工具笔记
让 AI 写 SQLite 备份脚本，再做一次恢复演练
使用数据库提供的一致快照并试着恢复。
资料核验2026.11.12 · SQLite · 本地数据库与小型服务
本地应用的数据库看起来只有一个主文件。开启 WAL 后，尚未检查点合并的已提交改动可能还在 WAL 文件里。此时只复制主文件，打开备份后可能看不到最后几次保存。
交给编码助手的任务
告诉助手当前数据库使用 WAL，并让它依据 SQLite 的备份方法生成快照。要求用独立路径恢复，验收关键表和最近一条已提交记录，整个演练用测试数据库。
用一致快照，验收恢复结果
优先用 SQLite 的备份接口，或使用文档所列的适用方法生成快照。别在数据库持续写入时，靠人工把几个相关文件分别复制来拼一次备份。
测试时新增一条可识别的记录，完成备份后把快照恢复到临时路径。检查最近记录、关键表行数和一条代表性的查询。
备份脚本报成功只说明动作结束。恢复能读到预期的数据，才说明这份备份真的可用。
先准备一个对照样例
在隔离库写入 backup-marker-42 并提交，备份后恢复到新文件。以一条业务查询和该标记行验收。若助手报告只比较了文件大小，让它真正打开恢复库执行查询，文件大小不能证明最后一次提交在里面。
用这些结果验收
- 备份包含刚提交的标记行。
- 恢复库能读关键查询。
- 原库没有被修改。
- 备份失败时不能把半成品当作可恢复快照。
审查时容易漏掉什么
开启 WAL 后主文件可能尚未合并最近的提交。助手若提议只拷贝一个路径，请它说明它为什么认为数据库处在可拷贝状态。优先用具有一致性保证的备份接口，最后以恢复证据判断。
恢复验收可以再查一份业务结果，例如最近一条文章的标题和更新时间，同时记录快照的生成时点。若只能恢复到旧数据，先调查快照方式和读写状态，别通过重跑查询或增大文件大小来掩盖。
