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）字符集，即使客户端全设对了，存进去还是截断或转义失败。
