.ndm文件本身是跨平台的XML格式,但实际迁移时问题多源于外部引用:绝对路径导致资源无法加载、硬编码字体在目标系统缺失、中文注释因ANSI/UTF-8编码不一致而乱码,以及不可见字符引发渲染异常。
模型文件本身不绑定环境,但路径和字体设置会拖后腿
navicat data modeler 的 .ndm 文件是纯 xml,结构定义(表、字段、关系、注释)天然跨环境,但实际迁移时出问题的几乎全是「外部引用」。比如模型里插入了一张 /users/alex/logo.png,换到 windows 就显示红叉;又或者强制设了 font-family: "sf pro display",linux 上没这个字体,文字就挤成一团。
实操建议:
- 所有图片、图标用相对路径插入,并把资源文件和
.ndm放在同一目录下(如model/目录里放schema.ndm和assets/logo.png) - 字体设置留空——让 Navicat 用各系统默认 UI 字体,别硬写具体名称
- 避免在模型注释里混入不可见字符(如 U+200B 零宽空格),这类字符在 macOS 和 Windows 渲染逻辑不同,容易导致对齐错乱或导出失败
同步前必须先“转换目标数据库类型”,不能跳过这步
你在一个 MySQL 模型上画完 ER 图,想同步到 PostgreSQL 生产库?直接点“同步到数据库”会出问题:Navicat 不会自动帮你把 ENUM 转成 TEXT 或自定义 TYPE,也不会保留 BTREE 索引声明——PostgreSQL 只认 btree,其他索引类型会被静默丢弃。
正确流程是:
- 右键模型 →
工具→转换模型→ 选目标数据库类型(如PostgreSQL 15+) - 转换后检查“数据类型映射”面板,手动修正不匹配项(如把
TINYINT(1)改成BOOLEAN) - 再执行
工具→同步到数据库,此时生成的 DDL 才真正适配目标库
连接信息不在模型里,同步时得手选,别指望自动带过去
.ndm 文件不存任何连接凭证,也不记录 SSH 隧道、SSL 配置或代理设置。你在本地模型上右键“同步到数据库”,弹出的对话框里,“目标数据库”下拉列表只显示当前 Navicat 已配置的连接——如果生产库连接还没建好,这一步就卡死。
高频踩坑点:
- 误以为模型里“绑定了”某个连接,结果换电脑打开模型,同步按钮灰掉(因为新机器没导入连接)
- 在测试环境同步成功,到生产环境却连不上,其实是漏配了
sslmode=require或跳板机隧道 - 上百个环境连接没分组,找“prod-us-west-postgres”翻半天,最后点错成“staging-us-west-postgres”,DDL 执行到错误库
建议提前用 navicat:// URI 批量导入连接,并按 业务线/环境/云厂商 建嵌套分组,同步时直接从对应分组里选。
中文注释乱码?先看文件头,再换编辑器
旧版本 Navicat(v12–v14)在 Windows 上默认用系统 ANSI 编码读写 .ndm,一迁到 macOS 或 Linux,中文注释全变问号。这不是模型坏了,是编码声明没对齐。
判断依据很简单:用 VS Code 打开 .ndm,第一行是不是 <?xml version="1.0" encoding="UTF-8"?>?不是就说明有问题。
修复方法:
- 在源系统用 Navicat v15+ 打开模型 →
文件→另存为→ 覆盖原文件(v15+ 默认强制 UTF-8) - 绝对不用 Windows 记事本编辑
.ndm——它保存时会偷偷转成 ANSI,且不提示 - VS Code 里右下角确认编码是
UTF-8,且勾选“保存时不带 BOM”
跨平台维护模型最麻烦的从来不是功能,而是那些看不见的隐式依赖:路径、字体、编码、不可见字符。它们不报错,但会让模型在某个环境里“看起来不对劲”,排查起来比语法错误还耗时间。











