WAL 改善读写并发，任务防重仍靠事务 W A L   改 善 读 写 并 发 ， 任 务 防 重 仍 靠 事 务

发送脚本是定时任务拉起来的瞬态进程:每半小时醒一次,干完就退。它可能在任何时刻被 taskkill、被系统重启、被我手抖 Ctrl-C 掉。

一开始的方案是在应用层加锁:进程启动时写一个锁文件,退出时删掉。逻辑很直白,问题也很直白 —— 进程被强杀时不会执行退出逻辑,锁文件留在那里,下一次定时触发看到锁就跳过。表现是发送静悄悄地停了,而且没有任何报错,因为从程序的角度看它"正常地跳过了"。

这类遗留锁文件导致的停发我恢复过一次，靠的是发现当天发送量是 0。它是退出清理未执行造成的状态问题，不能概括为所有应用层锁都会死锁。

SQLite WAL 允许读写并行，但同一时刻仍只有一个写事务，也可能返回 SQLITE_BUSY。WAL 改善数据库并发，领取发送任务与更新状态仍需要事务和业务条件来约束。

真正学到的是把故障边界拆开：不能只依赖正常退出时的清理，也不能把数据库连接关闭当成业务任务已正确完成。数据库事务、任务状态和外部发送结果需要分别核对。