pdo_set_charset() 经常不生效是因为它只在连接建立后修改客户端通知编码，不改变服务端初始化的字符集；最可靠方式是在 dsn 中直接指定 charset=utf8mb4，并确保 mysql 服务端、数据库、表、字段及 php 字符串均为 utf8mb4 编码。
pdo_set_charset() 为什么经常不生效
因为 PDO::setCharset() 只在连接已建立后才起作用，而 MySQL 服务端可能已经按默认字符集（比如 latin1）初始化了连接上下文。更关键的是，它只影响客户端通知服务端“我接下来发的 SQL 是什么编码”，并不改变连接本身的初始字符集协商结果。
- 必须在
new PDO()实例化之后、执行任何查询之前立即调用$pdo->setCharset('utf8mb4') - 仅对 MySQL 驱动有效；SQLite、PostgreSQL 不支持该方法
- 如果 MySQL 服务端配置中
character-set-server不是utf8mb4，即使设了也没用——服务端会默默降级回 latin1
DSN 中加 charset= 参数最稳妥
在创建 PDO 连接时，直接把字符集声明写进 DSN，让驱动在握手阶段就告诉 MySQL “我要 utf8mb4”，这是最可靠的方式。
- 正确写法：
$pdo = new PDO('mysql:host=localhost;dbname=test;charset=utf8mb4', $user, $pass); -
charset=utf8已过时，不能存 emoji；务必用utf8mb4 - 注意：PHP 5.3.6+ 才真正支持 DSN 中的
charset参数，旧版本会被忽略 - Windows 下若用命名管道或 Unix socket，
charset仍有效，但部分旧 MySQL 客户端库可能不识别
MySQL 服务端没配对，PDO 再怎么设都是白搭
PDO 设置只是客户端行为，如果 MySQL 的 my.cnf 里没配好，默认还是 latin1，插入中文会变问号或乱码。
- 检查当前连接实际字符集：
SHOW VARIABLES LIKE 'character_set%';，重点关注character_set_client、character_set_connection、character_set_database - 必须在
[mysqld]段落加：character-set-server = utf8mb4和collation-server = utf8mb4_unicode_ci - 重启 MySQL 后，新连接才会继承；已有连接不受影响
- 数据库/表/字段也得单独设为
utf8mb4，否则建表语句里没指定，依然用默认字符集
预处理语句里中文乱码？检查 bindParam 的数据源编码
就算 PDO 和 MySQL 都设对了，如果 PHP 字符串本身不是 UTF-8 编码（比如从 GBK 文件读入、或经 iconv('GBK', 'UTF-8', $str) 转换失败），绑定进去照样出错。
- 用
mb_detect_encoding($str, ['UTF-8', 'GBK'], true)确认字符串真实编码 -
bindParam()不做编码转换，它只是把 PHP 变量原样传给 MySQL 协议 - 避免用
mysql_real_escape_string()类旧函数混用，它们和 PDO 字符集逻辑不兼容 - Web 请求中，确保
$_POST或file_get_contents('php://input')的原始字节就是 UTF-8——这取决于前端<meta charset="utf-8">和 HTTPContent-Type: text/html; charset=utf-8
字符集问题从来不是单点配置能解决的，PDO 层、MySQL 服务层、表结构、PHP 字符串、HTTP 传输链路，五处缺一不可。最容易被跳过的，是确认 MySQL 实际运行时的 character_set_client 值——它不看你 DSN 怎么写，只看服务端配置和握手结果。
