枚举类型跨模式不匹配是根本原因：同名但不同模式（如public.status_enum与test.status_enum）在PostgreSQL中被视为独立类型，Navicat结构同步仅比对名称而忽略模式，导致ALTER COLUMN TYPE失败、默认值无法自动转换及运算符不存在等报错。
同步失败时提示“type mismatch”或“cannot cast automatically”
这类报错基本都指向枚举类型定义在源库和目标库中不是同一个对象——哪怕名字一样，只要不在同一模式（schema）下，postgresql 就认为是两个独立类型。navicat 的结构同步功能默认只比对名称，不校验所属模式，所以容易把 public.status_enum 和 test.status_enum 当作可互换类型，实际执行 alter column ... type 时就会卡在类型转换环节。
关键动作不是重试同步，而是先确认两边枚举的完整限定名：
- 查源库：运行
SELECT enumlabel FROM pg_enum WHERE enumtypid = 'public.status_enum'::regtype ORDER BY enumsortorder; - 查目标库：把
public换成目标模式名（如test），确保值列表、顺序、模式三者完全一致 - 若目标库枚举不存在，别依赖 Navicat 自动生成——它可能建在
public下，而你期望的是test
Navicat 同步前手动创建目标枚举必须指定模式前缀
Navicat 的“结构同步”向导里，如果勾选了“自动创建缺失的对象”，它对枚举类型的处理是盲目的：会直接执行 CREATE TYPE status_enum AS ENUM (...)，结果这个类型就落在当前 search_path 默认模式（通常是 public）里，而不是你真正要同步到的 test 模式中。
正确做法是，在 Navicat 中打开查询编辑器，手动执行带模式前缀的建枚举语句：
CREATE TYPE test.status_enum AS ENUM ('draft', 'published', 'archived');
然后再运行结构同步——此时 Navicat 才能识别出“目标端已有同名且同值的枚举”，跳过创建步骤，只做字段类型变更。
注意：search_path 设置会影响该语句行为，执行前用 SHOW search_path; 确认当前上下文。
同步后应用仍报“operator does not exist”
这说明代码或查询里硬编码了枚举值，但没带模式前缀，导致 PostgreSQL 在解析时按 search_path 顺序查找，优先匹配到了 public.status_enum，而字段实际绑定的是 test.status_enum，两者不可比较。
修复点不在 Navicat，而在 SQL 或应用层：
- 所有涉及该枚举的
WHERE、IN、=操作，值必须显式转为目标模式类型，例如：status = 'published'::test.status_enum - 应用 ORM（如 Hibernate）若用字符串匹配枚举，需确认其生成的 SQL 是否带类型修饰；否则得改用
status = 'published'+ 参数绑定，由驱动自动推导 - 检查视图、函数、默认值表达式里是否引用了未限定的枚举字面量
为什么 Navicat 不报错却同步失败？
因为它的结构同步逻辑把“枚举类型”当作普通类型处理，不校验跨模式一致性，也不检查 DEFAULT 表达式中是否存在隐式类型转换风险。比如目标字段有 DEFAULT 'draft'，但 draft 字符串无法自动 cast 到 test.status_enum，就会在同步后期执行 ALTER COLUMN ... SET DEFAULT 时静默失败或跳过。
最稳妥的方式是：同步前在目标库手动执行一次完整验证：
SELECT column_name, udt_schema || '.' || udt_name AS actual_type, data_type AS base_type FROM information_schema.columns WHERE table_name = 't_product' AND column_name = 'status';
确保 actual_type 明确显示为 test.status_enum，而不是 public.status_enum 或 character varying。任何偏差都得先人工修正，再让 Navicat 继续同步其他对象。
