断网时，维修工程师和调度员可能同时修改同一张工单：工程师改了处理结果，调度员改了派工时间。网络恢复后，系统必须决定这两份修改如何合并。这个决定不能交给代码自动完成，因为代码只懂比较，不懂业务。离线冲突的裁决权，本质上属于业务方，不属于开发方。
技术只能提供机制，不能替业务做取舍
离线场景不存在真正的实时一致。设备断网期间，本地数据与服务器数据各自演进，恢复连接后只能做合并。合并意味着取舍：保留谁的修改、丢弃谁的修改、还是把不同字段分开保存。每一种选择都有业务代价。按最后修改时间取胜，实现最简单，但会系统性惩罚操作慢、网络差的人，而且设备时钟并不可靠。按角色优先级取胜，符合组织权责，却可能让一线现场的真实记录被后台覆盖。字段级合并更贴近现实，A 改数量、B 改备注，各存各的，但需要提前定义哪些字段可以并行修改、哪些字段互斥。
这些不是技术选型，而是业务规则。开发方可以说明每种规则的成本和后果，但没有资格替客户判断“数量”和“备注”哪个更重要。
拍板的人要能承担错误代价
裁决规则应该由业务负责人牵头，一线使用者参与，开发方只提供选项。判断依据通常有三条：数据出错时哪一方损失更大、哪一类角色对哪类字段更有发言权、冲突提示出现后用户是否有能力自行判断。规则越细，开发工时越长，这个代价必须由提出规则的人知情并接受。
合同里要写清楚三件事：断网状态下具体能改哪些字段；冲突发生时用户看到什么提示；哪些操作必须联网才能完成。只写“支持离线使用”是不够的，这句话既不说明能否录入，也不说明冲突怎么处理。
规则先于实现
冲突裁决不是上线前才补的技术细节。它决定了同步逻辑的结构、字段的拆分方式，以及后端接口的设计。规则没定清楚就开工，后期每改一次规则，都要重新改动一遍同步代码。反过来，先把数据流向、角色权限和冲突处理方式画出来，再谈实现，报价和工期才有可靠依据。技术负责让规则稳定执行，业务负责让规则站得住脚，这条边界越早划清越好。
