必须将目标字段设为JSON/JSONB类型并禁用Navicat自动建表：MySQL≥5.7.8用JSON，PostgreSQL≥9.2用JSONB；关闭快速同步防编码变形；导入前确保UTF-8无BOM、扁平数组格式、字段名大小写严格匹配。
目标表字段类型不是JSON或JSONB
navicat 同步 json 字段时最常报错 invalid json text 或 invalid input syntax for type jsonb，根本原因不是 navicat 有问题，而是目标字段类型不匹配。它不会自动转换类型，只是把源值原样写入——如果目标列是 varchar 或 text，哪怕存的是合法 json 字符串，数据库也无法执行 json_extract、-> 等操作，后续查询会返回 null 或直接报错。
必须手动确认并创建正确类型：
- MySQL：目标字段类型必须是
JSON（不是LONGTEXT），且 MySQL 版本 ≥ 5.7.8；执行DESCRIBE table_name查看 Type 列是否为json - PostgreSQL：推荐用
JSONB（支持索引和高效查询），版本 ≥ 9.2；执行\d table_name确认字段类型 - 禁用 Navicat 的「自动创建目标表」——它对 JSON 类型识别不可靠，常建错成
text，改类型时可能因数据含非法字符失败
同步时启用「跳过错误记录」但没查日志
即使字段类型正确，源数据里混有非标准 JSON 也会中断同步：比如 {a:1}（key 缺少双引号）、尾部逗号、BOM 头、控制字符、超长字符串等。MySQL 插入非法 JSON 直接报错，PostgreSQL 对 JSONB 校验更严。
同步配置中勾选「跳过错误记录」只是避免整批失败，不代表问题消失：
- 同步完成后立刻打开 Navicat 底部「日志」面板，搜索关键词
Invalid JSON或jsonb - 导出报错行的原始数据，用数据库函数验证：
JSON_VALID('...')（MySQL）或to_jsonb('...')::text（PostgreSQL） - 常见污染源：前端生成的 JSON 带单引号、编辑器保存带 BOM、日志拼接混入非 UTF-8 字符
误用「快速同步」导致中文/emoji 变形
大批量同步 JSON 时，别开「快速同步」模式。它绕过客户端解析，走数据库原生 INSERT ... SELECT 或 COPY，但不校验传输过程中的编码变形——含中文、emoji 的 JSON 很容易被截断或乱码，写入后看似成功，实则已损坏。
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
该模式对 JSON 字段风险极高：
- MySQL 下可能把
{"name":"张三"}写成{"name":""，后续JSON_LENGTH()返回NULL - PostgreSQL 中
JSONB遇到无效字节序列直接拒绝插入，报错invalid byte sequence - 务必关闭「快速同步」，用常规同步模式，确保 Navicat 全程参与字符解码与校验
源 JSON 数据结构不合规却强行导入
Navicat 导入 JSON 文件只接受扁平的 array of objects 格式，例如 [{"id":1,"data":{...}},{"id":2,"data":{...}}]。如果源文件是单个对象、嵌套结构（如 {"users":[...]}）或带根键的混合体，它要么报错，要么只导入空行或错位数据。
导入前必须预处理：
- 用
jq 'map(del(.unwanted))'或 Python 脚本提取内层数组，确保顶层是方括号包裹的数组 - 字段名大小写必须与表列名严格一致（
user_name≠username），Navicat 映射逻辑区分大小写 - JSON 文件必须是 UTF-8 无 BOM 编码；记事本另存为时要选「UTF-8」而非「UTF-8 with BOM」
真正麻烦的从来不是同步动作本身，而是 JSON 数据在进入数据库前就已埋下隐性缺陷：格式看似合法，实则含不可见控制字符；字段名看着一样，其实多了一个全角空格；表结构写着 JSON，建表语句却漏写了 COLLATE utf8mb4_0900_as_cs——这些细节不逐项卡死，同步完才发现数据无法被下游服务正确解析。
