Navicat不导出JSON模型文件，仅支持.sql、.xmi（XMI 2.1）、.csv三种可Git管理的文本格式；.ndm为二进制模型文件，无法diff；真正可用于版本对比的是配套导出的.sql（含外键与注释）和.xmi（严格描述实体关系），需统一编码、LF换行并验证完整性。
.ndm 文件不能直接用于 Git 对比，但你问的“JSON模型文件”其实并不存在——Navicat 根本不导出 JSON 格式的模型文件。它导出的模型只有三种可 Git 管理的文本格式：.sql、.xmi（XMI 2.1）、.csv（术语表），而所谓“JSON 导出”仅适用于数据行内容，且输出是非法 JSONL，与模型无关。
Navicat 压根没有“JSON 模型文件”这个东西
很多人误以为 File → Export → To JSON 是导出模型结构，其实那是导出**当前查询结果的数据行**（类似 SELECT 输出），和 ER 图、外键关系、字段注释等模型元数据完全无关。.ndm 是唯一承载模型定义的文件，但它始终是二进制格式，不可读、不可 diff。
-
.ndm文件在 Git 中表现为“binary”，git diff只显示Binary files a/model.ndm and b/model.ndm differ，无法定位改了哪个字段 - Navicat 16/17 的「Export to JSON」菜单项只出现在「查询结果」右键或导出向导中，不在「Data Modeler」主界面里
- 即使强行把
.ndm改后缀为.json，文件头仍是PK\x03\x04（ZIP 签名），不是 JSON 文本
真正能 Git diff 的模型导出格式只有两个
必须用 Navicat Data Modeler 的「File → Export」子菜单，手动导出两份配套文本文件：
-
.sql：含CREATE TABLE、ALTER TABLE ADD CONSTRAINT等 DDL，可用于本地数据库验证，但字段顺序、注释位置易受导出设置影响，diff 结果可能噪音大 -
.xmi（XMI 2.1）：XML 格式，严格描述实体（UMLClass）、属性（UMLAttribute）、关联（UMLEndPoint）三层结构，Git diff 能清晰看出谁删了 - 两者必须同时导出、同名保存（如
user_auth.sql+user_auth.xmi），缺一不可——SQL 验证物理执行，XMI 保障逻辑一致性
导出时最容易被忽略的三个参数
导出质量直接决定 Git diff 是否有用。以下选项不勾选，.sql 和 .xmi 都会丢失关键信息：
- 导出 SQL 时：务必勾选
Include Foreign Keys和Include Comments，否则外键约束和字段说明不会写入文件 - 导出 XMI 时：必须选
XMI 2.1（不是 2.0 或其他），Navicat Linux 版对 XMI 2.1 解析最稳定；Windows 导出的 XMI 在 Linux 导入时若选错版本，会报Invalid XMI content - 统一编码：所有导出文件默认 UTF-8 无 BOM，但若用 VS Code 等编辑器二次打开并保存，可能偷偷加 BOM——Git 会把 BOM 差异当作整行变更，导致虚假冲突
为什么你 diff 出来全是乱码或空行？
常见于跨平台协作场景，本质是换行符和路径处理失当：
- Windows 导出的
.xmi文件含\r\n，Linux Git 默认配置会自动转成\n，但 Navicat Linux 版导入时若检测到混合换行，会静默截断后续内容，造成.xmi文件末尾缺失 -
.gitattributes必须配置：* text eol=lf强制所有文本用 LF，否则git status总提示 “modified: model.xmi” 却看不出改了啥 - Navicat 不校验 XMI 文件完整性，导入失败时既不报错也不提示，只是模型画布空白——此时应直接用
xmlstar --validate model.xmi检查是否 well-formed
真正的模型 Git 协同，从来不是靠“让 Navicat 支持 JSON”，而是放弃幻想，用 .xmi 做逻辑层比对、.sql 做执行层验证，并把编码、换行、路径大小写这些底层细节钉死。否则每次 git pull 后打开 Navicat，看到的大概率是“Invalid model file format”或一片空白的画布。
