开发者 Mort 在文章 SQLite should have (Rust-style) editions 中提出一个社区设想：增加类似 PRAGMA edition = 2026 的总开关，一次启用外键约束、合理的锁等待、WAL、较合适的同步模式，并让严格表成为默认选择。这不是 SQLite 官方路线图，而是一份针对默认行为的设计提案。

一句话结论：Edition 的价值不是给 SQLite 增加新能力，而是让新项目获得更安全的默认值，同时不破坏依赖旧行为的海量软件。

SQLite 的特殊之处在于它几乎无处不在。手机 App、桌面软件、浏览器、设备固件和小型服务都可能把它直接嵌进进程。也正因为如此，一个看起来更合理的默认值，只要改变旧程序的行为，就可能在全球大量设备上制造兼容性问题。

提案列出的第一个反直觉默认值是外键约束关闭。你可以在建表语句里认真写下 FOREIGN KEY，数据库却不会默认执行它，除非连接主动设置 PRAGMA foreign_keys = ON。项目一旦漏掉这一步，删除用户后仍留下指向旧 ID 的数据，甚至可能在 ID 被复用后错误地归到另一个用户身上。

另外几个问题更像开发者踩过才会知道的坑。SQLite 的类型默认很灵活，整数列也可能存入文字；多个写入者竞争时，默认可能立即返回 SQLITE_BUSY，而不是先等几秒；WAL 也没有默认开启。它们都有现成的设置，却要求每个项目、甚至每条连接都记得配置。

为什么不直接把这些开关全改掉？因为旧应用可能依赖宽松类型，可能假设 journal mode 不变，也可能有自己的重试策略。Rust 的 Edition 思路恰好提供了一个折中：语言可以推出新一代默认规则，项目主动选择版本，旧项目仍按原来的语义运行。Mort 想把同样的机制搬到 SQLite。

当然，一个“超级 PRAGMA”也不是没有麻烦。WAL 并非适合所有文件系统和部署方式，busy_timeout = 5000 也不一定适合每个交互应用；STRICT 表还会改变合法类型名称。把一组偏好叫作“2026 版正确答案”，仍需要 SQLite 维护者对长期兼容作出承诺。

OC 的判断是，这个提案未必会按原样进入 SQLite，但它指出了一个真实的 API 设计问题：稳定软件的坏默认值最难修，因为用户越多，改变越危险。Edition 比继续堆文档提醒更有吸引力，它把“记得配置”变成“明确选择一套现代行为”。

为什么重要：

• 对开发者：新建 SQLite 项目时应主动检查外键、锁等待、journal mode 和类型约束。
• 对框架作者：数据库连接初始化应集中配置，不能指望每个业务模块记住 PRAGMA。
• 对用户：更严格的默认值会减少难以察觉的数据错配，但升级策略必须尊重旧数据和旧应用。

参考来源：

• Mort：SQLite should have (Rust-style) editions
• SQLite：PRAGMA Statements
• Rust：What are Editions?