一项能力能否长期维护，不取决于演示是否成功，而取决于团队能否解释每个状态、每次重试和每一份残留数据。 WAL 允许读写并行但仍只有一个 writer。长读事务会阻止 checkpoint 回收旧页，使 WAL 持续增长并把延迟推到后续写入。
数据设计需要同时说明原子写入、并发读写、版本迁移、崩溃恢复和清理策略。能成功保存一次不代表断电、空间不足或旧版本重开时仍保持一致。
设计时必须回答的问题
先把下面几项写成可评审的规则，而不是散落在回调和界面判断里。规则越清楚，后续扩容、兼容和排错越少靠猜。
- 设置合理 busy_timeout，写事务只包含数据库操作，分页读及时关闭；监控 WAL bytes、checkpoint result、fsync 与写锁等待。
- 先定义正常、降级、取消和失败四类终态，再让界面、存储与指标消费同一状态。
- 重试必须带幂等键、退避和截止时间；超过截止时间后建立新任务，而不是继续复活旧回调。
“SQLite WAL 并发：单机服务快，但检查点会突然变慢”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
边界情况不是附加项
不要把异常路径理解成弹一次提示。它还包括在途工作如何停、对端如何获知、残留数据如何处置，以及下一次操作是否会继承旧状态。
- 在事务里调用网络 API 会长期占 writer；直接复制活跃 db 文件而不带 WAL/SHM 可能生成缺少最近提交的备份。
- 只修正界面状态而没有清理底层资源，下一次操作继承队列、锁或过期凭据并再次失败。
- 只在理想数据量下测试，真实的大文件、长会话或高并发会越过隐含上限并产生级联故障。
用证据确认它真的可用
用已知输入和可控故障建立金样本，然后把线上低基数指标与测试结果对齐。只有指标能提前识别同类退化，验证才真正延伸到生产。
- 并发短写与一个故意长读，期间触发 checkpoint、磁盘接近满和进程 kill，验证恢复完整性与 p99 写延迟上限。
- 在操作中途断网、切换网络并恢复，核对两端状态、持久化记录和资源计数最终一致。
- 发布前记录成功率、p50/p95/p99 延迟、错误分类和资源高水位，并为回退条件设定明确阈值。
可以上线的标准是：用户知道当前发生了什么，系统在异常后能停止或恢复，资源不会无界增长，运维也能从最小必要证据定位阶段。