SQLite 3.53.4 已正式发布。本次更新延续了 3.53.0 以来的改动，其中最值得关注的是修复了一个与 WAL 重置有关的数据库损坏漏洞。对于桌面软件、移动应用、边缘设备和嵌入式服务来说，这类修复的优先级通常高于新功能：数据库文件可能只有一个，但它承载的往往是无法轻易重建的本地状态。
为什么 WAL 修复值得立即关注
WAL（Write-Ahead Logging，预写式日志）模式不会直接把每次修改写回主数据库文件，而是先追加到 -wal 文件。读取方可以继续访问稳定快照，写入方则按顺序记录变更，因此 WAL 常被用于改善读写并发。
应用可以通过下面的 SQL 启用 WAL：
PRAGMA journal_mode=WAL;
WAL 并不只是一个开关。它还涉及 checkpoint、WAL 文件重用、连接关闭以及异常退出后的恢复。只要其中某个状态转换处理不正确，就可能破坏主数据库、WAL 文件和共享内存文件之间的一致性。
SQLite 3.53.4 修复的是 WAL 重置场景下可能导致数据库损坏的问题。来源摘要没有给出漏洞触发条件、受影响平台或完整调用序列，因此不能简单断言所有使用 WAL 的应用都会遇到它。不过，只要生产系统启用了 WAL，或依赖的框架默认启用了 WAL，就应把此次升级当作数据完整性修复来评估。
先确认实际运行的 SQLite 版本
系统中经常同时存在多个 SQLite：命令行工具使用一个版本，Python、PHP、移动应用或自行编译的程序又链接了另一个版本。只执行 sqlite3 --version 并不足以证明业务进程已经升级。
可以先检查命令行工具：
sqlite3 --version
sqlite3 :memory: 'SELECT sqlite_version();'
如果应用使用 Python 标准库，可以直接查询运行时链接的 SQLite 版本：
import sqlite3
print("Python module version:", sqlite3.version)
print("SQLite runtime version:", sqlite3.sqlite_version)
with sqlite3.connect(":memory:") as connection:
runtime_version = connection.execute(
"SELECT sqlite_version()"
).fetchone()[0]
print("SQL reported version:", runtime_version)
运行方式：
python check_sqlite.py
这里应重点关注 sqlite3.sqlite_version 和 SQL 查询返回值。sqlite3.version 表示 Python 数据库模块自身的版本，并不等于底层 SQLite 引擎版本。
对于 C 程序，可以在启动日志或诊断接口中输出运行时版本：
#include <stdio.h>
#include <sqlite3.h>
int main(void) {
printf("SQLite runtime: %s\n", sqlite3_libversion());
printf("SQLite source id: %s\n", sqlite3_sourceid());
return 0;
}
假设系统已经安装 SQLite 开发包，可以这样编译：
cc check_sqlite.c -lsqlite3 -o check_sqlite
./check_sqlite
这比只查看头文件中的 SQLITE_VERSION 更可靠，因为程序可能在运行时加载另一份动态库。
升级前后验证数据库完整性
升级数据库引擎前应先停止写入并备份数据库。数据库启用 WAL 时，不要在应用仍运行的情况下只复制主 .db 文件，因为尚未 checkpoint 的事务可能仍位于 -wal 文件中。
一种可操作的升级前检查流程如下。请把 app.db 和备份路径替换为实际值：
set -euo pipefail
DB="app.db"
BACKUP="app-before-sqlite-3.53.4.db"
sqlite3 "$DB" 'PRAGMA wal_checkpoint(FULL);'
sqlite3 "$DB" ".backup '$BACKUP'"
sqlite3 "$DB" 'PRAGMA integrity_check;'
正常情况下，完整性检查应输出：
ok
升级到 3.53.4 后，可以再次执行检查并确认日志模式：
sqlite3 app.db 'SELECT sqlite_version();'
sqlite3 app.db 'PRAGMA journal_mode;'
sqlite3 app.db 'PRAGMA quick_check;'
quick_check 适合部署后的快速验证，integrity_check 检查更全面，但在大型数据库上会消耗更多时间和 I/O。两者都不能替代可恢复的备份。
如果数据库由服务进程持续使用，建议通过应用自身的备份机制或 SQLite Backup API 创建一致性副本，而不是依赖普通文件复制。升级测试还应覆盖进程异常退出、重新启动、长事务、并发读取和 checkpoint 等真实工作负载。
不要把库升级等同于应用已经修复
SQLite 可以作为系统动态库存在，也可以通过 amalgamation 源码直接编译进应用。后者在移动端、桌面客户端和嵌入式程序中很常见。即使操作系统的软件包已经更新，静态链接或内置 SQLite 的应用仍可能继续运行旧版本。
排查时可以沿着实际交付链路逐层确认：
- 检查生产进程通过 SQL 或
sqlite3_libversion()报告的版本。 - 确认容器镜像、安装包和固件已经重新构建，而不只是更新构建机器。
- 对动态链接程序检查最终加载的库文件，避免误用系统中的旧副本。
- 对使用语言运行时或 ORM 的项目，在应用进程内执行
SELECT sqlite_version()。 - 保留升级前备份，并验证恢复流程，而不仅是验证备份文件存在。
采用建议
启用 WAL 的项目应优先评估 SQLite 3.53.4，并在与生产一致的并发和故障恢复场景中进行回归测试。没有启用 WAL 的项目也应确认间接依赖是否会切换日志模式，因为框架、驱动或初始化代码可能代为执行相关 PRAGMA。
升级时最重要的不是替换一个二进制文件，而是确认业务进程确实加载了 3.53.4、现有数据库通过完整性检查、备份能够恢复，并且 WAL checkpoint 与异常重启路径仍按预期工作。对于承载用户本地数据的应用，这组验证应成为发布清单的一部分。