逆向工程中文表名乱码99%是连接层未设utf8mb4所致，需同时配置：高级选项中勾选override default charset并选utf8mb4、初始化命令填set names utf8mb4;、清除冲突参数，且必须重启navicat验证character_set_client/connection/results全为utf8mb4。
逆向工程中文表名乱码，99%是连接层没设 utf8mb4
Navicat 逆向工程（如生成 ER 图、导出模型）读取的是 information_schema.tables 等元数据表，这些字段本身不存字符集属性，完全依赖当前连接的 character_set_client 和 character_set_results。如果这两项不是 utf8mb4，MySQL 就会用 latin1 解析本该是 UTF-8 编码的字节流，导致表名、字段注释（如 COMMENT '用户ID'）变成 Óû§ID 这类乱码——而普通查询看着正常，是因为你查的是业务数据，不是元数据。
必须同时配置三处，缺一不可
只改其中一项，乱码照旧。要真正生效，得全部满足：
- 右键连接 → 编辑连接 → 「高级」选项卡 → 勾选 Override default charset → 下拉选
utf8mb4（注意不是utf8，也不是UTF-8） - 同一页面 → 找到「初始化命令」→ 填入
SET NAMES utf8mb4;（结尾分号不能少） - 检查连接字符串里没有残留冲突参数，比如
characterEncoding=utf8或单独的useUnicode=true（它们不指定 mb4，等效 fallback 到 latin1）
验证是否真生效，别信“测试连接成功”
“测试连接”只验账号密码和网络，不校验字符集。必须手动执行：
SHOW VARIABLES LIKE 'character\_set%';
重点盯住这三项是否全为 utf8mb4：
character_set_clientcharacter_set_connectioncharacter_set_results
只要其中一项是 latin1 或 gbk，逆向工程就必然乱码。而且改完设置后，**必须完全退出 Navicat 再重开**，否则新配置不会加载进会话上下文。
OceanBase / PostgreSQL 用户特别注意租户与 client_encoding 绑定
OceanBase 的字符集是租户级的，PostgreSQL 的 client_encoding 是会话级的。如果你连的是 OceanBase 租户 A，但该租户实际配的是 utf8mb3；或者 PostgreSQL 连接串漏了 options=-c%20client_encoding%3DUTF8（URL 编码不能错），那 Navicat 拿到的表名就是错的原始字节，后续任何操作都补救不了——因为乱码发生在元数据传输第一环。
