ThinkPHP5数据库连接层乱码主因是charset设错位置、值或被覆盖；须在DSN中写死charset=utf8mb4，删掉database.php中'charset'=>'utf8'配置，禁用MySQL伪utf8，改用utf8mb4，并验证@@character_set_client/connection/results均为utf8mb4，同时确保MySQL服务端character-set-server为utf8mb4。
ThinkPHP5数据库连接层乱码，根本不是“没设 charset”，而是设错了位置、设错了值、或设了但被覆盖。最常见的情况是：你改了 database.php 里的 'charset' => 'utf8'，但 PDO 实际连接用的还是 MySQL 客户端默认的 latin1 或 gbk。
为什么 'charset' => 'utf8' 在 database.php 里经常失效？
ThinkPHP5 的 'charset' 配置项只影响 PDO 构造时的 charset 参数（即 DSN 中的 charset= 子句），但它不强制生效——如果 DSN 字符串里已经显式写了 charset，这个配置就会被忽略；更糟的是，某些旧版 PDO 驱动根本不认这个参数，只看 DSN。
实操建议：
- 直接在
'dsn'字段里写死charset=utf8mb4，例如：'dsn' => 'mysql:host=127.0.0.1;dbname=thinkphp;charset=utf8mb4' - 删掉
'charset' => 'utf8'这一行，避免和 DSN 冲突 - 别用
utf8—— MySQL 的utf8是阉割版（最多 3 字节），存 emoji 或生僻字会变???，必须用utf8mb4
SET NAMES utf8mb4 放 params 里靠不住
'params' => [\PDO::MYSQL_ATTR_INIT_COMMAND => 'SET NAMES utf8mb4'] 看起来很规范，但在部分 PHP + PDO 组合（尤其是 PHP 5.6 + mysqlnd 5.0.11 以下）中会被静默跳过，查出来的中文仍是乱码。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
- 优先走 DSN 方式声明
charset=utf8mb4，这是 PDO 官方推荐且兼容性最好的路径 - 如果非要用
params，务必搭配mysql.default_charset = utf8mb4写进php.ini（仅限 CLI 或 Apache 模块环境） - 验证是否生效：连接后执行
Db::query('SELECT @@character_set_client, @@character_set_connection, @@character_set_results')，三个值都应为utf8mb4
数据库服务端没配对，PHP 层怎么设都没用
即使 DSN 写对了，只要 MySQL 服务端的 character_set_server 是 latin1 或 gbk，新创建的表默认就不是 utf8mb4，后续查字段定义、建索引、甚至 SHOW CREATE TABLE 都可能漏掉编码声明。
实操建议：
- 检查全局变量：
SHOW VARIABLES LIKE 'character\_set\_%';，重点确认character_set_server和collation_server是utf8mb4和utf8mb4_unicode_ci - 修改
/etc/my.cnf（Linux）或my.ini（Windows），在[mysqld]下加两行：character-set-server = utf8mb4和collation-server = utf8mb4_unicode_ci - 已有表必须单独转换：
ALTER TABLE user CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;，只改库或只改连接层不解决存量数据
真正卡住人的地方，往往不是“该不该设 utf8mb4”，而是设了之后没验证三个连接变量是否真同步，或者表结构还卡在老编码上。连 Db::name('user')->where('name', '张三')->find() 返回空数组，都可能是字段实际存的是乱码字节，而不是逻辑查不到。
