navicat 的 er 图/模型文件不能防冲突，因其仅是本地快照，不感知数据库实际 ddl 变更，无服务端加锁、版本比对或审批流，且通常未纳入 git 管控，无法追溯修改；真正防冲突需依赖数据库权限控制、sql 脚本审核与 ci/cd 流水线等流程管控。
navicat 本身没有模型锁定机制，多人同时改表结构必然冲突，靠工具自动防护是徒劳的。
为什么 Navicat 的 ER 图/模型文件不能防冲突
Navicat 里保存的 .nsx 或 .nsm 文件只是本地快照，不参与数据库实际 DDL 执行。你画的 ER 模型再“锁得严”，只要另一个人直接在 SQL 编辑器里执行 ALTER TABLE users ADD COLUMN phone VARCHAR(20)，目标库结构就已变更——模型文件对此毫无感知，也不会报错或阻塞。
更关键的是：这些模型文件通常不纳入 Git 等版本控制，团队成员各自保存在本地，连“谁改了什么”都难追溯，谈不上协同保护。
- ER 模型 ≠ 数据库结构，它只是可视化草稿
- 模型导出的 SQL 脚本若未审核直接执行，反而放大风险
- Navicat 不提供模型编辑时的服务器端加锁、版本比对或提交审批流
真正能防止结构冲突的只有数据库权限与流程管控
防止崩溃的关键不是“锁模型”，而是“锁操作入口”。MySQL / PostgreSQL 本身不支持结构修改的乐观锁，必须靠人+权限+规范兜底：
- 开发库只给
SELECT、INSERT、UPDATE权限，禁用ALTER、DROP—— 所有结构变更必须走 DBA 审批的 SQL 脚本 - 测试/生产库严格限制连接账号，禁止用 Navicat 直连执行 DDL；只允许通过 CI/CD 流水线执行已 Review 的
schema.sql - 建表语句统一存 Git，每次变更附带
git blame可查责任人，分支策略强制 PR + 至少一人 approve - Navicat 仅用于查看、查询、生成初版脚本，不作为部署终端
如果非要靠 Navicat 辅助协同，只能做三件事
别指望它“自动防冲突”，但可降低人为失误概率：
- 所有人连接同一个开发库（而非各自本地库），用 Navicat 的「结构同步」功能定期比对——源设为 Git 中的
schema.sql导入的参考库，目标设为当前开发库，预览差异后人工确认是否执行 - 在 Navicat 同步向导的「选项」中，**务必取消勾选
Drop objects not exist in source**，避免误删线上已有字段 - 启用「比较 comments」和「比较 collation」前，先确认所有环境 MySQL 版本一致（如都是 8.0.33），否则同步可能生成非法语法（如零日期）
最易被忽略的一点：Navicat 的「结构同步」预览 SQL 是唯一能提前发现 DROP 风险的地方，但很多人跳过这步直接执行。只要没手动核对过生成的 ALTER/DROP 语句，所谓“防止崩溃”就只是心理安慰。
