Navicat 17 的 .nmodel 文件不支持 Git 原生追踪，因其为二进制格式，导致 diff 无意义、无法合并、历史不可读；应将其视为构建产物，仅提交可审计的导出 SQL 和 model_summary.txt，并通过 On-Prem Server 实现带版本说明、权限控制和编辑锁定的模型协同。
Navicat 17 的 .nmodel 文件本身不支持 Git 原生追踪
Navicat 17 的模型文件（.nmodel）是二进制格式，不是纯文本 XML 或 JSON。直接丢进 Git 仓库会导致：diff 无意义、无法合并冲突、历史版本不可读、CI/CD 工具无法解析结构变更。很多团队误以为“只要文件进了 Git 就算版本控制”，结果在三人协作时出现模型覆盖、关系线丢失、字段类型回退等问题。
真正可行的路径是：把 .nmodel 当作构建产物，只提交其上游可审计、可 diff 的中间表示。
- 每次修改模型后，必须手动导出为
.sql脚本（使用「文件 → 生成 SQL 文件」），勾选「创建数据库」「创建表」「创建外键」，并保存为schema_v20260907.sql这类带日期/版本号的命名 - 同时导出一份结构快照
model_summary.txt：右键模型画布 →「验证模型」→ 复制输出中的「表数」「外键数」「警告条目」粘贴进去，用于人工比对 -
.nmodel文件仅保留在本地工作区或团队共享网盘（如 Navicat On-Prem Server），不纳入 Git
用 Navicat On-Prem Server 替代 Git 做模型协同
Navicat 17 内置的 On-Prem Server 是更贴近实际协作场景的选择——它不是代码托管，而是模型状态托管。关键在于它记录了谁在什么时间点发布了哪个版本的模型，且支持权限隔离。
- 模型发布前，必须先点击「模型 → 发布到服务器」，填写版本说明（例如：“修复 orders.user_id 外键引用大小写错误”），不能留空
- 团队成员从 On-Prem Server 拉取模型时，会自动下载配套的
.sql导出物和model_summary.txt，避免本地重新生成时因驱动/版本差异导致字段错位 - 服务器端不允许多用户同时编辑同一模型；第二人尝试编辑时会提示「该模型已被
zhangsan@2026-09-07 14:22锁定」，强制串行化修改
同步模型到数据库前必须比对 SQL 差异
「同步到数据库」按钮在 Navicat 17 中本质是执行全量重建，它不会调用 mysqldiff 或 pg_dump --schema-only 做结构比对。所谓“同步”，就是暴力 DROP TABLE + CREATE TABLE，哪怕你只改了一个 VARCHAR(50) 到 VARCHAR(100)。
- 安全做法是：先用「文件 → 生成 SQL 文件」导出当前模型的 DDL，再用命令行工具比对：
diff -u prod_schema.sql dev_schema.sql - 重点关注三类变更：
FOREIGN KEY行是否新增/删除、ENGINE=InnoDB是否被误转为MyISAM、JSON 字段是否在 MySQL 5.7 环境下被生成为LONGTEXT - 若发现
DROP TABLE操作，立刻中止，改用手动ALTER TABLE语句补丁，尤其当目标库已有千万级订单数据时
模型文件共享时最容易被忽略的元信息
一个 .nmodel 文件里藏着四层隐性依赖，缺一不可，但 Navicat 17 不在 UI 上显式标出：
- 模型属性中设定的数据库类型与版本（如
MySQL 8.0），必须和目标库SELECT VERSION()输出完全一致，否则 JSON/Generated Column 会静默失效 - 连接所用的驱动类型（
MySQL (Native)vsODBC）会影响外键元数据读取精度，逆向工程后导出的 SQL 可能漏掉ON UPDATE CASCADE - 模型内所有表名/字段名是否撞了保留字（如
order,group），Navicat 默认不加反引号，但导出 SQL 在真实库执行时直接报ERROR 1064 - 外键引用的父表名大小写是否 100% 匹配（
users≠Users），模型校验器（Validate Model）会报 warning，但很多人忽略它
这些不是“高级技巧”，而是每次打开 .nmodel 后必须扫一眼的硬性检查项。跳过就等于把 ER 图当草图用，迟早在线上建表时报错。
