两个系统对同一条主数据的操作撞在一起，轻则字段被覆盖，重则客户或物料出现重复、被误删。问题往往不是同步程序没跑，而是合并规则没定清楚。下面按“现象→可能原因→排查顺序→预防措施”逐一拆解。
现象：主数据越同步越乱，先判断属于哪一类冲突
常见的表象有三类。一是同一条记录在两个系统里字段值不同，一端刚改完又被另一端改回去；二是同一个对象出现多条记录，编码不同但名称相同；三是下游系统还在引用某条数据，而上游已经把它删除。
这三类问题对应三种操作：新增冲突、修改冲突、删除冲突。排查前建议先把冲突实例按这三类归堆，否则会把编码规则问题误判成合并规则问题。
一个实用判断是：看冲突记录是否有明确的“最后修改方”。如果两端都有修改且缺少时间依据，多数不是网络延迟，而是优先级没定义。
新增冲突：先统一编码主键，再谈优先级
新增冲突最常见的场景，是两个系统各自新建了同一个供应商或物料。此时字段值不一致只是表象，根因是主键或唯一业务键的生成规则没有收口。
建议先问三个问题：由哪个系统负责分配编码？编码是全局唯一还是按系统前缀分段？名称、统一社会信用代码、物料规格中，哪一个组合可以做业务判重键？这三项不确定，后面任何合并规则都站不住。
- 编码主责系统必须唯一，其他系统的申请请求回主责系统受理后再下发。
- 业务判重键要避开描述性字段，避免带空格、简称、全半角差异导致判重失效。
- 冲突的新增记录不要写成两条并存，应先标记为待人工合并，合并后保留一条主记录。
- 清理重复前要评估下游引用关系，尤其被流程、单据、报表引用的记录。
这类判断往往和整体系统集成架构一起考虑。需要具体实施方案时，可以参考我们的软件定制开发与系统集成服务，先做编码体系与接口契约的统一设计。
修改冲突：字段级优先级比系统级优先级更可靠
很多方案只规定“以哪个系统为准”，上线后仍会出问题。原因是主数据里不同字段的权威来源并不相同：联系人信息可能以协同办公侧为准，价格与规格可能以业务系统为准。用一个系统给所有字段定优先级，必然有一批字段被错误覆盖。
更稳的做法是做到字段级。为每个字段标注权威系统，同步时只允许权威来源写入该字段，其余系统的修改进入待审或只读。
- 时间戳不能单独作依据，跨系统时钟不一致时“最后写入”会误判，建议以版本号或业务动作时间配合。
- 给每个字段记录来源系统与更新时间，出问题时能追溯是哪一次同步写入的。
- 对地址、电话这类多源可写字段，建议指定唯一权威源，避免两端各写一半形成拼接数据。
- 合并策略要在接口层集中实现，不要让每个对接点各自处理。
修改冲突还容易和同步延迟纠缠在一起：看起来是以旧覆盖新，实际上是乱序。可参考我们整理的技术实现细节中关于顺序保证的通用做法，再结合业务判断。
删除冲突：先降级为停用，再按引用关系决定
删除是三类操作里风险最高的。一端执行物理删除后同步到另一端，往往直接导致下游单据丢失关联。因此建议默认规则是：主数据不做物理删除，统一改为停用并在同步中传递状态。
真正需要物理删除的，只应是录入错误且尚无引用的数据。是否可删，先查被引用的对象是哪些。
- 确认删除请求来自权威系统，非权威侧的删除视为无效并打回。
- 查询该记录在下游是否被流程、单据、报表引用，引用存在时拒绝删除并提示改为停用。
- 允许停用的记录不再参与新增与选择，但历史单据仍能解析。
- 删除与停用动作都要写审计日志，保留操作方与时间，便于回溯。
在不同行业里，这套规则还涉及系统和人员。制造与供应链场景里主数据引用链更长，可参考同类项目案例中的处理方式，再结合自身业务裁剪。
逐项排查顺序：先止血，再定规则，最后补防重
线上已经出现冲突时，不建议一上来改代码。按下述顺序推进，每一步都有明确产出。
- 暂停相关同步任务，避免冲突继续扩散，同时保留现场日志。
- 导出冲突记录清单，按新增、修改、删除三类归档，统计涉及的系统范围。
- 检查唯一键与编码规则，确认重复数据是否源于判重键不一致。
- 核查字段权威来源，找出被错误覆盖的字段及覆盖方向。
- 检查删除与停用的处理逻辑，确认是否存在物理删除导致下游断链。
- 检查接口层是否有统一合并处理，还是各对接点各自为政。
- 建立对账任务，把差异清单产出频率固定下来，作为验收依据。
- 把规则写入接口契约与文档，再逐步恢复同步任务，观察对账结果。
预防措施：把优先级与合并规则写进契约
真正减少冲突的不是补丁，而是交付阶段就把规则写清楚。数据字典里应有字段权威来源，接口文档里应有合并策略与冲突返回方式，验收标准里应有对账结果要求。
上线后保留日对账加异常告警，异常量激增时先停同步再查原因，比事后逐条修数据省力得多。对于政府单位与集团型企业，这套规则还关系到权限与审计，具体要求可以参考我们的政府与国企国产化改造案例中关于数据治理的做法。
如果你的多个系统已经互相覆盖、重复记录反复出现，可以联系我们与我们沟通，按现有系统梳理一份数据权威矩阵再定方案。
自查清单：主数据同步规则八问
- 每个主数据对象，是否明确了唯一的编码主责系统？
- 业务判重键是否经过全半角、空格与简称的规范化处理？
- 每个可同步字段，是否标注了权威来源系统？
- 修改冲突时，是否以版本号或业务动作时间为依据，而不是只看本地时间？
- 删除是否已默认降级为停用，物理删除有条件与审批？
- 合并策略是否集中在接口层实现，而非分散在各对接点？
- 是否定期输出对账差异清单，并有对应处理责任人？
- 冲突发生时是否先停同步再排查，日志是否保留？
这份清单建议在需求评审与上线验收两个节点各过一遍。规则清晰之后，同步任务才能从反复救火变成可维护的常规工作。更多技术实现细节也整理在栏目里，可作为后续对接的参考。
