阀值 vs 阈值 才是文化重灾区。除此之外，

登录 vs 登陆
稍候 vs 稍后
发帖 vs 发贴
账号 vs 帐号
充值 vs 冲值
更新 vs 跟新
震动 vs 振动
陷阱 vs 陷井
剖腹产 vs 刨妇产
重新开始 vs 从新开始
无上光荣 vs 无尚光荣
一筹莫展 vs 一愁莫展
我悲伤的不能自已 vs 我悲伤的不能自己

加一个镇楼：
很多人说他们的老婆是 新 heng 结衣，我表示很欣慰。

mac+chrome，没有发现问题。
说有发现矿机的，能给出证据吗？

永远不要忽略一辆载满磁带的在高速公路上飞驰的卡车的带宽
http://news.mydrivers.com/1/544/544117.htm

我记得 google、amazon 经常做这样的事。

很好，lz 总结的很好。233333333

干活()
try:
下班()
except 产品经理改需求:
掏出菜刀摆桌上走人()
except:
pass
继续干活()

每天不都是这样的逻辑吗？你还能处理多大的异常？

1，历史。div 是 HTML2.0 出场的，div 加持一堆 css 和 js 属性那是更久以后。a 呢？ HTML1.0 就有了。我用 a 用的好好的，凭什么 div 出来我就要改？历史代码还要不要？接受新事物也可以，只要新事物在某些方面巨幅超越旧习惯——然则并没有。
2，懒，方便。有一种写法是“<div 可编辑，带框，可焦点，可记录值，可和表单合作。。。>”，巨臭巨长一大堆属性。没办法，div 有五万种属性可供配置，为了每个具体场合有适合的表现，必须配置妥当。这么恶心的代码，我分分钟抽象出一个新标签叫<input>。你叫他语法糖、模板、组件。。。随便什么都可以，背后的原因都可以是懒。分化是必然结果。
3，语义化。所有的代码，本质上都是给人读的。越通俗越直白越自然越好。
4，效率。漫长的、复杂的 div 显然不便于网络传输和浏览器解析。高度抽象后简洁的<input>更有效率。
5，简单。不是每个人都能灵活使用 div+css+js 的。给他们一目了然的 p、img 和 a，他们已经可以写网页了！用的人多的技术才是能活下来的技术。
6，还有其他，懒得写了，直接进入总结吧。

lz 能提出这种问题，技术水平一般在 1-2 年左右，能力有长足进步，逐渐发现自己能在原本以为非常稳固的世界中用某些 tricks 打开新的大门。这时候很容易对旧世界产生思考，产生质疑，有一种打破和改造旧世界的冲动。
但，压住，压住。在冲动之前，应该理智。先想清楚，“存在即合理”这句话的意义何在。抛弃自己的立场，客观全面的评价旧事物，再谈打破和改造的必要性、程度、方式。

也许 lz 现在已经跨越了技术方向的第一个门槛。现在要补的，是设计、工程、人性、哲学等比较宏大比较虚的话题了。: )

他们的沙箱根本不同步维护，经常有各种问题。
对接人员建议我们用真实环境账号测试！

说句实话，我看到的独立游戏爱好者很多，要都做成这样就敢去任何一个论坛发帖，那论坛也是药丸。
禁言有点过了，沟通清楚然后删帖我觉得并无不妥。

无论技术上可不可行，我觉得和设计初衷、和字面意思、和直觉相违背的 geek 用法都是以可读性 /可维护性为代价的奇技淫巧。

@megachweng @vexe
入门三两天连 SQL 都看不明白的小白，你们居然指望掌握 md 和 gist。。。
我看出来的是，这孩子连如何解决问题都没养成好习惯，怕不是才毕业吧。。。

想当年，js、jq、mvc、es6、node、mysql 这些烂大街的名词无一不是“偏理论，有数学难度的内容”，只不过大家见多了，觉得没啥新鲜了而已。
现在你觉得区块链、机器学习好牛逼，我封装一个库分分钟让 90%的使用者变 API 工程师。十年后，还会有和你一样的人来发一样的帖子，只不过是把 node/mysql 换成了区块链 /机器学习而已。
能想清楚这个问题吗？能想清楚应该怎么做吗？
如果想不清楚，还不如踏踏实实从 API 工程师做起，逐步丰富视野深入挖掘，了解烂大街们的上层设计和底层实现，优点和缺陷。然后理论联系实际，厚积而薄发，成为下一个烂大街技术的孤独奠基人。

改进办法难道不是——
压缩“源码”就不要带.git 目录！
——吗？

看起来不需要可逆？

那就相当随意了。。。sum(md5(n)) % 255 反正足够随机+落到 0~255 范围内即可。

因为升级的人都默默升了，也没啥值得大惊小怪的亮点，懒得说话。
所以，这是一个幸存者偏差型问题。

1，结果导向。你目前急需的才是最高优先级。
2，兴趣优先。不管深度还是广度，兴趣是最佳驱动力。
3，然后是广度优先。每个深度都是无底洞，都可以扔一辈子在里面，而无论是实用角度还是耐力角度，广度都更好一些。
4，对于个别重要话题，保持一定深度。记住两点：选题要准，深度要足够深但又不过深。
然后就是在 2 驱动下的 34343434 循环了。

不费硬件资源，费人力资源，费精力。
每次涉及到账号体系的时候，都需要考虑三方授权问题。
1，多账号绑定怎么办？
2，多一个业务逻辑就多一个服务内容，每次部署升级迁移备份都少不了它怎么办？
3，也多一个失败风险点，引起的客服、投诉量怎么办？
4，三方服务失败 /被墙怎么办？
5，三方服务被脱裤，安全体系崩溃影响我方怎么办？

你看，换位思考一下，随便想一想都这么多问题。不是问题不存在，而是代价和收益的比较。

——做个三方登录加维护多少成本？
——大概每年 100w 吧。
—— 100w 就够了？那做呗。这么小的代价，给到用户的感受是非常不同的。我们 x 牛，要以用户的价值为中心！
——好的 boss ！我这就去安排！
——对了，这部分功能的用户量有多少？
—— 3。。。3 个。
——哈？虾蟆？ 3 个？ 3 个人每年 100w 你莫不是今天停药了？这么边缘化的功能，砍掉！

以上纯属瞎掰，具体数值请楼上各位了解运营层或财务层的决策大佬们提供。

不管需求有多少，不管有没有二次开发便利。
定价 100 元 /天就是在侮辱人格。

浮点数是有范围和精度的。
http://www.cnblogs.com/BradMiller/archive/2010/11/25/1887945.html
可以照这个文章自己手算一遍。