给个 echo 接口放出 url 来给大家看看可能更清楚。

在 markdown 语法层面，##和==等效。我更喜欢##，从 h1 到 h6 很统一很方便记忆很有逻辑美感。
在渲染层面，h2 和上文有没有亲密接触，真的是 css 的事情，和 md 一点关系都没有。

@huclengyue 战术层面的勤劳掩盖了战略层面的懒惰。任何语言里额外转一次 string 都是体力活，但好在不用动脑呀。
相反，选择自带库不是懒惰，这是聪明的偷懒，因为脑力都耗费在设计上，耗费在方案选择上了。就算自带库不能满足需求（比如 js 自带 json 解析不能满足 long 需求）依然花力气去找轮子而不是造轮子。有现成的谁不爱用呢是吧。

你要这么想：输入是 bin，要求输出是 string，用什么？当然用 base64 一步达成。
urlencode 输出是 string，但输入也是 string，并不符合你的场景需求，你还得为它做一步转换准备好入参。预先从 bin -> string 过程中，必然会引入新的因素：编码。
再说一下字符编码。并不是任意一个 bin 都能转成对应的 string 的。很多编码方式都有它自己的规则，例如 utf-8，对于 n 字节的符号（ n > 1 ），第一个字节的前 n 位都设为 1，第 n + 1 位设为 0，后面字节的前两位一律设为 10。因此很容易构造（遭遇）一个非法的 bin 序列在转换时报错。还有，转换后的码点是不是一个合法字符？这是由码表说了算。码表上不存在的，有可能就作为非法字符忽略或者显示为框或者问号。
假设第一步转换凑巧没出错，还得考虑第一步转出特殊字符，第二步 urlencode 时会不会正常处理。例如\0、\r、\n。。。毕竟它的设计并不是计划用在这种场合。

塞到 json 里用 urlencode 首先就错了。base64 足矣。
其次，问题的原因是编码。如 2 楼所言。

1，不谈 json，绝大部分持久化协议都有类型系统。为什么？可能这些协议设计者规范制定者都是傻子吧！
2，json 大数字导致 js 解析失败的问题，是怪 json ？我扔个 20 位的字符串你 js 真的就能按 long 处理了吗？我扔个 2000 位的呢？我扔个 10^20 的大数字字符串把你内存撑爆了你是不是还是怪 json ？冤有头债有主，https://www.npmjs.com/package/long 了解一下。要搞科学计算的，请自己实现大数字的解析和计算。别死抓着系统 json 解析库不放，却怪字段类型。
3，类型错误导致异常的同学，硬生生通过消灭错误的根源解决了错误。你们真厉害，跟 zf 一个处理思路。那值错误问题呢？想个办法也消灭掉？参数个数问题呢？变长参数嘛！参数顺序问题呢？调用时用字典传参写明 key/value 对嘛。参数名拼写问题呢？我编不下去了。。。不过我想聪明人应该能解决，办法总比问题多嘛！

——以上是恶搞，以下是正经分析——

其实还有一点是非常重要的：信息抹除。原接口设计和数据 /参数持久化是携带了类型信息的，被硬生生抹除了。
接口 a 需要一个 int，传了个"0"，
接口 b 需要一个 string，传了个"0"，
接口 c 需要一个 bool，传了个"0"。
他们默默做类型转换的时候，揣摩通透服务端的意图了吗？万一服务端真的 bug 了，就输出了一个错误的类型，你能察觉吗？
这是信息抹除带来的第一个问题：错误被掩盖。
第二个问题可能是某些人习以为常的：文档上说入参均为 string，但其实具体实现中会对他们做对应的转型操作。转错了程序当然没法正确执行。这使得人们更依赖所谓的文档，却直接丢弃了语言 /协议 /架构 /方案自身的自描述和自检能力。“最好的文档就是代码本身”这句话的价值不是为懒得写文档找借口，而是真正的金玉良言。
第三个问题随着第二个问题而来，文档缺失和过期大概是实际项目中的常态，信息抹除所带来的额外信息恢复工作就变成了一项困难的事，增加更多不必要的成本和风险，以及团队沟通成本、技术管理成本。

那么为什么很多“给别人用的接口”反而倾向于这样设计呢？容错性表面上能稍微好一点，而额外带来的风险和成本又不必自己承担。典型的就是给第三方用的接口、给其他部门用的接口、给其他团队用的接口。后端给 app 扔个这样的接口，不必沟通，不必争论，暂时性的增加了双方的幸福感。有种让他在团队内部同一项目内声明一堆 Object... args 的方法？怕不被自己人打死。

说白了，这就是懒惰+短视+自私的人性抉择。

塞一个实例里：实例挂了不就都挂了吗？
塞一个集群里：集群挂了不就都挂了吗？
塞一个机房里：机房挂了不就都挂了吗？

任何策略都有收益和代价，并不存在一定对的策略更不存在完美无缺的策略。看你自己选择了。

白天开会，晚上干活，这是日常。
思考？所有暗时间。
这下你知道程序员为啥爱加班不爱社交了吧。。。/023

什么都可以魔改啊。。。这个有限制吗？

cs 专业课了解一下。#58 有列。

其实说实话，就算以上都了解，很多野蛮生长的人还是比不上科班出身。为什么？
并不是那些专业课的原因，专业课几乎都是基础，离现实很远。有帮助，但帮得略显有限略显过时。
根本差异还是在人，在人的学习方法和学习速度。
面试、招聘过很多科班和野草，概率上来说，科班就意味着这人的学习能力足以让他轻松通过本科硕士的课程。进入工作以后虽然几乎还是白纸，快速学习能力能让他们迅速吸取知识并抓住本质还能融会贯通形成体系。
概率上来说，野鸡学校、培训班、初中毕业的人更容易出现学习困难的征象，成长缓慢，被动学习，他们一路就是这么磕磕碰碰凑凑合合走过来的，工作以后就指望能脱胎换骨一日千里？

所以，根本上还是人的问题。

人的差异有两方面：大脑的差异，这是先天的。有的人就是思维敏捷。方法和习惯的问题，这是后天的。人家有独特的有效的学习习惯和技巧。
先天的不用考虑，杞人忧天毫无价值。而且绝大部分人的努力程度和终身成就之低，低到根本用不着拼天赋的地步。所以我们还是只考虑后天因素好了。

关于学习方法，这个也是可以学习可以练习的，和野不野生没关系。网上有很多介绍，更系统更全面更科学，我就不班门弄斧了。只针对性提几个建议：
1，强烈的决心。lz 看起来是有的。
2，合理的计划。lz 看起来没有。
3，适合的方法。例如看视频是远小于看书的，效率低，被动，不利于思考。

有了合适的方法和习惯（发动机），追上所谓科班生也就 1 年时间而已。再往后，你跑的可比他快了。

1234 里都没看出有什么动态内容。
那就为每个用户提前生成啊。

@cnt2ex 我正打算做个基于 linux 的计算器，听您一席言还是算了，怕不是得被骂死。
听说特斯拉的车载系统是基于 linux，居然也胆敢没开 root 权限，逆天而行妥妥要凉！

symbian、WP、iOS 从来不开放 root，居然就没人骂。
Android 不完善的时候让部分用户尝到了 root 的甜头，后来为了大多数人的安全和体验尽量严格禁止，反而被用户喷。
还有另一个真实的故事：
某馒头店偶尔送一两个馒头给贫穷的人，众人纷纷点赞夸老板仁厚善良。
老板一激动，决定把善心做成一项事业。70 岁以上无业老人随时可以来免费领馒头。
于是慕名而来领馒头的人越来越多，甚至还有反复排队反复领取的。
亏的钱越来越多，老板终于做不下去了，宣布这项事业中止。
本来能领到馒头的老人发现从此没有馒头领了，部分人就开始谩骂。

这两个故事告诉我们，当得到成为一种习惯，有一天却突然发现曾经的得到已经消失的时候，有的人真的会失去平静和理智，忘记这份得到的来源，忘记自己凭什么能得到，单单只因为失去而谩骂。
解决办法是：开始就不要给。

卖手机，手机并没有提供 root 功能，你嫌 root 麻烦。
卖电视，电视并没有提供换操作系统功能，你嫌商家没有提供方便的工具还要你自己去焊芯片刷 ROM。
卖房子，开发商并没有提供敲承重墙打天花板做阁楼功能，你嫌装修不方便不自由一锤一锤直到把楼砸塌。

都不知道哪来的浑身是理。。。

愿意 root 确实是你的自由，明显的一点就是商家并未阻止你然后把你告上法庭。至于门槛？不存在的，这不是 bug 这是 feature，商家的设计思路并不必须考虑 hacker。不爽你可以去选择专门针对 hacker 的产品。

这网站。。。号称 https vs http ？根本就是 http2 vs http1.1 啊。和 https 有关系吗？

老板说了，拿最近遇到的技术难点去问求职者。
问到不懂的就出出气涤荡涤荡心灵才好加班。
问到高手就认真学习人家的思路，口头应付应付打发走。