看你想干啥……本地开发随便写写，线上这么写有问题。。。

★ Allow-Origin 赋值成 $http_origin ，就等价于 allow *
　 origin 是请求时携带的网页 URL ，现在这么配，是来者不拒的意思，或者像 #12 那样提前判断下。

★ 应该仅在必要的 Method & URL 上加 header 字段，而不是直接写在 server {…} 或 location / {…} 这样粗暴。
　我们为了减少静态资源的 overhead 流量会给 CDN 单独买个域名，就是为了在请求和响应期间减少 header 所携带的内容。CORS 这种功能性的 header 应该仅在必要时出现。

★ 后端框架也需要注意的一点
　我遇到过一个网站，虽然有 CORS 策略阻止我干坏事儿，但是他们 jsonp 是开着的。我觉得是后端框架的锅，默认开启了 jsonp 的特性，URL 追加个 ?callback=jsonp_xxxx 还是能从前端跨域拿到对方的数据…

我自己剃头，有款推子用得很舒服，前两个月发现京东买不到了，天猫也没有，但淘宝有卖的，但是是英规插头。想必以后是买不到了吧…然后我就买了俩

刚刚看了一眼，我买的店铺也给下架了

@privil @kinkin666 我并没有表述 AWS 的服务器没有用 ECC 内存

可能是我们的机器实在是太多了，所以遇到了非常极端的小概率问题的可能性也是有的吧…

因为在这个事儿之前，我刚读过 Dropbox 关于它客户端 bitflip 相关问题的文章，因为 Dropbox 的用户体量就非常巨大，他们的客户端上的 bitflip 很常见…（文章里是这么说的）

----
当然我们遇到的这个问题并没有定论，而且 AWS 的服务器不可能不用 ECC 内存，毕竟那么大的体量，出了问题他们担待不起。

我对于问题原因的判断单纯因为两端的日志比对，字符 3 （ 0x33 ） 变成了字符 #（ 0x23 ），就一个 bit 之差…

Surge 有机制，可以通过匹配热点名字 SSID ，然后用直连 Direct 的规则就行了。具体自己看下文档

我们 AWS 生产环境遇到过一次（疑似），而且是灾难级别的

程序端打印的日志跟 slow query 里的语句差了一个 bit ，这个翻转了的 bit 把 where 给注释掉了，然后这条 update 语句更新了全表…

送个金子做的小蛋糕：宝宝零岁纪念

「升级到 iOS 18 测试版两周了，这次决定未来不升级 iOS 18 了」

笑死，beta 的时候卡，得出结论：以后不升级了

上一个现象级的不是《周楚除三害》吗

月底有死侍与金刚狼

如果没写过后端，已经有几千用户了，建议别写后段…Java 有几个框架经常报漏洞；或者别的语言的框架，你完全不了解的话，会导致后段数据库被注入什么的…

当然，如果你对各种安全准则熟稔于心的话：
Swift 有 http 框架了，可以了解一下，Linux 也可以跑

ipatool 先完成购买，再用手机下？看能不能下载旧版本的

mailgun ，发信量大的话，买独立 IP

当然是用绿联的 wildcard 证书 有效期一年 /doge

[绿联私有云 NAS 可能存在中间人攻击，官方域名的泛域名证书可以被直接下载-哔哩哔哩] https://b23.tv/vNM31NS

体感么，Xbox Kinect 那种

「有价值」这个事儿是有偏好的，你得训练你自己的，才能用

「输出摘要，这样我一看就知道……」，那你还是看了全部的新闻

如果生产的话，普通的 Web 业务，流量就别太大，否则会收到邮件，限定你多久内升级成企业套餐…

而这个流量阈值是不透明的

前两天有个 CF 怒删客户站点的 blog ，只看了标题，没细看内容，说是被删的站点触碰了 CF 的规则啥的

没事！尽管扫！