必须使用Git管理的schema.sql或CI写入的“主干结构库”作为源库，禁用Drop missing objects in target，改用Alter table模式并手动检查在线变更支持性，外键名、注释等隐性差异需人工管控，.nsx文件不可直接共享，应交付SQL脚本或合并至Git迁移目录。
结构同步前必须确认源库是“权威结构”而非队友本地库
很多人误把同事刚连上的测试库当源，结果把对方还没提交的草稿结构推到共享目标库。Navicat 的 Structure Synchronization 不区分“谁改的”，只认你选的源库当前状态。一旦源库是某人本地开发环境且未纳入版本控制，同步就等于广播他的临时改动。
真正安全的源只能是：
• Git 仓库里受保护的 schema.sql 导入生成的库
• 团队约定的“主干结构库”（如 dev-structure），只允许 CI 流水线写入
• 或 Navicat 模型工作区导出的 XML 文件逆向生成的库（需确保该 XML 已被 PR 合并）
同步配置里必须关掉“Drop missing objects in target”
这个选项默认勾选，但它是覆盖风险的主因之一：只要目标库有某个表在源库不存在，Navicat 就会生成 DROP TABLE 语句。队友刚加的 audit_log 表若不在你的本地源里，它就会被删掉。
正确做法是：
• 明确取消勾选 Drop missing objects in target
• 改用 Alter table 模式（Navicat Premium 16+ 默认启用）
• 对每条生成的 ALTER TABLE ... ADD COLUMN 手动检查是否支持在线变更（例如 MySQL 5.7+ 的 ALGORITHM=INPLACE）
• 若目标库已含数据，禁用 Drop columns 类操作——Navicat 不会主动提示数据丢失风险
字段顺序、注释、外键名这些“隐性差异”Navicat 不处理
Structure Synchronization 默认只比对对象存在性（表/视图/函数有没有），不校验字段顺序、列注释、外键约束名（比如自动生成的 fk_abc123）、分区定义等。这些差异不会报错，但会导致团队协作时 SQL 脚本与实际结构不一致。
补救和预防要点：
• 外键名必须手动设为固定值（如 fk_order_user_id），否则每次导出 XML 都不同，Git diff 全是噪音
• 字段注释要补上 -- @desc 注释块，并在导出模型时启用 Export comments as SQL comments
• MySQL 版本兼容性需在模型属性中显式设置（如目标为 MySQL 8.0），避免 JSON 字段在 5.7 上同步失败
• 同步前用 mysqldump --no-data 导出双方 DDL，用 diff 做最终校验
团队共享同步任务时，.nsx 文件不能直接发给队友
.nsx 是 Navicat 的 profile 文件，它不包含连接密码、SSH 隧道参数、SSL 设置——这些全存在本地配置里。你导出的 .nsx 在队友机器上十有八九连不上目标库，更别说执行同步了。
可靠交付方式只有两种：
• 用 Data Transfer 导出带完整 DDL 的 SQL 脚本（取消勾选 Include DROP TABLE，启用 Use IF NOT EXISTS）
• 或用 Structure Synchronization 生成变更脚本后，人工合并进团队 Git 仓库的 /migrations/ 目录
• 每个环境（dev/staging/prod）必须使用独立数据库账号，权限严格限制为 CREATE/ALTER/SELECT，禁用 GRANT OPTION
真正的风险点不在 Navicat 功能本身，而在于“谁来决定源结构”和“谁有权触发同步”。一旦把这个决策权交给单个开发者本地环境，再精细的配置也防不住误操作。
