用途：该原则用于处理并发执行者可能同时写入同一文件、分支、键或状态对象的场景。核心问题是并发写入共享可变状态会产生间歇性、难以复现且调试成本高的竞态条件。
主要能力：提供一套判断与处理顺序。首先识别共享可变状态，例如双方都读写的文件、都推送的分支、都定义并消费的 API。默认做法是消除共享写目标，先追问这些执行者是否真的需要同一个规范对象，还是只是在发布彼此独立的事实；随后让每个执行者拥有自己的文件、键、分支或状态目录，只在读取或汇报的边界处合并。只有当同一个共享写目标确属真实不变量时，才在结构上串行化访问，可采用锁文件、顺序阶段、单写者执行者或原子比较交换。
使用方式：没有提供具体命令或代码。可依据文中的模式判断：两个 worker 各自把 lastX 字段写进同一个 state.json 仍属于共享变更；而 indexer-state.json 与 metrics-state.json 分开则不算。
适用场景：适用于存在并发写入的工程协作与系统设计，包括文件、版本控制分支、配置键和共享状态对象的管理。
限制：应把“我们需要一把锁”视为需要检查的设计气味，而非默认答案；指令和约定本身不构成并发控制。资料未提供具体实现示例、命令、性能数据或适用范围细节。