并发写共享状态前先拆分再串行化

当多个并发执行者可能写入同一文件、分支、键或状态对象时，先消除共享，再考虑结构化串行化。

适用场景

解决思路

1. 识别共享可变状态：找出被多个执行者同时读写的内容，例如双方都读写的文件、都推送的分支、既定义又消费的 API。
2. 默认做法是消除共享写入目标：先问这些执行者是否真的需要同一个规范对象，还是只是在发布各自独立的事实；若是后者，就给每个执行者分配各自拥有的文件、键、分支或状态目录，只在读取/汇报边界做合并。注意：两个 worker 各自把 `lastX` 字段写进同一个 `state.json` 仍属于共享变更；而 `indexer-state.json` 与 `metrics-state.json` 分开则不算。
3. 仅当同一个共享写入目标确实是硬性不变量时，才用结构化方式串行化访问：使用锁文件、顺序阶段、单写入者执行者，或原子 compare-and-swap。把“我们需要加锁”当作需要审视的设计异味，而不是默认答案。

适用边界 · 注意事项

• 当多个执行者确实必须维护同一个规范对象、无法拆分为各自独立状态时，不能简单消除共享。
• 当共享写入目标属于真实不变量时，不能只靠约定或说明来替代结构化串行化。