根本原因是Navicat依赖缓存的元数据快照，未及时更新源表新增字段；需右键源库选“刷新”或右键表选“重新加载表结构”，必要时清空Cache文件夹。
Navicat 同步时源表新加字段不显示在比对列表中
根本原因不是 navicat 漏读，而是它依赖缓存的元数据快照——你刚在源库用 alter table add column 加完字段，navicat 的对象树和内部 schema cache 还没更新，仍按旧结构做比对。
常见错误现象：同步向导里“源数据库”侧看不到新字段；点开表结构预览，字段列表仍是老的；甚至刷新连接、重连数据库也无效。
- 必须手动触发元数据刷新：右键点击源库 → 选择 “刷新”（不是刷新连接，是刷新数据库节点本身）
- 若刷新后仍不出现，再右键点击具体那张表 → 选 “重新加载表结构”（Navicat 16+ 支持该选项；旧版需先关闭该表标签页，再双击重新打开）
- 极端情况可清空 Navicat 缓存：关闭 Navicat → 删除
%AppData%\PremierSoft\Navicat\下对应版本的Cache文件夹 → 重启
同步前执行了 ALTER，但 Navicat 仍比对出“无差异”
Navicat 默认只扫描 INFORMATION_SCHEMA.COLUMNS，而某些 ALTER 操作（如仅改 COMMENT、调整 ENUM 值顺序、或用 MODIFY COLUMN 但类型未变）不会触发该视图的 UPDATE_TIME 更新，导致 Navicat 认为“结构未变”。
实操建议：
- 强制让 Navicat 重读：执行
SHOW CREATE TABLE `table_name`;后，立刻点“同步到模型”（此操作会绕过缓存，直接解析建表语句） - 避免用
MODIFY COLUMN微调字段：改字段类型/长度时，优先用CHANGE COLUMN并显式重写字段定义，确保INFORMATION_SCHEMA中COLUMN_DEFAULT或EXTRA字段有实际变更 - ENUM 类型字段新增值后，Navicat 15 及更早版本可能完全忽略变更——升级到 Navicat 16.1+ 或改用
mysqldump --no-data导出后人工比对
目标库字段存在，但同步脚本里没生成 ADD COLUMN 语句
这通常不是 Navicat 漏识别，而是它把“字段存在但类型不同”判为“类型转换”，而非“新增”。比如源库是 VARCHAR(255)，目标库是 VARCHAR(100)，Navicat 默认生成 MODIFY COLUMN 而非 ADD COLUMN，且若类型兼容性判断失败（如含中文校对规则差异），可能直接跳过整条变更。
关键检查点：
- 确认同步设置中勾选了
Compare all object types和Structure（路径：Tools → Options → Data Synchronization → General） - 查看比对结果窗口底部的“详细信息”面板：展开对应表，看字段行是否标为
Modified而非Added；若是Modified，说明 Navicat 认为字段已存在 - 检查目标库该字段的
COLLATION是否与源库一致：不一致时 Navicat 可能放弃同步——临时在目标库执行ALTER TABLE `table_name` MODIFY COLUMN `col_name` VARCHAR(255) COLLATE utf8mb4_0900_as_cs;再试
同步后新字段值全为 NULL，但程序读不到
这不是结构同步的问题，而是应用层缓存或 ORM 映射没更新。Navicat 只管 DDL，不管你的 Java MyBatis XML、Python SQLAlchemy model 或 Node.js Sequelize 定义。
容易被忽略的地方：
- Spring Boot 项目里，如果用了
@Table(name = "xxx")但没加@Column(name = "new_field")，JPA 会直接忽略该字段，查出来就是 null —— 即使数据库里已有值 - PHP Laravel 的 Eloquent model 若没在
$fillable或$casts里声明新字段，toArray()或 API 返回时自动过滤掉 - Navicat 自带的“查询”窗口默认不显示新字段：右键结果集 →
选择列→ 勾选新字段名（它不会自动追加到默认列列表）
