navicat 不处理代码分支级字段冲突，仅响应数据库实例的实际结构差异；其结构同步功能用于发现和执行变更，非git式合并工具，需配合ddl脚本与版本控制实现类分支管理。
navicat 本身不处理代码分支级别的字段定义冲突，它只响应你当前连接的数据库实例中的实际结构差异。所谓“不同分支字段定义冲突”，本质是开发流程中多个环境（如 dev / test / prod）的表结构不一致，navicat 的结构同步功能只是帮你发现并执行变更，不是 git 那样的合并工具。
结构同步时提示 ERROR 1060（重复列名）
这是最常见误判为“分支冲突”的场景，实际是 Navicat 在比对两个数据库时，发现目标表里已存在同名字段，而你又试图添加它。
- 典型触发动作：从 dev 库同步结构到 test 库，但 test 库里已有
updated_at字段，而 dev 的建表语句或 ALTER 语句里又包含ADD COLUMN updated_at - 根本原因不是分支问题，而是同步方向或前提条件没对齐——比如 test 库被手动改过，或上次同步中断残留了部分 DDL
- 解决办法不是“选哪个分支”，而是先确认目标库是否干净：
DESCRIBE table_name查字段，再对比源库 DDL；若确认目标库应完全跟随源库，勾选 Options 里的Drop columns not exist in source（谨慎！会删字段） - 如果只是想跳过某字段冲突，不要在同步向导里硬点“继续”，而是导出 SQL，手动删掉那行
ADD COLUMN或改成MODIFY COLUMN
同一张表在不同环境字段顺序/类型不一致
比如 dev 里 status 是 TINYINT，test 里却是 VARCHAR(20)，Navicat 结构同步会报错或静默失败。
- Navicat 默认只比对字段名和是否为主键/索引，**不校验类型、长度、默认值、注释**——这些差异不会阻止同步启动，但可能造成后续数据写入失败
- 预览 SQL 时注意看生成的
ALTER TABLE ... MODIFY COLUMN是否合理；若类型不兼容（如VARCHAR→TEXT一般可接受，但INT→DATE会报错），需提前在目标库手动调整 - 字段顺序差异不影响功能，但 Navicat 同步后可能重排——如果你依赖
SELECT *的列序（不推荐），就得在同步后手动ALTER TABLE ... MODIFY COLUMN ... AFTER
如何让结构同步更贴近“分支合并”逻辑
你需要自己建立约定，Navicat 不提供分支策略配置。
- 所有结构变更必须走 DDL 脚本 + 版本控制（如 Flyway/Liquibase），Navicat 只用于验证或紧急修复，不作为主发布通道
- 同步前强制要求：源库执行
SHOW CREATE TABLE导出建表语句，与目标库比对；用mysqldiff或pt-table-sync --dry-run做前置检查 - 若必须用 Navicat 同步多环境，建议固定一个“权威源”（如 CI 构建后的 dev 库），每次同步前先
TRUNCATE TABLE structure_log清空记录表，再跑同步并记录生成的 SQL 到日志文件——这相当于你的简易 merge log - 复合主键或唯一索引变动容易被忽略：Navicat 的 Key Mapping 页只显示主键，
UNIQUE KEY变更需手动检查SHOW INDEX输出
真正麻烦的从来不是 Navicat 怎么点，而是你没法靠点几下就解决团队协作中缺乏结构演进共识的问题。字段定义冲突背后，往往是缺乏 DDL 提交规范、缺少 pre-commit hook 校验、或者测试库长期没人维护。Navicat 只能告诉你“这两边不一样”，至于哪边该听哪边的，得人来定。
