你看嘛，一个 HTTP 请求的 URL 放在第一行的
然后 body 可能是很大的，甚至可能是一个文件，所以 body 有可能是流式处理的
这也就代表着，如果你需要将一个请求分配到一个具体的函数上去的话，等 body 全部解析完是很慢的也很没必要的
举个例子，body 是一个文件流的话，只要我分配到了“把文件存起来”这个函数上，这个函数就可以把 body 流对接到 file 流。但如果我没办法分配到函数上，我就要等 body 流读完，把这个流放在内存里（假设内存没爆掉），然后解析 body 分析函数，把整个内存里的流给它，它再存到文件里，这效率多低啊
所以一些参数放在 URL 是非常合理的，特别是用来鉴权的、判断路由的等等
当然我可以不用 URL 而用 HTTP 头，但 HTTP 头的危险性在于你不知道中间有哪个 SB 一样的代理自说自画给你改了或者弄丢了……

@realpg 我们叫百度，算 Top 里应该问题不大

@realpg 公司是 Top……算了我也不知道 Top 几了已经被你们黑得体无完肤了。但有自己的整套云，只论成本的话要比我报的数字低很多，只是这个云对内部门间也是按对外的价格结算的

@realpg 是的不同的实现成本会完全不同，用云服务肯定相对会贵一些，但稳定性和数据保障性更靠谱一些，外加运维的成本几乎没有。然后 CDN 那个费用就完全看规模了，规模不上去屁事没有，规模上去了可不是按流量算钱这么简单了，所以我一直不敢对全网开放

@realpg 解压和不解压是不一样的，代理和同步全量存储是不一样的
NPM 的全量解压后大约有 20TB，对象存储约 2500 一个月
CDN 以我们公司为例，仅小范围推广的情况下，产生 7TB 一个月的流量，1700 一个月

同步的计算成本可以用 3 套方案：
1. 用官方 NPM 的 couchdb replica 方案，成本不高，但国内网络原因稳定性极差
2. 用淘宝 npm 的增量接口，同样成本不高，但那个接口事实上会偶尔漏一点东西，需要有一套机制去补上
3. 用轮询 npm 全量做对比的方案，成本极高，我用 FAAS 实现这一套核算下来 5000 一个月

除此之外，无论如何不能避免的首次同步全量，大约会有 5000-6000 的成本

确实到不了几万，但小一万一个月是存在的

现在这情况你让他上哪呢？ A 股吃得住吗，美股看中美关系吗，港股去找乐子吗？

我们有一个这样的东西，逻辑不难，下载 gz 包解压放进存储里，存储用对象存储就行，不贵
要省钱的，就请求来的时候发现没有再下载解压，第一次访问慢
想速度的，全量同步进来，成本比较高，存储加带宽几万一个月吧

戴森电吹风用冷风吹

强迫症的健康福音，就算热量可以改得目标很低轻松完成（我现在设的 400 ），那 30 分钟的运动是不能调整的，所以每天肯定有至少 30 分钟的快步走
不刷圈不舒服斯基

@zhangsimon 因为视频的压缩是前后帧相关的，所以要效果优秀的话不大可能中间转一段再拼一拼就能搞定

@honglei92 基本可以肯定微信也是 ffmpeg

如果 if 里的条件是 A 接口返回才知道的，那么除了把 B 和 C 放进 A 的 then 里以外没有任何办法
代码改造成 await 的话改起来没什么成本，反正外部调用肯定是认定返回值是 Promise 吧

@screen 用国外的也一样啊，比如日本和欧美都听的，用哪个都不好使

Apple Watch 能让你手机上所有拦截短信的 App 一下子变成废物

我一直不明白前端怎么就学不完了，你后端不有 N 个 ORM 、N 个 IoC 、N 个 MVC 、N 个 RESTful 、N 个 Async IO 、N 个 APM 、N 个 MQ 、N 个 Cache ？东西能比前端少？分库分表 Sharding 不难？横向纵向可缩可扩不难？全链路监控秒级报警不难？自动保活故障恢复不难？

@Ansen 代位追偿不用单独买吧，有车损险就自带了

@yitl666 90%的时间觉得爽呆了，偶尔难受一下

曾经也有过一方要回老家一方要留上海的问题，后来要回的回了，要留的留了，然后还结婚了，至今已经结婚了 6 年了，结婚前交往了 5 年

软件基本不大可能成为卡脖子的技术，特别是 RTOS 这种军用有需求的，肯定是有自主的