Navicat网格编辑中文变问号或空格，本质是连接层字符集未生效导致服务端错误解析字节；必须同步设置连接高级选项为utf8mb4、初始化命令SET NAMES utf8mb4，并确认表字段显式支持utf8mb4，且修改后需断开重连验证@@character_set_client为utf8mb4。
Navicat 网格编辑（即双击表名直接在表格视图里增删改数据）时中文变问号、方块或空格，不是显示问题，而是数据写入阶段就已损坏——服务端收到的字节根本不是 UTF-8 编码的中文。
网格编辑乱码的本质是连接层字符集未生效
Navicat 网格编辑走的是 MySQL 的二进制协议直写路径，不经过 SQL 解析器，因此：
- 它完全依赖连接初始化时声明的
character_set_client和collation_connection - 如果连接没显式设为
utf8mb4，MySQL 默认按latin1或gbk解析传入的字节，中文立刻被截断或转义成? - 即使你“看到”编辑框里中文显示正常，那只是界面渲染的假象；一保存，服务端存进去的就是错的字节
常见错误现象：
- 新建记录填“测试”，保存后查出来是
??或???? - 修改已有中文字段，一提交就变空或问号
- 同一个连接下，SQL 窗口执行
INSERT正常，但网格编辑失败
必须改的三个地方，缺一不可
- 编辑连接 →「高级」→ 勾选「使用 MySQL 字符集」→ 下拉选
utf8mb4（不是utf8） - 同一位置「初始化命令」栏填：
SET NAMES utf8mb4;（强制覆盖默认行为） - 目标表字段必须显式支持：
SHOW CREATE TABLE <code>your_table; 中每个中文字段定义要含CHARACTER SET utf8mb4，否则即使连接对了，字段也存不下
别信「自动检测」：Windows 中文版 Navicat 默认走 gbk 初始化，而 MySQL 8.0+ 默认 utf8mb4，二者一碰就丢字节。
为什么改完连接还要重启？
Navicat 的连接池会复用旧连接句柄。即使你编辑了连接属性，已建立的连接不会自动 reload 字符集设置。
必须：
- 关闭所有该连接打开的窗口（包括查询、表结构、网格编辑页签）
- 右键连接 →「断开连接」
- 再右键 →「连接」
然后立刻执行：SELECT @@character_set_client, @@collation_connection;
确认返回值都是 utf8mb4，再进网格编辑——这才是真正生效的状态。
网格编辑不像 SQL 执行有报错提示，它静默失败。最容易被忽略的是：你以为改了连接就完了，其实旧连接还在后台跑，继续用错编码写数据。
