不能直接拖.nmw文件进团队协作环境——它是二进制本地快照，无版本、不可diff、无法合并；必须先导出为SQL或XML，再通过正向/逆向工程重建为可协作的模型工作区（.nmodel），且团队协作必须基于导出的XML文件进行结构级diff和变更评审。
直接拖 .nmw 文件进团队协作环境会失败
不能把本地 .nmw 文件复制粘贴到 navicat on-prem server 里——它不是协作单位，而是二进制快照，无版本、不可 diff、无法合并。强行导入会导致多人编辑后模型失联、git 提交全是“文件已修改”却看不出改了什么。
- Navicat 16/17 的团队协作依赖的是「模型工作区」（
.nmodel），不是单个.nmw - 旧版
.nmw必须先导出为 SQL 或 XML，再通过正向/逆向工程重建为可协作对象 - 导出时务必取消勾选
Include DROP TABLE，并启用Use IF NOT EXISTS避免同步时误删表
导出模型必须用 XML，不是 .nmodel
.nmodel 是二进制格式，Git 看不到字段增删或注释修改；团队协作必须靠 .xml 文件做结构级 diff 和变更评审。
- 右键模型工作区 →
Export Model to XML，生成人类可读、Git 可比对的文本文件 - XML 文件需统一存放在项目仓库的
/models/目录下，命名如user_service_v2.xml - CI 流程中可加校验脚本：对比
git diff HEAD~1 -- models/*.xml是否含<column name="created_at"></column>类结构变更 - 禁止跳过 XML 直接改
.nmodel后同步——这等于绕过评审，高概率引发线上 DDL 冲突
同步前必须手动清理三类默认陷阱
刚从 .nmw 导入的模型在 On-Prem Server 里看似正常，但不处理以下三项，协作两天就会出问题：
-
外键约束名：Navicat 自动生成的fk_abc123每次导出都不同，Git 提交后全是噪音。应在模型中为每个 FK 手动设固定名，如fk_order_user_id -
字段注释：图形界面填的 Comment 不会自动转成 SQL 注释。必须补上-- @desc 用户注册时间标记，并确认导出选项启用Export comments as SQL comments -
MySQL 版本兼容性：模型中若用了JSON类型但目标库是 MySQL 5.7，同步会失败。需在模型属性里显式设置目标版本（如MySQL 8.0）
多人编辑本质是副本分发，不是实时协同
Navicat 17 不支持多人同时编辑同一个 .nmodel 文件——所谓“共享”，是 On-Prem Server 给每人发一份副本，各自改完再提交。冲突只能靠 XML diff + 人工合并解决。
- A 修改模型并导出
user_v3.xml提交 Git，B 拉取后本地打开该 XML → 新建工作区 → 逆向工程导入，才能获得一致起点 - 若 B 在 A 提交前就自己改了本地
.nmodel，再同步到服务器，会导致两份结构不一致，且 Navicat 不提示、不报警、不回滚 - 团队必须明确 Owner 角色：所有结构变更由一人审核 XML 差异后，才允许执行「同步到数据库」
真正卡住团队的，从来不是怎么导出，而是谁来审 XML、谁有权点同步、以及出错后怎么回退——这些得写进 SOP，不能靠口头约定。
