Navicat 同步 JSON 字段前必须确认目标库版本及字段类型为 JSON（MySQL≥5.7.8）或 JSONB（PostgreSQL≥9.2），禁用自动建表，手动创建结构一致的目标表，启用跳过错误并检查日志，禁用快速同步，确保字符集正确，并提前校验源数据合法性。
Navicat 同步 JSON 字段前必须确认目标库的 JSON 类型支持
navicat 本身不转换数据类型，它只是把源字段值原样写入目标字段。如果目标表字段不是 json 类型（比如是 varchar 或 text），即使源数据是合法 json，同步后也无法被数据库当作 json 解析——后续用 json_extract、-> 等操作会报错或返回 null。
务必在同步前检查目标库版本和字段定义：
- MySQL：需 ≥ 5.7.8，且目标字段类型必须是
JSON（不是LONGTEXT） - PostgreSQL：需 ≥ 9.2，字段类型应为
JSON或JSONB（推荐JSONB，支持索引和更快查询） - 确认方式：执行
DESCRIBE table_name（MySQL）或\d table_name（PostgreSQL），看字段类型是否为json/jsonb
用 Navicat 数据同步功能时要关掉「自动创建目标表」
Navicat 默认勾选「自动创建目标表」，但它对 JSON 类型识别不可靠：MySQL 下常建为 LONGTEXT，PostgreSQL 下可能建为 text。一旦建错，同步完还得手动改表结构，而改类型可能因数据不合规失败（例如含非法 Unicode 的字符串）。
正确做法是提前在目标库建好结构一致的表：
- 字段名、顺序、约束（如
NOT NULL）保持一致 - JSON 字段必须显式声明为
JSON（MySQL）或JSONB（PostgreSQL） - 如果源 JSON 字段有默认值（如
DEFAULT (JSON_OBJECT())），目标表也需加上对应默认值
同步设置里要启用「跳过错误记录」并检查日志中的 JSON 解析失败
即使字段类型正确，同步仍可能失败：源数据里混有非 JSON 字符串（如 "{a:1}" 缺少引号）、超长字符串、BOM 头、控制字符等。MySQL 在插入非法 JSON 到 JSON 字段时直接报错：Invalid JSON text；PostgreSQL 对 JSONB 要求更严，会报 invalid input syntax for type jsonb。
建议同步配置中：
- 勾选「跳过错误记录」，避免整批中断
- 同步完成后立刻查看 Navicat 底部「日志」面板，搜索关键词
Invalid JSON或jsonb - 导出失败行的源数据，用
JSON_VALID()（MySQL）或to_jsonb()（PostgreSQL）单独验证
大批量 JSON 同步时别用「快速同步」模式
Navicat 的「快速同步」会绕过客户端解析，直接用数据库的 INSERT ... SELECT 或 COPY 执行，看似快，但对 JSON 字段极其危险：它不校验中间传输过程中的编码变形（尤其是含中文、emoji 的 JSON），容易把 UTF-8 变成乱码再写入，导致目标字段存储的是损坏 JSON。
稳妥做法是：
- 取消勾选「快速同步」，让 Navicat 逐行读取、转义、再插入
- 确保源库和目标库连接都设置了正确的字符集：MySQL 连接参数加
characterSet=utf8mb4，PostgreSQL 加client_encoding=utf8 - 若数据量超 10 万行，先分批次同步（按主键范围或时间字段切分），避免内存溢出或超时
真正卡住的往往不是 Navicat 操作步骤，而是 JSON 字段在源库中早已存在格式隐患——比如开发阶段用字符串拼接生成 JSON，没做 JSON_ESCAPE 或 to_jsonb() 处理。同步前花十分钟用 SQL 扫一遍：SELECT id, json_col FROM tbl WHERE NOT JSON_VALID(json_col)（MySQL）或 SELECT id FROM tbl WHERE json_col::jsonb IS NULL（PostgreSQL），比同步失败后再排查快得多。
