Navicat Premium 不提供 JSON 字段无损还原功能，其导出/导入依赖用户确保 JSON 合法性、正确使用 jsonb_pretty() 或 JSON 类型声明，并规避隐式截断与转义。
Navicat Premium 本身不提供「JSON字段无损还原」的独立功能——它不会自动识别、校验或修复 JSON 字段内容的语法合法性。所谓“无损”，实际取决于你导出时是否已确保 JSON 文本合法，以及导入时是否避开 Navicat 对 JSON 字段的隐式字符串截断/转义逻辑。
导出时没用 jsonb_pretty() 或 to_jsonb()，导入必然损坏
PostgreSQL 的 jsonb 字段在 Navicat 网格中显示正常，但直接 SELECT 导出为文件时，Navicat 把它当普通 text 处理：字段名不加引号、中文乱码、换行符被吞、双引号不转义（如 "name": "张三" 变成 name: 张三），导致后续 JSON.parse() 直接报 SyntaxError: Unexpected token。
- 必须在导出前用 SQL 包裹字段：
SELECT jsonb_pretty(data) AS data FROM table - 若字段含中文，执行
SET client_encoding = 'UTF8';再查询，否则导出文件开头可能带 BOM 或乱码 - 绝对不要用 Navicat 的「导出向导 → 保存为 JSON 文件」，它会强制压平缩进、删换行、加表头，JSON 结构全毁
- 最稳方式是命令行：
psql -t -c "SELECT jsonb_pretty(data) FROM table" > data.json（-t关闭表头和分隔线）
MySQL 的 JSON 字段导入时需显式声明类型，不能靠 Navicat 自动推断
Navicat 导入 JSON 文件时，默认把所有字段当 VARCHAR 或 TEXT 处理，即使目标列是 JSON 类型，也不会触发 MySQL 的 JSON 校验；若原始 JSON 有语法错误，数据能写进去但字段值为 NULL，且无任何提示。
- 导入前确认目标表字段定义是
JSON类型，不是TEXT（ALTER TABLE t MODIFY COLUMN j JSON;） - 在 Navicat 「导入向导」中，手动为 JSON 列勾选「Use JSON type」选项（该选项仅在目标列为
JSON时出现） - 若 JSON 文件顶层是数组（如
[{"id":1},{"id":2}]），Navicat 会按行拆分导入；但若某行 JSON 语法错（比如少逗号、多逗号），整行静默失败为NULL - 导入后务必查一遍：
SELECT id, j, JSON_VALID(j) FROM t WHERE JSON_VALID(j) = 0;，及时发现无效项
Redis 的 JSON 文档还原必须用 JSON.SET，Navicat 编辑器只是可视化代理
Navicat for Redis 提供 JSON 编辑器界面，但它不直接执行 JSON.SET；你点「保存」时，Navicat 实际发的是 SET key "raw_string" —— 如果你手输的 JSON 不合法（比如单引号代替双引号、末尾多逗号），Redis 不报错，但后续 JSON.GET 返回 ERR wrong JSON type 或空响应。
- 编辑前先用在线工具（如 jsonlint.com）校验原始 JSON 合法性
- 编辑后别直接点保存，先复制内容到查询窗口执行：
JSON.SET mykey . '{...}'，看返回是否OK - Navicat 的「JSON 视图」只读不写，修改必须切到「文本视图」并确保格式严格符合 RFC 7159
- 批量还原建议弃用 Navicat，改用
redis-cli --pipe+JSON.SET命令流，可控性强
真正容易被忽略的点是：Navicat 所有 JSON 相关操作都依赖底层数据库的原生支持，它自己不做语法解析或自动修复。你看到的“正常显示”，只是渲染层的妥协；而“无损还原”的责任，始终在你构造导出语句、校验源 JSON、匹配目标类型这三步上。
