必须在navicat连接高级设置中启用utf8mb4并手动添加初始化命令“set names utf8mb4;”，否则字段注释因连接层解码错误而乱码；windows需设utf-8系统编码，已损坏注释须用alter table重写。
navicat 中字段注释（column_comment）显示乱码，不是渲染问题，而是字节流在连接层被错误解码——**必须让 navicat 在建立连接时就声明用 utf8mb4 解析元数据**，否则读出来的中文就是错的字节，后续怎么刷新、重绘都无效。
为什么只改数据库字符集没用？
字段注释存储在 information_schema.COLUMNS.COLUMN_COMMENT 中，是原始字节直接存取，不经过服务端自动转码。即使表和列本身是 utf8mb4，只要连接时 MySQL 认为客户端用的是 latin1（Navicat 默认行为），它就会把注释字节按 latin1 编码发出来，Navicat 再按 utf8 解，必然乱码。
验证方法：
- 连接后执行 SELECT @@character_set_client, @@collation_connection;
- 若返回 latin1 或 gbk，说明连接层没生效
必须设置连接初始化命令：SET NAMES utf8mb4
仅在连接「高级」里勾选「使用 MySQL 字符集」并选 utf8mb4 不够——Navicat 16+ 版本中，该选项不自动触发 SET NAMES，必须手动补上。
- 右键连接 → 编辑连接 → 高级 → 勾选「使用 MySQL 字符集」→ 下拉选
utf8mb4 - 在同一页面的「初始化命令」文本框中，**逐字输入**：
SET NAMES utf8mb4;（注意分号不能少） - 断开当前连接，再重新连接（缓存不刷新，重启连接是硬性要求）
- 刷新 ER 图或重新打开表结构查看，注释应立即正常
Windows 系统级编码冲突：chcp 936 是隐形杀手
部分用户发现：数据库、连接、SQL 文件全设对了，但字段注释仍乱码，而表名、字段名、数据内容却正常——这极可能是 Windows 控制台默认代码页（chcp）为 936（GBK），导致 Navicat for MySQL 的底层 Qt 组件在解析元数据字符串时发生编码误判。
检查方式：
- 打开 CMD 或 PowerShell，输入 chcp
- 若显示 活动代码页: 936，就是它
解决路径（二选一）：
- 临时修复：CMD 中先执行 chcp 65001，再启动 Navicat（不推荐，每次都要）
- 永久修复：系统设置 → 时间和语言 → 语言和区域 → 管理语言设置 → 更改系统区域设置 → 勾选「Beta版：使用 Unicode UTF-8 提供全球语言支持」→ 重启电脑
已有注释已损坏？ALTER TABLE 重写是唯一办法
如果注释当初是用错误连接写入的（比如用 GBK 连接插入了中文注释），那字节本身就错了，改连接也读不出正确中文。
确认是否已损坏：SELECT TABLE_NAME, COLUMN_NAME, COLUMN_COMMENT FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'your_db' AND COLUMN_COMMENT REGEXP '[^ -~]';
若结果中 COLUMN_COMMENT 显示为 ???、æ 或空格混杂，说明已损毁
修复操作（务必在已设好 SET NAMES utf8mb4 的连接下执行）：ALTER TABLE your_table MODIFY COLUMN your_column VARCHAR(255) COMMENT '新注释';
注意：字段定义需完整复刻原类型（含 NOT NULL、DEFAULT 等），否则会意外变更结构
最易被忽略的一点：Navicat 的「SQL 预处理」功能会把元数据里的中文转成 \u7528\u6237 这类 Unicode 转义，ER 图模块不识别，直接丢弃——关掉它：工具 → 选项 → SQL 编辑器 → 取消勾选「启用 SQL 预处理」。
