只配[mysqld]不够，因character-set-server仅影响新库默认值，不控制客户端连接编码；必须同步配置[client]和[mysql]段default-character-set=utf8mb4，并重启服务，再验证全部character_set_*变量均为utf8mb4。

必须在 my.cnf 或 my.ini 里同时配置服务端和客户端段落，只改 [mysqld] 不足以保证连接层编码一致——很多乱码问题就卡在这一步。

为什么只配 [mysqld] 不够？

MySQL 启动后，character-set-server 只影响新数据库的默认字符集和 character_set_server 变量，但不强制客户端连接时用什么编码。命令行工具（如 mysql）、备份工具（如 mysqldump）甚至某些驱动默认仍走 latin1 或旧版 utf8。

常见现象：SHOW VARIABLES LIKE 'character_set_%'; 显示 character_set_server = utf8mb4，但 character_set_client 和 character_set_results 是 latin1 或 utf8（注意：MySQL 的 utf8 实际是 utf8mb3，不支持 emoji 和部分中文）。

• [mysqld] 控制服务端行为
• [client] 控制所有客户端工具的默认连接编码
• [mysql] 单独控制 mysql 命令行客户端（可覆盖 [client]）

my.cnf 必须写的三段配置

Linux 下通常编辑 /etc/my.cnf 或 /etc/mysql/my.cnf；Windows 下找 my.ini（常见于 C:\ProgramData\MySQL\MySQL Server X.X\）。

确保包含以下内容：

[client]
default-character-set = utf8mb4

[mysql]
default-character-set = utf8mb4

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

注意：default-character-set 和 character-set-server 中的短横线 - 是标准写法（下划线 _ 也兼容，但保持统一）；collation-server 不能省，否则中文排序、大小写比较可能出错。

改完必须重启 MySQL 服务：sudo systemctl restart mysql（Linux）或通过 Windows 服务管理器重启。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

验证是否真正生效

不要只看 character_set_server，要检查连接建立后的实际会话变量：

登录后执行：

mysql -u root -p -e "SHOW VARIABLES LIKE 'character_set_%'; SHOW VARIABLES LIKE 'collation_%';"

关键字段应全部为 utf8mb4：

• character_set_client
• character_set_connection
• character_set_results
• character_set_server
• collation_server

如果其中任意一项不是 utf8mb4，说明配置未加载、文件路径不对、或被其他配置文件覆盖（可用 mysql --help | grep "Default options" 查找实际读取的配置路径）。

已有应用连接仍乱码？检查代码层显式声明

即使配置文件全对，PHP/Python/Java 等仍可能忽略服务端设置，走驱动默认编码：

• PHP mysqli：连接后必须调用 mysqli_set_charset($conn, 'utf8mb4')
• Python pymysql：创建连接时传参 charset='utf8mb4'
• JDBC URL：加 ?characterEncoding=utf8mb4&useUnicode=true
• Node.js mysql2：选项中设 charset: 'utf8mb4'

漏掉这一层，等于在高速公路上修好了路基，却忘了给车装 GPS——数据进得去，但解码路径错了。

最易被忽略的是：开发环境和生产环境配置文件不一致，或者 Docker 容器里挂载的 my.cnf 没生效，导致本地测试正常、上线就乱码。