dsn里直接加charset=utf8mb4最可靠，php 5.3.6+支持握手阶段协商编码；不写则mysql按默认latin1初始化连接，后续set names无效；utf8不支持emoji，必须用utf8mb4。
DSN里直接加 charset=utf8mb4 最可靠
PDO连接MySQL时字符集乱码，90%是因为没在DSN里声明字符集。PHP 5.3.6+ 支持直接在dsn字符串中写charset=utf8mb4，这是握手阶段就协商编码的唯一确定方式。
错误写法：$pdo = new PDO('mysql:host=localhost;dbname=test', $user, $pass)——没带charset，MySQL服务端按默认latin1初始化连接，后续所有SET NAMES都晚了。
正确写法：$pdo = new PDO('mysql:host=localhost;dbname=test;charset=utf8mb4', $user, $pass)。注意：utf8mb4不是utf8，后者不支持emoji和部分生僻字。
Unix socket或Windows命名管道场景下也要保持charset参数位置靠后：例如mysql:unix_socket=/var/run/mysqld/mysqld.sock;dbname=test;charset=utf8mb4，否则PDO解析会截断。
$pdo->exec("SET NAMES utf8mb4") 是补救手段，不是首选
这个语句只在连接建立后发送一条初始化命令，它不改变MySQL服务端已初始化的连接上下文，也不影响预处理语句的编码协商逻辑。某些PDO驱动版本（尤其Laravel 8+）甚至会跳过执行。
适用场景仅限于：你无法修改DSN（比如用第三方封装库），且确认MySQL服务端character_set_server已是utf8mb4。
必须满足三个条件才可能生效：
- 调用时机必须在
new PDO()之后、任何查询之前 - 仅对MySQL驱动有效，SQLite/PostgreSQL不支持
- 不能和
PDO::MYSQL_ATTR_INIT_COMMAND重复设置，否则冲突
$pdo->setCharset('utf8mb4') 在旧环境容易失效
这个方法看似简洁，但底层依赖MySQL客户端库是否识别该指令。Windows上部分旧版libmysql.dll或macOS Homebrew安装的MySQL client会忽略它。
更关键的是：setCharset()只通知服务端“我接下来发的SQL是utf8mb4编码”，并不强制重置连接的character_set_client、character_set_connection、character_set_results三者。一旦服务端配置没对齐，仍会降级为latin1。
验证是否真正生效，别信返回值，要用：$pdo->query("SHOW VARIABLES LIKE 'character_set%'")->fetchAll()，重点检查上述三个变量是否全为utf8mb4。
达梦、SQL Server等非MySQL驱动要换写法
达梦数据库（DM8）要求DSN中写charset=UTF-8（注意大小写和短横线），写成utf8或utf-8都不认；ODBC方式则必须通过odbc.ini配置CharacterSet=UTF-8，DSN里不能带charset参数。
SQL Server用pdo_sqlsrv时，字符集由连接选项CharacterSet控制，值为UTF-8（同样区分大小写），且必须配合SQL Server 2019+和UTF-8排序规则（如Latin1_General_100_CI_AS_SC_UTF8）才真正生效。
所有非MySQL场景，SET NAMES和setCharset()基本无效，因为协议层不兼容。
最容易被忽略的一点：即使PDO连接层设对了，如果PHP源文件本身不是UTF-8 without BOM保存，或者前端HTTP请求头没声明Content-Type: application/json; charset=utf-8，中文照样进不来。字符集是端到端链条，断一环就乱码。
