navicat不支持原生语义正确的json导出，其默认导出将int、datetime等字段全转为字符串，null变为"null"，且不处理时区、嵌套与字段重命名；推荐用mysql的json_object+json_arrayagg手写sql或python脚本修复类型。
navicat 本身不支持“原生语义正确”的 json 导出——它导出的 .json 文件只是把每行数据转成一个对象、再用方括号包成数组，但字段类型全变成字符串，且不处理 null、时间格式、嵌套结构等。直接用于微信云开发、前端解析或类型敏感场景时大概率报错或逻辑异常。
Navicat 默认导出 JSON 的实际行为
右键表 →「导出向导」→ 选「JSON 文件」→ 下一步完成，生成的文件长这样：
[{"id":"1","name":"张三","created_at":"2024-05-20 10:30:00","state":"1"}]
注意几个关键事实：
-
id和state原本是INT，导出后全带双引号，成了字符串 -
created_at是DATETIME，但没转成 ISO 标准格式，也未做时区归一 - 如果某字段值为
NULL，导出结果是"null"（字符串），不是真正的 JSONnull - 无法控制 key 名大小写、无法重命名字段、不支持跨表 JOIN 合并导出
MySQL 5.7+ 推荐：用 JSON_OBJECT + JSON_ARRAYAGG 手写 SQL
这是最可控、类型保真度最高的方式，适合中小数据量（
SELECT JSON_ARRAYAGG(
JSON_OBJECT(
'id', id,
'name', name,
'state', state,
'created_at', created_at
)
) AS json_data
FROM users
WHERE status = 1;
执行后，结果集只有一行一列：json_data，值就是标准 JSON 数组。复制该字段内容，粘贴到新文件保存为 users.json 即可。
关键点：
- 数字、布尔、
NULL字段直接传入JSON_OBJECT，不会加引号，类型保留 - 时间字段如
created_at会自动转为"2024-05-20T10:30:00.000Z"格式（取决于 MySQL 时区设置） - 若要避免大结果集内存溢出，加
LIMIT 5000分批查，再手动合并 - 跨表关联时，必须用别名避免键冲突，例如
'user_id', u.id，不能写两个'id'
大数据量或复杂结构：用 SELECT ... INTO OUTFILE 生成 NDJSON
当单次查询超 10 万行，JSON_ARRAYAGG 容易 OOM 或超 group_concat_max_len 限制。改用逐行输出（NDJSON 格式），再用脚本合并：
SELECT JSON_OBJECT( 'id', id, 'name', name, 'tags', JSON_EXTRACT(profile, '$.tags') ) INTO OUTFILE '/tmp/users.ndjson' FIELDS TERMINATED BY '' LINES TERMINATED BY '\n' FROM users;
注意：
-
INTO OUTFILE路径是 MySQL 服务端本地路径，不是你本地电脑；需有FILE权限 - 输出是每行一个 JSON 对象（NDJSON），无外层数组，适合流式处理
- 导出后需用
cat /tmp/users.ndjson | jq -s '.' > users.json合并（Linux/macOS）或 Python 脚本封装 -
JSON_EXTRACT可安全展开已存 JSON 字段，避免字符串拼接出错
字段类型丢失后怎么补救
如果你已经用 Navicat 默认导出了 JSON，且发现 "id": "123" 这类问题，别删掉重来。可以用轻量脚本修复：
Python 示例（用 pandas 读入再导出）：
import pandas as pd
df = pd.read_json("navicat_export.json")
df["id"] = df["id"].astype(int)
df["state"] = df["state"].astype(int)
df["created_at"] = pd.to_datetime(df["created_at"])
df.to_json("fixed.json", orient="records", date_format="iso", date_unit="s")
重点：
- 不要依赖正则全局替换
"id": "(\d+)"→"id": $1，容易误伤含数字的字符串字段（如手机号、编码） - 时间字段修复必须用
pd.to_datetime或类似库，否则时区/精度全乱 - 微信云开发导入要求顶层是数组，且每个元素必须是 object，不能有 null key 或重复 key
真正麻烦的从来不是“怎么导出”，而是导出后下游是否能按预期解析——类型、空值、时间、嵌套，每个都可能在某个环节静默失败。动手前先确认目标系统对 JSON 的 schema 要求，比盲目调参数重要得多。
