php 8.0+ 默认加载 mbstring 但不自动统一字符集，乱码根源在于文件编码、http 响应头、html meta、数据库连接、内部函数五个环节任一不一致；必须确保全部为 utf-8 无 bom，并显式调用 mb_internal_encoding('utf-8')。
PHP 8.0+ 默认已启用 mbstring 扩展，但字符集仍不会自动统一——乱码根源从来不是 PHP 版本新旧，而是五个环节（文件编码、HTTP 响应头、HTML meta、数据库连接、内部函数）中任意一个掉链子。只要有一个是 GBK、ISO-8859-1 或带 BOM 的 UTF-8，中文就大概率显示为问号、方块或 。
PHP 文件必须存为 UTF-8 无 BOM
VS Code 打开 .php 文件后，右下角编码显示为 UTF-8 with BOM 或 GBK，立刻失效。BOM（\xEF\xBB\xBF）会卡在 header() 前，直接触发 headers already sent 错误。
- 在 VS Code 中：点击右下角编码 → “通过编码重新打开” → 选
UTF-8；再点编码 → “另存为编码” → 勾选UTF-8 (no BOM)覆盖保存 - Linux 下批量清除 BOM：
sed -i '1s/^\xEF\xBB\xBF//' *.php - 验证是否干净：
file -i your_script.php输出应含charset=utf-8且不含bom
header() 和 <meta charset> 必须同时写且大小写一致
只写 header('Content-Type: text/html; charset=utf-8') 不够：CDN 可能缓存旧响应头，Firefox 有时优先读 <meta>。二者不一致（比如一个写 UTF-8，一个写 utf-8）反而引发冲突。
-
header()必须放在所有输出之前：不能有空格、echo、print、HTML、甚至?>关闭标签后的换行 -
<meta charset="UTF-8">必须放在最开头，紧贴标签，不能在<title></title>或 CSS 引用之后 - 用
curl -I http://yoursite.com/test.php验证响应头是否真含charset=utf-8
MySQL 连接必须用 utf8mb4，不能只写 utf8
PHP 8.0+ 的 mysqli 和 PDO 默认不设字符集，即使表是 utf8mb4，连接层仍可能走 latin1。MySQL 的 utf8 是阉割版，最多存 3 字节字符（不支持 emoji 和部分生僻汉字），而 utf8mb4 才是完整 UTF-8。
- mysqli 连接后立即执行：
$mysqli->set_charset('utf8mb4') - PDO DSN 中必须显式加：
mysql:host=localhost;dbname=test;charset=utf8mb4 - 禁用模拟预处理：
PDO::ATTR_EMULATE_PREPARES => false，否则字符集可能被绕过 - 检查表字段：运行
SHOW CREATE TABLE user，确认VARCHAR字段声明含CHARACTER SET utf8mb4
内部字符串函数要切到 mb_*，且设好默认编码
PHP 默认的 strlen()、substr() 按字节算，对 UTF-8 中文会截断字节流，导致乱码或异常。PHP 8.x 虽默认加载 mbstring，但 mb_internal_encoding() 默认仍是 ISO-8859-1，不手动设就白搭。
- 在脚本开头（
header()后、任何字符串操作前）加：mb_internal_encoding('UTF-8') - 把所有
strlen($str)换成mb_strlen($str, 'UTF-8')，substr($str, 0, 10)换成mb_substr($str, 0, 10, 'UTF-8') - 避免用
iconv()做运行时转换：它容易因非法字节崩溃，除非明确知道源编码是 GBK
最容易被忽略的是 require/include 的文件——哪怕主脚本全合规，只要被引入的某个 .php 文件带 BOM 或含空格，header() 就会静默失败。建议把所有入口文件（如 index.php、api.php）单独检查一遍，别假设“它一直没出事就安全”。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
