MySQL客户端中文乱码主因是字符集不一致，需在应用连接串、命令行参数或会话中显式设utf8mb4，并配置my.cnf的client[mysqld]三段，最后验证连接、建表、插入各层编码是否均为utf8mb4。

MySQL 客户端连接后中文乱码的典型表现

执行 SELECT 查询时中文显示为问号（???）或方块，但 INSERT 中文后查出来也是乱码；用 SHOW VARIABLES LIKE 'character%' 发现 character_set_client、character_set_connection、character_set_results 三者不一致，或其中某项是 latin1。

连接时强制指定字符集的三种可靠方式

不要依赖 MySQL 服务端默认配置，客户端每次建立连接都应显式声明编码。优先级从高到低如下：

• 应用代码中连接字符串加参数：如 Python 的 mysql-connector-python 使用 charset='utf8mb4'；Java JDBC URL 后加 ?characterEncoding=utf8mb4
• 命令行客户端启动时指定：mysql -u root -p --default-character-set=utf8mb4（注意不是 --charset）
• 临时会话内执行：SET NAMES utf8mb4; —— 这等价于同时设置 character_set_client、character_set_connection、character_set_results

my.cnf 配置文件中必须修改的三项

仅改 [mysqld] 段的 character-set-server 不够，客户端行为由 [client] 和 [mysql] 段控制：

[client]
default-character-set = utf8mb4

[mysql]
default-character-set = utf8mb4

[mysqld]
character-set-server = utf8mb4
collation-server = utf8mb4_unicode_ci

改完需重启 MySQL 服务，并确认所有段落都存在且拼写准确——漏掉 [mysql] 段会导致 mysql 命令行工具仍用 latin1。

验证是否真正生效的关键检查点

光看 SHOW VARIABLES 不够，要分层验证：

• 连接后立即执行 STATUS，查看输出中 Current database: 下方的 Server characterset: 和 Client characterset: 是否均为 utf8mb4
• 建表时显式指定：CREATE TABLE t (c VARCHAR(10)) CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;，避免依赖数据库默认值
• 插入测试数据：INSERT INTO t VALUES ('你好');，再用 SELECT HEX(c) FROM t; 查看是否返回 E4BDA0E5A5BD（UTF-8 编码的“你好”），而非乱码对应的错误字节

很多问题卡在表本身用了 latin1 或 utf8（非 utf8mb4）字符集，即使客户端全设对了，存进去还是截断或转义失败。