navicat乱码需固化字符集配置：导出含"charset":"utf8mb4"的.ncx模板至git，禁用autocharset，强制初始化命令set names utf8mb4，并在ddl中显式声明character set utf8mb4。
团队协作中 Navicat 乱码不是“谁配错了”，而是连接配置没纳入统一管理——必须把字符集设置固化为可复用、可验证、不可绕过的标准动作，否则每次新成员接入或换机器都会重蹈覆辙。
Navicat 连接配置必须导出为 JSON 模板共享
手动在每个人电脑上点选“utf8mb4”不可靠：新版 Navicat 可能隐藏下拉框、旧版不支持该选项、Windows 系统 locale 会干扰默认值。真正有效的是导出连接配置本身。
- 右键连接 →「导出连接」→ 保存为
.ncx文件（本质是 XML，但 Navicat 8+ 支持导出为更清晰的 JSON 格式） - 重点检查导出内容中是否含：
"charset": "utf8mb4"（MySQL）、"options": "-c%20client_encoding%3DUTF8"（PostgreSQL）或"characterEncoding": "utf8mb4" - 把该文件放入团队 Git 仓库的
/configs/navicat/目录，命名如prod-mysql-utf8mb4.ncx，并附 README 明确要求“导入后必须重新连接才生效” - 禁用“自动检测字符集”选项——导出的配置里若出现
"autoCharset": true或类似字段，手动删掉再提交
初始化命令 SET NAMES utf8mb4 必须写死在连接模板里
光设连接层 charset 不够：MySQL 协议允许客户端声明编码，但某些驱动或网络中间件会忽略声明，只认初始化语句。Navicat 的「使用初始化命令」不是可选项，是必填项。
- 编辑连接 →「高级」→ 勾选「使用初始化命令」→ 填入：
SET NAMES utf8mb4;（注意结尾分号不能少） - 不要用
SET CHARACTER_SET_CLIENT = utf8mb4单独设某一项——SET NAMES同时覆盖client、connection、results三者，缺一不可 - 验证是否生效：连接后立即执行
SELECT @@character_set_client, @@collation_connection;，两个返回值都必须含utf8mb4 - 如果团队用 CI/CD 自动建库，SQL 脚本开头也得加这句，否则 Navicat 导入时不会自动触发
表结构 DDL 必须带 CHARACTER SET utf8mb4 显式声明
团队成员各自建表时若只写 CREATE TABLE t1 (...)，就会继承数据库默认字符集——而这个“默认值”可能因人而异（有人连的是测试库，有人连的是本地库），导致同名表在不同环境字符集不一致。
- 所有 DDL 必须显式声明：
CREATE TABLE t1 (...) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci; - 字段级也要约束：TEXT 类型容易被忽略，
content TEXT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci不能省 - 用
SHOW CREATE TABLE审计现有表，若发现无DEFAULT CHARSET或值为utf8（即 utf8mb3），立刻用ALTER TABLE ... CONVERT TO CHARACTER SET utf8mb4修复 - 禁止用
ALTER DATABASE ... CHARACTER SET试图“一劳永逸”——它只影响后续新建表，对已有表和字段完全无效
最常被跳过的环节是：成员从 Excel 或 CSV 导入数据时，根本没执行 SET NAMES utf8mb4，也没确认源文件真实编码（比如别人发来的 Excel 用 GBK 保存，你用 UTF-8 导入，字节直接错位）。这种操作无法靠模板预防，只能靠 Code Review 时强制检查导入前的 SQL 窗口首行语句。
