navicat云端模型同步不能实现真正协同，本质是单向文件备份，无并发编辑、冲突检测或变更广播；export diagram to sql仅导当前图对象，不补全依赖表，易致建表失败。
navicat 的“云端模型同步”不能实现真正的多人协作设计。它只是把本地 .nmw 文件上传覆盖到 navicat cloud，不解决并发编辑、冲突检测、变更广播或依赖一致性问题。所谓“同步”，本质是单向备份，不是协同。
为什么 Export Diagram to SQL 导出的脚本总在生产环境报错
常见错误现象：FOREIGN KEY 指向的表未被导出，或字段类型与目标库不兼容（如 MySQL 8.0 的 JSON 字段在旧版中不支持）；Export Diagram to SQL 只导当前图内选中的对象，不会自动补全被引用但未出现在图里的表。
- 导出前必须右键该图纸 →
Refresh from Database，否则图中可能残留已删字段或过期索引 - 若图中存在跨图引用（如订单图拖入了 users 表），导出时不会提示缺失依赖，只静默跳过——结果就是建表失败
- 真正安全的做法是：用
Tools → Analyze Database逆向整个库生成新 ER 图，再从中筛选对象导出，而非依赖人工维护的图纸
Navicat Cloud 同步 .nmw 文件时最危险的操作
常见错误现象：A 修改模型后上传，B 下载覆盖本地文件，B 未提交的字段备注、颜色标记、连线布局全部丢失，且无任何冲突提示或 diff 预览。
- Navicat Cloud 不保存版本历史，每次上传都会覆盖上一版，无法回退
- 自定义元数据（如表备注、字段描述、图表注释框）在同步过程中会被清空，仅保留基础结构
- 模型文件超过 5MB 后，上传/下载变慢，且容易因网络中断导致文件损坏，重试后仍可能内容不一致
团队版 Navicat 的“协同合作”到底同步什么
它同步的是配置类元数据，不是模型逻辑状态。所谓“共享模型工作区”，实际只是把同一个 .nmw 文件在多个客户端间来回拷贝。
- 真正能同步的：连接配置、查询片段、虚拟组、BI 工作区 —— 这些是纯文本或结构化小文件，适合覆盖式同步
- 明确不同步的：表字段变更广播、外键依赖校验、图纸间引用关系一致性检查、模型语义冲突检测
- 如果团队需要留痕、审阅、并行修改，必须放弃
.nmw，改用文本化建模（如 Mermaid DSL 或 QuickDBD），然后走 Git 流程
多人同时编辑一个数据库模型，关键不在“能不能传文件”，而在“改了之后别人知不知道、要不要重做、会不会漏掉”。Navicat 的所有云端功能都绕开了这个核心问题——它把协作简化成了文件搬运，而真实协作里最难的，永远是人和人之间对“同一份事实”的理解对齐。
