Navicat 16 默认不生成 DROP 语句是因启用「安全模式」，默认未勾选“Drop objects not exist in source”，防止误删手动添加的对象，属设计策略而非 bug。
为什么 Navicat 16 默认不生成 DROP 语句
navicat 16 的结构同步默认启用「安全模式」：它假设目标库可能含手动添加的表、字段或索引（比如 dba 临时加的调试列），所以不会主动删任何东西。这背后控制开关就是 drop objects not exist in source，默认未勾选——不是 bug，是设计策略。
取消勾选后仍出现 DROP 的真实原因
即使你确认该选项已取消，仍看到 DROP COLUMN 或 DROP TABLE，大概率是以下情况之一：
- 你在「源对象」树形列表里手动取消了某张表的勾选（右键 → Uncheck），但 Navicat 把这理解为“源中不存在”，于是对目标库执行删除操作
- 同步前你改过源库连接的「默认 Schema」，导致 Navicat 实际比对的是空 schema，误判目标库所有对象都“多余”
-
Compare foreign keys被勾选，而源库外键名和目标库不一致（比如fk_order_user_idvsorder_user_id_fk），Navicat 会先删旧外键再建新外键
真正禁用所有 DROP 类操作的配置组合
单靠一个选项不够，必须同时满足：
- 在「选项」→「常规」中，取消勾选
Drop objects not exist in source - 在「选项」→「高级」中，取消勾选
Compare auto-increment value（否则可能触发ALTER TABLE ... AUTO_INCREMENT = N，间接导致主键重置风险） - 进入「结构比对」界面，在左侧
Source Objects树里，确保所有表、视图、函数节点都处于勾选状态（哪怕你暂时不打算同步它们，也要保持勾选；想跳过请用部署脚本阶段人工注释） - 若目标库有同名但结构不同的表，不要依赖同步覆盖——先手动导出原表 DDL 备份，再决定是否删表重建
预览 SQL 时怎么快速识别残留 DROP
点开「预览 SQL」页签后，别从头扫，直接搜索关键词：
- 搜
DROP TABLE：出现即违规，立刻回退检查源对象勾选状态 - 搜
DROP COLUMN：常见于字段重命名（Navicat 把RENAME COLUMN拆成DROP + ADD），此时应勾选「忽略列顺序」并确认源库用了 MySQL 8.0+ 的重命名语法 - 搜
FOREIGN KEY：若看到成对的DROP FOREIGN KEY和ADD CONSTRAINT，说明Compare foreign keys生效了，且外键名不一致
最易被忽略的是：当你用不同用户连接源/目标库，PostgreSQL 下因 search_path 差异，Navicat 可能根本没加载到某些 schema 的对象，却在目标库发现它们，从而判定为“需删除”。这时候得分别配两个连接，每个指定固定 schema。
