Navicat Data Modeler 本身不处理模型合并冲突，其 .nmw 文件为二进制封闭格式，无版本语义和内置三路合并能力；冲突实际发生在 Navicat On-Prem Server 的模型工作区，表现为对象级元数据覆盖风险，需依赖手动命名约束、显式注释及提交前比对等事前规避策略。
Navicat Data Modeler 本身不处理模型合并冲突
navicat data modeler 是单机桌面工具，.nmw 文件是二进制、不可 diff、无版本语义的封闭格式。它没有内置的合并逻辑，也不支持 git 式的三路合并。所谓“解决冲突”，实际发生在协作基础设施层（navicat on-prem server 或 navicat cloud），而非 modeler 界面内。
冲突真实发生的位置：On-Prem Server 的模型工作区
只有当你把本地模型导入 Navicat On-Prem Server 并启用「模型工作区」后，多人编辑才可能触发冲突。此时冲突不是代码级的文本差异，而是对象级的元数据覆盖风险：
- 两个用户同时修改同一张表的字段长度 → 后保存者覆盖前保存者的变更
- 用户 A 删除外键，用户 B 同时给该外键加注释 → 注释丢失，且外键状态不一致
- 未命名的约束（如
fk_12345）被重复生成 → 工作区中出现重复或冲突的约束定义
Server 不会自动“合并”这些操作，而是按保存时间戳做最终写入 —— 这就是隐性冲突。
真正可用的冲突规避手段
靠事后“解决”不如事前规避。关键动作不是等冲突出现再处理，而是让模型结构本身具备可协同性：
- 所有外键、索引、检查约束必须手动命名（如
fk_order_user_id、idx_user_email），禁用 Navicat 自动生成的随机名 - 字段
COMMENT必须显式写入 SQL 导出内容（导出时勾选Export comments as SQL comments，并在建模界面里填好描述） - 避免直接在图形界面拖拽修改主键或列顺序 —— 这类操作容易引发隐式结构重排，改用
Model → Edit Table → Columns面板精确控制 - 每次向 Server 提交前，先用
Model → Compare Model对比本地与 Server 当前版本，人工确认差异范围
云同步场景下“放弃/保留/重命名”的局限性
Navicat Cloud 提供的“放弃服务器文件 / 保留本地副本 / 重命名本地副本”选项，只适用于整个 .nmw 文件级别的覆盖决策，对模型内部对象（表、字段、关系）无粒度控制。它解决的是文件同步冲突，不是模型语义冲突。
这意味着：如果你和同事各自改了同一张表的不同字段，Cloud 不会帮你合并这两处修改，只会让你选一个完整文件覆盖另一个。真正的协同必须依赖 On-Prem Server + 模型工作区 + 手动命名 + 显式注释这套组合，否则协作只是假象。
