haha370104

本质上就是单线程，我的个人理解是 runtime 机制带来的程序内的控制权转交

从流量费方面考虑……如果你的内网系统部署于云服务器，cdn 大概稍微便宜点？

首先，我们假设需要对所有接口访问都增加日志方便线上错误排查，合理需求对吧

其次，因为接口返回是有敏感信息而且数据量可能很大，所以日志不能记录 response body，也非常科学对吧。

然后我的服务器是一个集群，里面有上百个节点，也非常常见对吧。

假设有个接口 GET /api/some_source/{id}/some_field，作用是获取某个资源的某个字段，这个 path 的设计也非常 restful 对吧

接下来的事情出现了，我作为一个业务开发动了一下这个接口的逻辑；其他人更新了 nginx 配置，但出于种种原因没有生效于所有节点，可能只有 1 个节点会报出 404 。

接下来线上开始 404 错误率飙升，dev 环境「可能」无法复现（可能从业务代码来看这个资源的访问和用户状态有关，dev 环境 nginx ），然后你完全不知道是因为 nginx 导致的还是业务代码导致的。现在你唯一能做的就是让接口调用者（最好是前端，因为发布快）赶紧打一段日志配合排查问题

是不是觉得 restful 原教旨蠢了起来？还是那句话，基于单一责任原则，httpCode 最好只用来表示请求本身的状态；业务状态你用业务 code 来表示

Object.entries(
array.reduce((previousValue, currentValue) => {
previousValue[currentValue.id] = (
previousValue[currentValue.id] || []
).concat(currentValue.spec)
return previousValue
}, {})
).map(([id, spec]) => ({ id, spec }))

这应该是我能想出来最短的写法了……

mcmod 了解一哈，我觉得单纯论发布网站的话 mcmod 体验比 mcbbs 之流好太多了

@fenghuang 你即使用浏览器，外面套一层 charles 的代理照样会被检测，我其实还是挺怀疑浏览器的调试工具并没有告诉你全部的请求头或者说做了一些你不知道的事情

印象中某些时候，chrome 的调试工具并不会显示所有的请求头。

说 js 的先考虑这么一个问题：浏览器的加载顺序是下载 HTML->解析 HTML->下载 HTML 内的所有引用资源、那么请问，在执行第一步的时候，服务器是怎么知道一个浏览器能不能加载 js 的？更加方便的一个反驳方式：请直接进入设置禁用掉 chrome 的 javascript 代码，页面虽然加载略微有点不正常但是不会 403

我们换种方式，先禁用掉 JavaScript （非必要步骤），然后打开 Charles，解析 https 包，然后发现浏览器被 403 了，在通过验证码认证后，cookies 里面多出了一个 key：cf_clearance，curl 的时候加上这个 cookie 就可以正常请求了

@baobao1270 cookie 里面的 _sp_id.aded 参数每次都会变，里面有个时间戳