@imhxc #70 除非你能直接塞图灵完备的代码进数据库，不然什么都有局限性
就是 SQL 有时不得不分成两个查询（ SELECT ），虽然完全就是数据库里的内容，之后可优化为一次数据库交互包含两个查询（避免传输），但一个（对人脑来说）本来看上去非常简单的东西，不通过逻辑检验竟然无法简化。

实际上 RESTful 不是有局限性，而是它就是局限性本身：通过强加某种限制，将（一次） API 请求类比为对（一项）资源的操作，形成某种直觉映射，来理清思路。要 “改” 到 RESTful，并不是改动 API 就行的，而是整个建模得修改。
有人[谁？]（忘了谁）认为其实是启发自 Unix 的文件操作。（所以 WebDAV 是 RESTful 最恰当的应用场景）

这哪叫故意劣化，这叫 QoS

封 80 443 的原因又不是技术原因。

不过你不能证明此网站添加菠菜广告的时间点和迅雷添加此网站的时间先后关系
说不定迅雷先引用了此网站，有了迅雷引的这么多流量此网站才接到菠菜广告。

割与被割其乐融融，你又为什么掺一脚（

割与被割其乐融融，你又插什么脚（

@abcbuzhiming #24 为什么 QQ 要打击第三方机器人？
首先任何人做某事应当是为了利益。但共赢的利益放在面前反而选择双输的结果，这让人看不懂。
像苹果一样收个 “QQ 税” 都让人能够理解，盲目地武断地滥用利维坦进行打击的目的是什么？
承他者所言，不少 IM 软件允许甚至激励第三方编写机器人达成双方共赢，此类实践在前的情况下，难道非得官方通告显式地允许才行吗？

更进一步地反思：楼主没有显式地允许你回贴，你 @ 的两人也没有显式地允许你 @ 。
你觉得非得经过 QQ 方面显式允许你才能开发第三方 bot，那你为什么不经过上述三位的显式允许即进行了上述行为？

注释越多越好？

难以阅读的代码提名奖：
在注释中讲个引人入胜的小故事

我先拍脑袋提段（伪）代码，你的工具将彻底降级体验，场景是 /t/691526 的 #6 楼，假设 100 个完全相同的 Task
if(random()<0.01){
syncronized(x){
x--;
}
}
如果你只靠静态分析，那么全部只能塞进一个串行绪。
所以上述必然要拆分，把 random()<0.01 判断完之后重新构造 Task，这个新 Task 才能加锁。
否则就是近似 100 倍性能损失。
结果就是没解决复杂性，最多是些锁语义的语义糖，还优先解决死锁问题。

如果你觉得真的有必要，如上，请给 arXiv 发论文。

Arch 的教程选择 /tmp 挂 tmpfs，实质上似乎就是个 ramdisk
不知道你的“临时文件”是什么情况
另外，NTFS(?) 也可以把一个盘挂在非盘符根目录的。
其实你的需求就是临时文件不落盘，ramdisk 或者 ramdisk+unionfs 之类是最好的选择。

上面说的 log 能基本看个大概
完全掌握所有边角情况还是得看前端代码。
如果不接触 JavaScript 的话，提一个看前端代码找网络访问情况的诀窍，
如果前端写得正常，应该会有 *_HOST 这种名字的全大写伪常量，基本盯着使用这个变量的地方就行。
有时会封装一个函数里用上这个变量，那么把这个函数也纳入考量。

比你同时开 WebStorm Clion PyCharm IntelliJ 强（
@cstj0505 #16 懒加载应该不会启动就开 Java 进程的，是不是默认打开了一个 Java 的 buffer ？
或者因为 VSCode 的脚本加载点其实严重缺乏，导致必须随 VSCode 一起启动：比如写 Python 的话，默认打开的 Terminal 不能自动加载 virtual environment，因为 terminal 加载比 buffer 发现语言而调用语言插件早……
缺乏预载阶段，允许单一插件分块加载是很大的性能优化。

年底也不行
你们怕是忘记去年临时改了五一调休

gdb ？