在DEV上发帖，阅读量从几百到几千都有，作者自己也说不清规律。很少是写得不好，更多是发布的时间点、标题、标签，以及有没有人恰好刷到。让他介意的是，沉下去的那些帖子里，有些恰恰是他最想读的。
于是他开了个新系列：翻DEV上几乎零互动的帖子，挑看起来是真东西的读完，再把最好的几篇分享出来。规则有四条：互动几乎为零，反应和评论为零或接近零，数据截至2026年10月17日；每篇都从头读到尾，不跳读、不凭感觉选；作者若放了自己项目的链接，会明说；不收钱，没有赞助位、付费提及或返佣，有人想买位置就拒绝。
这一期挑了五篇，其中一篇用数字把很多首次贡献者的直觉摆上了台面。
21万条外部PR，四分之一石沉大海
作者@pctablet505跟踪了六个月内来自外部贡献者的拉取请求，只查一件事：两周内有没有人类回复、评审或合并。机器人、维护者自己的PR和草稿都被排除在外。
他的结论是：在有十个以上外部PR、处于活跃状态且有许可证的项目里，约四分之一的项目让其中大部分PR在两周内无人应答。而且这个比例随星标数上升：
- 1k–10k星：约21%
- 10k–50k星：约31%
- 50k+星：约39%
这篇的价值在于给一件每个首次贡献者都隐约怀疑的事配上了数字。它同时写清了自己的边界：这不是对维护者的判决，只覆盖GitHub，而且只是一个时间切片的快照。
需要提醒的是：该账号是新号（九月注册），帖子链接到作者自己的免费排名站点，数字也是他自己统计的。推荐者明确表示没有核实过，所以这更像一个提得不错的问题加一个看似合理的答案，而不是板上钉钉的事实。如果你正准备发出人生第一个开源PR，想知道它大概会在哪里得到回应，这篇值得一读。
另外四篇：GC、SQLite和一条被截断的堆栈
第一篇讲.NET性能：GC暂停主要来自分配量，所以解法是少分配。用栈分配、span还是池子，取决于数据要活多久。它指向.NET 10和ASP.NET Core 10源码里真正用到这些技术的地方，而不是玩具示例，也直说了每种做法的坑，从栈上限到池化数组的正确归还，并反复提醒先测量。缺的是基准数字——技术讲得清楚，但没展示省下了多少。适合那些"别人说要用池化所以用了、却一直没搞清什么时候划算"的人。
第二篇是@mgebrov的《VideoFloppy：五年，十个用户，一美元》。2021年，他依赖的一个学习工具关停，于是他做了个保存和分享外链视频的站点，在两个工作之余的零碎时间里搭建。五年过去，它只有几十个用户、几乎没有流量，以及一个付了一美元的付费客户。这篇没有包装，他直说这东西从来不是为了赚钱，然后列出它给了自己什么：在工作中能用的实战经验，比如在Blazor Server里处理客户端IP地址。帖子链接了产品，因为产品就是主题，没有推销。
第四篇解释为什么SQLite的WAL文件永远不缩小：开了WAL模式、有活跃读写、autocheckpoint开着，PRAGMA wal_checkpoint也报成功，但-wal文件还是涨到几个GB。问题在于读事务重叠、始终有读者开着时，检查点永远走不完回到第一帧的循环。作者没有转述文档，而是直接在SQLite的wal.c里追检查点逻辑，再搭实验台做基准测试：在每秒2000次提交的写入者加重叠读者的条件下，WAL以11.9 MiB/s增长，即使读者断开后仍停在357 MiB。文中还讲了PRAGMA wal_checkpoint(TRUNCATE)到底做什么，以及它带来的写入者停顿权衡。缺的是：基准模拟的是激进连续的写入循环，低流量或批处理场景不会这么快撞上这个边缘情况。
第五篇来自@doogal：Node.js里遇到未处理的拒绝，打开堆栈却只看到库的内部代码，自己的文件名和行号不见踪影。原因是V8默认只保留10层栈帧，中间件、ORM和异步包装一叠加，这10层在你代码之前就用完了。文章解释了这个默认值背后的原因，给出一行修复（Error.stackTraceLimit = 50或--stack-trace-limit标志），并用"只有10次曝光的相机"作类比。缺的是：没讲在生产环境调高上限的性能代价，而这恰恰是你不该直接设成Infinity的主要原因。
系列末尾留了个口子：最近读到什么值得更多关注的东西，可以在评论里丢链接，附一句为什么。符合上面规则的会被读完，最好的进下一期。
热门跟贴