set names utf8失效是因为mysql的utf8仅支持3字节字符，不支持emoji等4字节字符；真正应使用utf8mb4，且需服务端配置、连接层设置与客户端声明三者统一才有效。
执行 SET NAMES utf8 为什么经常失效
这条语句本身没问题，但 MySQL 的 utf8 是个历史遗留伪标准——它最多只支持 3 字节 UTF-8 字符（如中文），**不支持 emoji、某些生僻字、数学符号等 4 字节字符**。真正该用的是 utf8mb4。执行 SET NAMES utf8 后，character_set_client、character_set_connection、character_set_results 三个变量确实会变成 utf8，但服务端实际存储和比较仍按 utf8mb4 或 latin1 处理，导致“看起来设了，其实没对齐”。
mysqli->set_charset('utf8mb4') 比 query("SET NAMES ...") 更可靠
原因在于：set_charset() 是 mysqli 扩展原生提供的连接层字符集设置函数，它直接修改底层连接的编码协商参数；而 query("SET NAMES ...") 是一条 SQL 命令，依赖于当前连接状态是否已就绪，且在某些封装类或长连接复用场景下可能被跳过。
- 必须在
$mysqli = new mysqli(...)成功之后立即调用，不能等到第一次查询前才做 - 如果使用过程式风格，务必传入有效的连接资源：例如
mysqli_set_charset($conn, 'utf8mb4')，$conn不能是null或未初始化值 - 调用后可用
$mysqli->get_charset()->charset验证是否生效，返回应为utf8mb4
PDO 中 charset=utf8mb4 在 DSN 里写没用？检查这三点
DSN 中加 charset=utf8mb4 理论上应该生效，但实际常被忽略，主要因为：
- MySQL 服务端配置未启用
utf8mb4：比如character_set_server仍是latin1或utf8，PDO 无法强制覆盖服务端默认 - 用了持久连接（
PDO::ATTR_PERSISTENT => true）：旧连接的字符集状态会被复用，新请求不会重新协商 - 驱动版本太老或配置冲突：某些旧版 php-mysqlnd 驱动会忽略 DSN 中的
charset，只认init_command
稳妥做法是：DSN 写上 charset=utf8mb4，再补一句 $pdo->exec("SET NAMES utf8mb4")，双重保险。
别只盯着 PHP 连接，先确认 MySQL 服务端是否真支持 utf8mb4
很多乱码问题根本不在 PHP 侧，而是 MySQL 启动时压根没加载正确配置。尤其在 phpEnv、XAMPP、MAMP 等集成环境里，my.ini 或 my.cnf 文件常被精简或权限锁定。
- 连进 MySQL 执行
SHOW VARIABLES LIKE 'character_set_server';，结果必须是utf8mb4，不是utf8或latin1 - 检查配置文件（如
C:\phpEnv\MySQL\my.ini）的[mysqld]段，必须有：character-set-server = utf8mb4collation-server = utf8mb4_unicode_ciskip-character-set-client-handshake = ON - 改完配置一定要通过控制面板「重启 MySQL 服务」，不是关窗口或杀进程
服务端没对齐，PHP 侧所有 SET NAMES、set_charset、charset=... 都只是在错的基础上打补丁，越补越乱。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
