工具笔记
让 AI 缩短 SQLite 写事务：网络先完成，写入后开始
先准备数据，再用短事务完成本地写入。
资料核验2026.11.12 · SQLite · 本地数据库与小型服务
导入任务拿到一页数据，打开事务，逐条写入，写到一半还要请求外部接口补字段。另一个请求此时也要写库，等待时间一下变长。SQLite 允许多个连接读，同时仍只有一个写事务。
给 AI 的上下文与边界
给助手一条会在逐行写入时补请求的导入流程，要求它标出从 BEGIN 到 COMMIT 的每个等待点。把远端准备放到事务外，必须依赖数据库当前状态的业务检查留在写入时重新做。
把耗时准备留在事务外
先拉取和整理本页数据，再开启事务写入这一批。只有必须与写入一起判断的条件留在事务内。如果后一步失败，回滚整个批次，并在事务外记录失败。
用两个连接验收：第一个连接处理导入，第二个尝试写一条无关记录。确认网络延时发生时，第一个连接没有长期占着写事务。
切分批次时明确恢复位置。重跑一页应该可以重试，而不是追加出两份同样的记录。
可以直接照着做的演练
让导入任务在远端准备阶段等一秒，另一连接期间保存一条用户备注。然后在批次第二条写入制造错误，对照当前批次是否全部回滚。把联网延时、持锁时间和事务总耗时分别记下。
检查生成结果
- 在外部请求故意延迟时，第二连接仍能独立写入。
- 一批中间失败时该批不留半份数据。
- 重跑同一页不会制造重复记录。
复查时追问一层
短事务并不等于把所有校验移出事务。如果某项约束依赖并发状态，先保证数据库在写入时还能检查。把每批大小和恢复位置写清，便于评估总耗时与持锁时间。
如果远端数据在准备到写入之间可能变化，要求助手区分本地快照策略和必须重新检查的条件。短事务仍需约束业务不变量。用失败恢复点验证重复导入时既没有漏批次，也没有把已处理批次追加两遍。
