必须确认目标表JSON字段类型为JSON而非LONGTEXT，因Navicat不自动映射类型；需手动建表并显式声明JSON类型，禁用快速同步与自动建表，启用跳过错误并检查日志中的Invalid JSON关键词，同时统一字符集为utf8mb4。
同步前必须确认目标表字段类型是JSON，不是LONGTEXT
Navicat 不会自动把源库的 JSON 字段映射为目标库的 JSON 类型。默认启用「自动创建目标表」时，MySQL 下几乎总会建为 LONGTEXT——看着能存，但后续用 JSON_EXTRACT()、-> 或 JSON_VALID() 会返回 NULL 或直接报错 Invalid JSON text。
正确做法是手动建好目标表：
- 字段名、顺序、是否允许
NULL、默认值（如DEFAULT (JSON_OBJECT())）必须和源表一致 -
JSON字段必须显式声明为JSON，不能靠 Navicat 自动推断 - 执行
DESCRIBE table_name确认字段类型确实是json，不是longtext或text
禁用「快速同步」，否则 JSON 数据可能被静默损坏
「快速同步」模式绕过 Navicat 客户端解析，直接走数据库级 INSERT ... SELECT。它不校验中间字符编码、BOM 头、控制字符或非法 Unicode，而这些在 JSON 字段里极易导致插入失败。
典型现象：
- 同步中途卡住，日志只显示“Error during data transfer”
- 部分行导入成功，但
JSON_VALID(col)返回0 - 字段值看起来正常，但
col->"$.name"总是NULL
务必在同步设置中取消勾选「快速同步」，让 Navicat 逐行解析并校验每条 JSON 字符串。
启用「跳过错误记录」并检查日志里的 Invalid JSON 关键词
即使字段类型正确，源数据里混入非标准 JSON（如单引号代替双引号、尾部逗号、{a:1} 缺少引号）也会触发数据库原生报错。
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
MySQL 报错示例：Invalid JSON text in argument 1 to function json_extract
PostgreSQL（若同步到 PG）报错：invalid input syntax for type jsonb
同步配置中必须勾选「跳过错误记录」，否则整批中断。完成后立刻打开 Navicat 底部「日志」面板，搜索：
Invalid JSONjson_extractjsonb
定位失败行后，导出对应源数据，用 JSON_VALID() 单独验证，或用在线工具如 JSONLint 检查格式。
字符集不匹配会导致 JSON 字段写入乱码或截断
Navicat 默认按连接字符集传输数据。如果源库用 utf8mb4，但 Navicat 连接参数没显式指定，或目标库连接用了 latin1，JSON 中的 emoji、中文、特殊符号就会变成问号或被截断——而 JSON_VALID() 仍可能返回 1，掩盖问题。
解决方式：
- 源库和目标库连接的「高级」设置里，都加上
SET NAMES utf8mb4 - 确保目标表字段的字符集也是
utf8mb4（SHOW CREATE TABLE可查） - 避免在「附加选项」里勾选「自动检测编码」，手动设为
UTF-8
最隐蔽的坑是：JSON 字段本身不报错，但里面嵌套的字符串内容已损坏，后续业务查询时才暴露。
