# #2 【承接自 10-14】【8190 待办后端·根治并发写竞态（最稳妥方案）】问题（用户 2026-10-14 指出，晚风核实代码确认）：todo_server.py（/home/zyf/手机待办/todo_server.py，PORT=8190）所有写操作都是「read_md() 读全文 → 改 → write_md() 整份写回」，write_md 用 os.replace 只保证写入原子性、**不保证不丢更新（lost update）**；服务是 ThreadingHTTPServer 多线程 → 页面多请求 / AI 直接改文件 / 多设备同时操作 → 互相覆盖，**条目会凭空消失**（已实测到"插入位置错乱"这一表现）。用户要求：**用最稳妥的方法，哪怕再麻烦也没关系**。要做的：① 服务端加锁：threading.Lock（进程内）+ fcntl.flock(MD，跨进程) 把「读-改-写」整段包起来 —— 覆盖所有写路径：/add /toggle /edit /delete /supplement /rework /toggle_arch /add_archive，以及 realign_day、park_log_to_ops、save_state(task_state.json)、夜间对账 _nightly_loop；② 强烈建议**直接换 SQLite**（WAL 模式 + 事务）做唯一数据源，待办.md 降级为"导出视图"，从根上消灭 lost update（用户说"再麻烦也没关系"→ 倾向这条）；③ 纪律：所有 AI/脚本（含晚风）**禁止再直接改写 待办.md**，一律走服务端接口（/add、/edit…），接口内部串行化；④ 改前 cp -a todo_server.py + 待办.md（后缀 .bak_20261014_并发根治）；⑤ 验收：并发压测（同时 curl 打 /add 20 条 + 同时手动改文件），20 条一条不丢、序号连续无错位、重启服务后数据一致。相关文件 /home/zyf/手机待办/todo_server.py、~/桌面/待办.md（改前备份 + 重启 8190）。来源：用户 2026-10-14「这个机制很有可能变成大问题」「用最稳妥的方法，哪怕再麻烦也没关系」。

归属日期: 2026-10-18
序号: 2
当前状态: ✅ 已通过（第1次）
被接手次数: 1

该任务出现时间为
2026-10-18-本次第一次

---

## 2026-10-18 第1次
- 执行者: 幽灵
- 做了什么:
- 证据（真命令 + 原始输出）:
- 结论:
- 遗留/卡点:

## 2026-10-18 验收通过
- 验收人: 用户
- 备注: （无）