Navicat导入JSON中文变问号或方块的根本原因是JSON文件编码与数据库字符集不匹配；需确保JSON为UTF-8无BOM、Navicat连接字符集与表一致（如utf8mb4）、MySQL服务端相关character_set变量统一，并注意JSON格式须为数组、字段名全英文、大文件应拆分或改用命令行导入。

Navicat导入JSON时中文变问号或方块

根本原因是json文件编码与navicat连接数据库时的字符集不匹配，不是文件“坏了”，也不是navicat故障。常见现象是：json里明明有{"name": "张三"}，导入后变成{"name": "???"}，或者整行显示为乱码符号。

• 先确认JSON文件本身编码：用VS Code或Notepad++打开，右下角看是否是UTF-8（无BOM最稳妥），别用Windows记事本另存为“UTF-8”，它默认加BOM，Navicat对BOM敏感
• 检查Navicat连接属性里的Character set设置：必须和目标MySQL表的CHARSET一致，比如表是utf8mb4，这里就得选utf8mb4，不能只写utf8
• MySQL服务端也要同步校验：SHOW VARIABLES LIKE 'character_set%';重点关注character_set_client、character_set_connection、character_set_database三个值，建议统一为utf8mb4

用Navicat「导入向导」导入JSON失败报错

典型错误信息像Invalid JSON text或Unexpected token，其实多数不是JSON语法错，而是Navicat对JSON结构有隐含要求：它只接受数组格式的JSON，单个对象会直接报错。

• 原始JSON如果是{"id": 1, "name": "李四"}（单个对象），必须包一层变成[{"id": 1, "name": "李四"}]
• 字段名必须全英文、不能含空格或特殊符号；值里如果含换行符\n或制表符\t，建议先用JSON.stringify()序列化一遍再保存
• Navicat 15+支持JSON导入，但12及更早版本根本不识别.json扩展名——得手动改后缀为.txt，并在导入向导里手动指定“文本文件”，再选字段分隔符为none

导入后中文能显示但搜索/排序异常

这说明编码“通了”，但排序规则（collation）没对齐。比如字段是utf8mb4_general_ci，而你实际要按拼音排序或区分大小写，就会出问题。

• 建表时优先用utf8mb4_0900_as_cs（MySQL 8.0+）或utf8mb4_unicode_ci（兼容性更好），避免用utf8mb4_general_ci（已弃用）
• 已有表可在线修改：ALTER TABLE users MODIFY name VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
• Navicat执行SQL时，如果临时会话没设对，SELECT * FROM users WHERE name = '王五'可能查不到——记得在查询前加SET NAMES utf8mb4;

批量导入大JSON文件卡死或中断

Navicat导入界面本质是把JSON转成INSERT语句再执行，超10MB就容易超时或内存溢出，不是配置调高就能解决。

• 拆分JSON：用jq -c '.[]' data.json | split -l 5000 - chunk_（Linux/macOS）或Python脚本按500条一组生成多个小JSON
• 改用命令行替代：MySQL原生命令mysql --default-character-set=utf8mb4 -u root -p db_name ，配合jq生成标准INSERT语句更稳
• Navicat里关掉「Auto-commit」，勾选「Continue on error」，防止某条失败整个中断

真正卡住的点往往不在JSON本身，而在MySQL服务端的max_allowed_packet和wait_timeout。哪怕Navicat显示“导入成功”，也可能只写入了前几万行——务必查SELECT COUNT(*)核对行数。