Navicat 17 数据字典工具本质是手动触发的快照式导出器，不支持自动扫描同步元数据变更；其权威来源必须是数据库原生COMMENT+Git管理的SQL脚本，导出仅作发布前验证。
直接上结论：Navicat 17 的数据字典工具本身不支持“自动扫描并同步上千张表的元数据变更”，它本质是手动触发+半静态导出的文档生成器。真正在大型团队里跑通数据字典协同，关键不在“用不用 Navicat”，而在于你是否把 data_dictionary 当作代码资产来管理——即版本化、结构化、可 diff、可 CI 检查。
为什么不能全靠 Navicat 自动更新数据字典
Navicat 的数据字典功能（通过 工具 → 数据字典 启动）本质是快照式导出：它读取当前连接下数据库的 information_schema 或系统视图，拼装成 HTML/PDF/Markdown 文档。它不会监听 DDL 变更、不记录修改人、不保留历史版本、不支持字段级变更比对。当团队每天执行几十次 ALTER TABLE，仅靠人工点“重新生成”会立刻脱节。
常见错误现象包括：
- 导出的字典里字段描述仍是“待补充”，但生产表已上线三个月
- 多人同时导出 PDF，文件名带时间戳却无版本号，无法判断哪个是最新权威版
- 某成员在 Navicat 里编辑了字段备注，但未同步到数据库的
COMMENT ON COLUMN，导致下次导出时丢失
必须把字段注释写进数据库，而不是只存 Navicat 本地
Navicat 能读取的字段说明，只来自数据库原生的 COMMENT 元数据（如 PostgreSQL 的 pg_description、MySQL 8.0+ 的 INFORMATION_SCHEMA.COLUMNS.COLUMN_COMMENT）。它不维护独立的注释存储。这意味着：
- 所有字段描述必须通过 SQL 写入数据库，例如：
COMMENT ON COLUMN users.email IS '主登录邮箱，经验证'; - 建表语句里必须带
COMMENT，不能依赖 Navicat 界面填完就以为生效 - Navicat 导出的数据字典，只是这些 COMMENT 的“只读投影”，不是源头
否则，一旦换用其他工具（如 psql、DBeaver）或做数据库迁移，所有描述信息直接消失。
用 Git + SQL 脚本替代 Navicat 手动导出
真正可协作的方案是绕过 Navicat 的导出按钮，改用脚本自动化提取 COMMENT 并提交到 Git：
- 为每个数据库建一个
schema/目录，存放001_create_users.sql、002_add_email_comment.sql等可执行脚本 - 用
psql -c "\d+ users"或自定义 Python 脚本从pg_description提取 COMMENT，生成 Markdown 表格 - 把生成的
data_dictionary.md和 SQL 脚本一起 commit，PR 时强制要求更新对应字段描述 - CI 流水线检查：若
ALTER TABLE脚本新增字段但没配COMMENT，则拒绝合并
Navicat 在这个流程里只承担两个角色：一是作为开发时快速查看 COMMENT 的 GUI 工具；二是用它的“模型工作区”反向生成建表初稿（但最终以 SQL 脚本为准）。
Navicat 17 协同服务器能解决什么，不能解决什么
Navicat on-prem server 支持同步 连接设置、查询、虚拟组 和 模型工作区，但它不同步数据字典内容本身。也就是说：
- ✅ 团队共用同一套模型文件（
.ndm），函数/过程定义可见、可评论 - ✅ 某人更新了模型里的字段说明，其他人打开模型就能看到（但这仍不是数据库真实 COMMENT）
- ❌ 导出的 HTML 字典文件不会自动推送到服务器，也不会触发通知
- ❌ 不支持多人同时编辑同一字段描述并自动 merge —— 它没有字段级锁或冲突解决机制
所以，哪怕用了 Navicat 17 协同服务器，数据字典的权威来源仍必须是数据库 COMMENT + Git 管理的 SQL 脚本。Navicat 的导出动作，只应作为发布前的手动验证步骤，而非协作主干。
