http://www.bilibili.com/video/av8869179/

2500 以活着……

网关应该有一个可以和空调控制器一体化的，这样能合算些

除非有 Server Timing 的支持，不然 TTFB 是没办法告诉你分阶段（ req - server - res ）的各阶段数据的，当然 req 和 res 这 2 个阶段可以考虑通过一些网络监听程度比如 wireshark 之类的去看

对于静态文件，由于 server 基本不会耗时，所以减少 ttfb 最简单的（对于很多人也几乎是唯一的）手段就是上 CDN

@xyjtou 不对，你这理解就跟 SSD 里有万年不动的系统文件所以其它区块更容易坏因此要经常重装下系统一样……

@dingsoung 这让我想起 2 年以前线下店铺都不能支付宝付款，不也活的很好吗，拿着现金就行了
5 年前京东还不能上午买下午送到，不也活的很好吗，要生活用品去超市（拿着现金）就行了
10 年前世界上还没有视网膜的显示器，不也活的很好吗，要眼睛不累去打印店（拿着现金）打印出来就行了

另外 1password 从来不是“把密码放人家那里”，你得弄明白这货怎么工作的

之前已经购买的不会内购收费，还算是有良心的

quiver

@HFX3389 就是 CDN 上没有这个文件，需要从真正的百度云的服务器上去重新拉这个文件，这样 CDN 的作用就小了很多

@QAPTEAWH Apple 确实曾经在某次电池问题时发表过声明是因为用了第三方充电器导致的，这公司和三星没啥质的区别

文件下载的速度和 https 基本没关系，百度云的分片还是比较大段的不至于因为一个握手影响严重
网宿和百度云的问题是在于近期速度确实慢下来了，感觉是回源的情况变多了

@lloovve 我在内部网下云盘的东西还没从自己私有 NAS 上拖东西快- -

既然改密码要用原密码，改手机号要用原手机号也很正常，而且在当前很大一部分应用的设计里，手机号的安全级别比密码还要高

水中毒是要不排出去不断喝的，最后说白了就是脑子进水而已，如果你排出去了再喝不会有事，体液环境稳定性还是很好的

编码规范只应该针对 2 个方面优化：

1. 人阅读时的体感感受
2. 基于子串和正则的简单分析脚本的实现便捷性

其它方面的，包括文件体积、程序可分析、搜索引擎等等，都应该是工具来解决的领域，为什么要让人来做这个事情？

我不反对如本题主贴中所述的这类编码规范，但我坚决反对主贴中所述的得出这一编码规范的理由，人机不分离绝对是不可取的事情

@FrankFang128 你真的理解么？在 JS 中每行加分号是为了人在读代码的时候保持一致性，不会因为某一行突然以分号开始而使流畅阅读产生停顿，不是为了压缩时不出错
正确的为了压缩时不出错的规范是：在行首字符为[、{、(时，在行首插入分号
这个规范是有很多团队采用的

> For file size optimization and scannability purposes, consider omitting optional tags. The HTML5 specification defines what tags can be omitted.

一个团队居然需要人肉写代码的时候做 file size optimization 而不是工具来解决，管他是 google 还是哪家我都给 2 个字：垃圾

反正我用过 85W 的 usb-c 充电器是可以的

语法 spec 和工程还是两回事，工程要考虑的事情太多了，比如猪队友、猪队友以及猪队友

@dou4cc 你要这么算也行，我没见过 exception 不冒泡的语言

首先你要能把语言和应用环境分开，这个问题才有讨论的价值， js 的错误处理很简单，就一个 try/catch/finally ，没有冒泡没有全局处理

而你说的 domexception 、 onerror 、 unhandledrejection 都是应用环境下的异常处理，这在任何一个语言 /框架里都是存在的，比如 ASP.NET 的 Application_Error ，比如 Spring MVC 的 @ControllerAdvice ，比如 ROR 的 exceptions_app ，在一个应用环境中，异常一定是要“冒泡”到全局下统一处理的，否则造成应用的崩溃在生产环境是一件非常危险的事情