崩溃恢复 产品与架构
别名：
WAL
进程被杀（SIGKILL、segfault）后数据怎么活下来的机制：`journal_mode=WAL` + `synchronous=NORMAL` 下，已提交事务的数据先顺序追加进 `-wal` 日志文件，SQLite 下次打开数据库时自动回放 WAL，已提交事务一条不丢——崩溃恢复不靠你的 `finally` 块，而靠数据库引擎自己的日志。
它是什么
崩溃恢复回答本章最尖锐的问题：进程被杀（SIGKILL、segfault）后数据怎么活下来？ 答案藏在建表时那句 PRAGMA journal_mode = WAL 里。WAL（Write-Ahead Logging，预写日志）是 SQLite 的日志模式：写入不直接改主数据库文件，而是先顺序追加到 -wal 日志文件；主库文件只在检查点（checkpoint）时合并。配合 synchronous = NORMAL：
- 进程崩溃：已提交事务的数据在 WAL 文件里（写系统调用已完成），SQLite 下次打开数据库时自动回放 WAL，已提交事务一条不丢；
- 断电：那是更强的保证，需要
synchronous = FULL（每个事务都 fsync 到磁盘）；默认 NORMAL 不保证断电场景。
一句话理解
SIGKILL 这类「来不及运行任何清理代码」的崩溃，正是 WAL 最典型的适用场景——崩溃恢复不是靠你的 finally 块，而是靠数据库引擎自己的日志。demo 就做了这个实验：服务进程被 SIGKILL 后重启，同一数据库文件打开，会话原样回来。
坑
别忘了 WAL 会产生 -wal / -shm 两个伴生文件——备份/拷贝数据库时只拷主文件，会把没检查点的已提交数据丢在外面。完整语义与实验见第 10 章。