SQLite作为嵌入式数据库引擎表现出色，但存在默认设置不当的问题，例如默认忽略外键约束，这可能导致数据不一致和悬空引用。

SQLite是一款出色的嵌入式数据库引擎，被广泛用于本地数据存储，甚至一些服务器软件也在使用它。与传统关系型数据库不同，SQLite以库的形式运行，无需独立进程，同时避免了自定义序列化和解析器的需求。然而，它的默认设置存在几个严重问题。

首先，外键约束默认被忽略。在SQLite中，即使定义了外键，也不会自动强制执行，这可能导致数据不一致。例如，删除用户后，其帖子可能被新用户继承，因为SQLite会重用ROWID。解决方法是通过PRAGMA foreign_keys = ON;手动启用。

其次，列可以存储错误的数据类型。SQLite的列类型具有“亲和性”，而非严格限制。例如，定义为INTEGER的列可以接受文本值，这可能导致数据验证问题。虽然SQLite支持严格表（STRICT），但需要手动为每个表添加，没有全局设置。

第三，并发写入时会出现SQLITE_BUSY错误。默认情况下，当多个进程尝试同时写入时，一个进程会立即收到错误，而不是等待锁释放。通过PRAGMA busy_timeout = 5000;可以设置超时时间，但这不是默认行为。

最后，性能默认不佳。预写日志（WAL）默认禁用，而启用它并调整同步模式可以显著提升写入性能。

解决方案是引入类似Rust的“版本”系统。通过一个超级指令（如PRAGMA edition = 2026;）来同时启用所有合理的默认设置，包括外键约束、忙超时、WAL模式和同步模式，同时使严格表成为默认。这样既能保持向后兼容性，又能让数据库引擎随着时间推移更新默认行为。

根据评论内容，总结如下：

主要观点与论据：

1. 支持“版本（editions）”提案（评论3、4、6）

   • 评论3（sethev）认为该提案是“对常见问题的直接解决方案”，通过PRAGMA edition = 2026实现向后兼容，避免“希望别人改变”的空想。
   • 评论4（Rendello）建议在SQLite论坛讨论此方案，并指出当前PRAGMA foreign_key = ON（单数）不报错的问题，强调版本机制可避免此类混乱。
   • 评论6（andai）以JavaScript的"use strict"为例，说明“向后兼容”并非不可改变，版本机制可类似地修复不合理行为。

2. 对SQLite默认行为的批评（评论2、3、7、8）

   • 评论2（kccqzy）指出版本机制可能破坏跨版本数据库文件兼容性（如旧版/usr/bin/sqlite3无法读取新版数据库），但可通过捆绑对应版本工具解决。
   • 评论3（sethev）为SQLITE_BUSY辩护，认为busy_timeout默认留给调用代码处理是合理的，但常被忽略。
   • 评论7（Thaxll）批评SQLite类型系统“非常有限且危险”，类比旧版PHP，并指出缺少日期类型。
   • 评论8（souvlakee）抱怨ORM层（如Drizzle）不支持STRICT表，导致需手动修改迁移SQL。

3. 现有替代方案（评论9、10）

   • 评论9（chillfox）提到可通过编译时标志设置默认值。
   • 评论10（Retr0id）推荐使用封装库（如APSW）设置合理默认值，但希望有跨运行时的标准方式。

平衡性总结： - 支持方认为版本机制是解决SQLite默认行为问题的优雅方案，且向后兼容。 - 反对方担忧版本机制会破坏跨版本兼容性，并指出SQLite本身已有类型系统、ORM支持等深层问题。 - 中立观点认为现有替代方案（编译标志、封装库）已部分解决问题，但缺乏统一标准。