PHP连接MySQL中文乱码的核心是客户端、连接层、表结构、PHP脚本、HTTP响应五层编码必须全部对齐为utf8mb4，缺一不可；phpEnv中需修改my.cnf/my.ini的client[mysqld]三节并重启服务，建库建表须显式指定utf8mb4，PHP连接后须立即set_charset或DSN加charset=utf8mb4，且PHP文件须存为UTF-8无BOM。
phpEnv 里 MySQL 乱码，核心问题不是“怎么设 utf8mb4”，而是“设在哪一层、谁在生效、谁被忽略”——服务端、连接层、表结构、PHP 脚本、HTTP 响应，五处必须全部对齐，缺一不可。
phpEnv 的 MySQL 配置文件在哪？改完要重启吗？
phpEnv 默认不修改 MySQL 的全局配置，它只是套壳管理多个版本。实际配置文件路径取决于你安装的 MySQL 版本，常见位置有：
-
phpenv/versions/mysql-8.0.33/my.cnf（Windows 下可能是my.ini） - 或系统级路径：
C:/phpenv/versions/mysql-*/data/my.ini
必须同时设置以下三项（仅改 character-set-server 不够）：
[client] default-character-set = utf8mb4 [mysql] default-character-set = utf8mb4 [mysqld] character-set-server = utf8mb4 collation-server = utf8mb4_unicode_ci skip-character-set-client-handshake = OFF
改完后必须重启 MySQL 服务（在 phpEnv GUI 中点“Restart MySQL”或命令行执行 phpenv mysql:restart），否则配置不加载。
立即学习“PHP免费学习笔记（深入）”；
phpEnv 下 PHP 连接 MySQL 后 set_charset 失效？
phpEnv 自带的 PHP 扩展（mysqli/pdo_mysql）默认没问题，但常见失效原因是：连接建立后没立刻调用 set_charset('utf8mb4')，或用了过时写法。
- PDO 方式：DSN 中
charset=utf8mb4是必须项，不能省略；utf8会静默退化为三字节编码，存 emoji 直接报Incorrect string value - mysqli 方式：必须在
new mysqli()之后、任何查询之前调用$mysqli->set_charset('utf8mb4')；用mysqli_query($link, "SET NAMES utf8mb4")不可靠，尤其在持久连接或连接池场景下 - 验证是否生效：连接后立即执行
SELECT @@character_set_client, @@character_set_connection, @@character_set_results，三者都得是utf8mb4
建库建表时没显式指定 utf8mb4，phpEnv 会自动继承吗？
不会。phpEnv 不干预 SQL 执行逻辑，MySQL 服务端即使配置了 character-set-server=utf8mb4，新建数据库/表仍可能沿用旧默认（尤其是从旧备份恢复或 ORM 自动生成时）。
- 建库必须写全：
CREATE DATABASE mydb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 建表必须显式声明：
CREATE TABLE t (name VARCHAR(255)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci - 已有表修正用：
ALTER TABLE t CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci（注意锁表，大数据量慎用） - 验证语句：
SHOW CREATE TABLE t，确认输出中DEFAULT CHARSET=utf8mb4和COLLATE=utf8mb4_unicode_ci都存在
phpEnv 环境下 header() 和 HTML meta 都设了 utf-8，还是乱码？
说明问题不在前端，而在「PHP 文件自身编码」或「MySQL 连接层」。phpEnv 的 Windows 环境特别容易踩这个坑：
- PHP 源文件必须保存为 UTF-8 无 BOM——VS Code 右下角显示“UTF-8”且没有 “with BOM” 字样；Notepad++ 要选“编码 → 转为 UTF-8 无 BOM 格式”
- 检查是否误用
mb_internal_encoding('GBK')或其他非 UTF-8 设置，它会影响mb_*函数行为，间接导致字符串处理出错 - phpEnv 的 Apache/Nginx 默认不加
AddDefaultCharset，但若你手动改过配置，需确认没覆盖 PHP 的header()，比如AddDefaultCharset GBK会强行覆盖 - 最隐蔽的一点：phpEnv 启动的 MySQL 服务，如果用的是 ZIP 解压版而非 installer 版，
my.ini可能根本没被读取——运行mysql --help | findstr "Default options"查看实际加载的配置文件路径
字符集不是单点配置，而是一条从 MySQL 配置文件 → 表结构 → PHP 连接 → PHP 源码 → HTTP 响应头 → HTML meta 的完整链条。任意一环断开，中文、emoji、生僻字就可能变成 ? 或乱码，且错误表现还可能延迟出现（比如只在某次查询后才崩）。
