SQLite 数据库的作者 Richard Hipp 解释，为什么他的项目一律不接受外部的 PR。 PR 不是免费的。你实际上是对我提要求：你开发了这个很棒的功能，然后希望我帮你维护它、帮你编写文档、帮你测试，并在接下来的二十五年里一直为你维护它。 Linus 曾说过一句名言：Free 既可以指免费啤酒，也可以指言论自由。但还有另一种 Free：免费的小狗。“瞧，我这儿有只免费的小狗送给你。” 你明白我的意思了吧？ 提交一个 pull request 就相当于有人送你一只小狗。一天下来，你的小屋里就多了一只小狗。你不能把它扔掉——你有道义上的责任照顾它，直到它自然死亡。 我可不要任何免费的小狗。

看了 SQLite 论战，好有意思。 几派观点： 1. 数据归属：结构化数据 vs Plain Text。 2. 工程结构：RDBMS vs AOF。 3. 实现选择：成熟外部工具引入 vs 自建协议库。 4. 关注点：讨论工程 vs 信任权威 还有啥，可以补充 + 后续关注。 PS：我站 SQLite，考虑长期功能诉求和可维护性，总有需要引入一套复杂数据结构，不是自己写就是用别人的。

不管是用文件系统还是用 sqlite 存储聊天记录，本质区别是如何在一个大段的 block 存储上，存取大量的短数据，这才是根本区别。至于怎样索引，用什么算法搜索，两种方案基础之上都可以实现，那不是问题的关键。 用文件系统直接存储的问题是，文件系统是一个系统级公有设施。它要满足的是整个 OS 层面的通用需求，而不是某个单进程、某个业务场景的最优访问模式。所以如果把大量业务对象直接映射成普通文件，单文件的存取就会引入额外开销。当然现代文件系统已经把性能压榨到极限了，但抽象层级决定了它不可能专门为聊天记录这种大量短数据场景优化。每一个文件的打开，都可能涉及路径解析、目录查找 、inode 加载、权限检查、句柄管理、元数据更新等等文件系统开销，然而这对于聊天记录的存取场景完全是不必要的。 相比之下，sqlite 建立在文件系统之上，存取操作损耗低了很多，检索实现起来也更加容易。 不过如果仅讨论每一个聊天会话写一个文件这样的使用场景，一般用户顶多几百几千个聊天会话，这种量级下性能差距微乎其微，用啥都行。 我真正想吐槽的是，之前微信 Mac 版本把表情包、缩略图这种小数据也一概全部单文件塞文件系统，我的聊天记录不算特别多，微信的数据文件夹下都有上几十万个小文件，虽然用着没啥问题，但是对于系统备份、恢复、迁移操作都是灾难，90% 的时间浪费在小文件处理上。我记得某次测试，单 rm -Rf 删微信数据，就删了好几个小时，微信自己的聊天迁移如此缓慢，我猜也是同一个原因。4.0 新版本应该已经修了这个问题。

一堆人骂微信用sqlite，其实没有任何理由。 就本地存储这么多信息而言，sqlite是一个很好的选择，连中推公认最好的telegram的android和iOS也用的sqlite，证明sqlite这个database本身不是微信性能的瓶颈，同样用sqlite也能做出世界级聊天好工具。 那么真正瓶颈只能是微信团队程序员的智力水平了。

如果你也遇到异常，请记录： • Codex 版本 • 操作系统版本 • logs_2.sqlite-wal 增长速度 • SSD SMART/健康度变化 然后集中反馈给官方。硬盘损耗不可逆，别等设备出问题才重视。 建议配上 SSD 健康度前后对比，以及 WAL 文件持续增长的截图，可信度会高很多。