navicat多图纸模型工作区非协同工具，仅支持单机本地建模；多人共用.nmw文件会导致无提示覆盖、版本不兼容及无法git比对；真协同需以sql脚本为核心，通过git管理ddl，navicat仅作可视化与sql导出终端。
navicat 多图纸模型工作区根本不是协同工具
navicat 的「多图纸模型工作区」本质是单机本地建模功能，不提供实时协作、版本合并、冲突解决或权限控制。所谓“协同”只能靠人工交接 .nmw 文件，或导出为 .sql / .png 后手动同步，架构师若误以为它能替代 dbt、git + liquibase 或在线 erd 工具（如 draw.io + github），项目中期大概率会卡在模型对不齐、变更不可追溯上。
多人共用一个 .nmw 文件会发生什么
Navicat 不支持文件级并发写入。当两人同时打开同一 .nmw 文件并保存时：
- 后保存者会直接覆盖前者的全部修改，无提示、无合并、无历史快照
- 若其中一人用的是旧版 Navicat（如 15.x），而另一人用 16.x+，打开时可能报错
"Unsupported model version" -
.nmw是二进制格式，无法用git diff查看差异，也无法做 CR（Code Review）
真要协同，必须绕过 Navicat 原生工作区
把 Navicat 当作「只读可视化终端」+「SQL 导出器」，核心模型生命周期交给文本化、可版本化的流程：
- 用
CREATE TABLE脚本定义表结构，存入 Git 仓库，分支管理（如dev-model、prod-model） - Navicat 中通过
正向工程 → 导入 SQL 文件加载模型，而非手工拖拽建表 - 模型调整后，用
反向工程 → 导出为 SQL生成 DDL，人工比对、拆解、提交到对应分支 - 关键字段注释、索引策略等元数据，必须写进 SQL 注释（如
-- @desc 用户状态枚举），不能只存在 Navicat 图形属性里
导出 SQL 时最常踩的三个坑
Navicat 默认导出行为与生产环境脱节，不加干预极易埋雷：
-
导出选项 → "包含 DROP TABLE"默认勾选：本地测试没问题，但上线执行会清空线上表 —— 协同场景下必须取消勾选 -
导出选项 → "使用 IF NOT EXISTS"在 MySQL 5.7 下不生效，但 Navicat 16+ 默认启用，导出语句在老环境执行直接报错ERROR 1064 - 外键约束名（
CONSTRAINT `fk_user_order`）默认由 Navicat 自动生成，每次导出都不同，导致 Git 提交大量无意义变更 —— 应手动在模型中为每个 FK 指定稳定名称
模型协同真正的复杂点不在怎么画图，而在谁改了哪个字段、为什么改、改之前有没有评估下游依赖。Navicat 的图纸只是快照，不是信源。
