file_get_contents读中文乱码的根本原因是PHP按原始字节流读取，未识别编码；若源文件为GBK而浏览器以UTF-8解析，或缺失header('Content-Type: text/html; charset=utf-8')，即出现方块、问号等乱码。
file_get_contents 读取中文内容为什么直接 echo 就乱码
因为 PHP 默认按原始字节流读取，不解析编码；浏览器收到内容后，若没收到 Content-Type 响应头或 HTML 中没 <meta charset="UTF-8">，就会用默认编码（通常是 ISO-8859-1 或 GBK）解码 UTF-8 字节，结果就是方块、问号或错位字符。
- 必须在
echo前调用header('Content-Type: text/html; charset=utf-8')，且不能有任何输出（包括空格、BOM、?>后的换行） - 用
file -i filename.php（Linux/macOS）或 VS Code 右下角编码标识确认文件真实编码，不是“看起来像 UTF-8” - 如果文件是 GBK 编码，而你环境是 UTF-8，
file_get_contents读出来就是 GBK 字节流，直接 echo 给 UTF-8 浏览器 = 乱码 —— 此时要先mb_convert_encoding($content, 'UTF-8', 'GBK')
str_replace 替换后写入文件，中文变乱码怎么办
str_replace 本身不碰编码，它只是二进制安全的字节替换；乱码根源在于：输入字符串编码 ≠ 目标文件期望编码 ≠ 写入时实际字节流。
- 统一内部处理编码：读取后立刻转成 UTF-8（如
$content = mb_convert_encoding(file_get_contents($file), 'UTF-8', 'auto')），所有str_replace、preg_replace都在这个 UTF-8 字符串上操作 - 写入前确认目标文件编码：若目标文件要求 GBK，必须
mb_convert_encoding($content, 'GBK', 'UTF-8')再file_put_contents；PHP 不会自动转码，file_put_contents就是原样 dump 字节 - 避免用
preg_replace处理中文时漏掉u修饰符：匹配 UTF-8 字符必须加/中文/u，否则正则引擎按单字节切分，会截断汉字
批量替换多个文件时，如何防止编码崩坏
批量操作放大了编码不一致的风险 —— 一个文件是 UTF-8 with BOM，另一个是 GBK，脚本却用同一套逻辑处理，必然部分失败。
- 不要依赖
mb_detect_encoding()做自动识别：它准确率低，尤其对短文本或混合编码，容易误判；宁可人工确认或按目录约定编码 - 写入前加 BOM 仅对 UTF-8 有效：
$content = "\xEF\xBB\xBF" . $content，可帮 Excel、记事本等工具识别编码，但别给 GBK 文件加 - 关键检查点：编辑器保存时选 “UTF-8 without BOM”，php.ini 中
default_charset = "UTF-8"，mbstring.internal_encoding = UTF-8，三者缺一不可
为什么改了 PHP 代码还是乱码？常被忽略的底层配置
光改 PHP 脚本没用 —— Web 服务器（Apache/Nginx）、数据库连接、甚至操作系统 locale 都可能覆盖你的设置。
立即学习“PHP免费学习笔记（深入）”；
- Apache 检查
AddDefaultCharset是否设为UTF-8；Nginx 检查charset utf-8;是否在 server 或 location 块中生效 - MySQL 连接必须显式设字符集：
mysqli_set_charset($conn, 'utf8mb4')或 PDO DSN 加charset=utf8mb4，SET NAMES utf8不够（不支持 emoji，且易被中间件重置） - PHP 文件自身若有 BOM（哪怕只有一字节
\xEF\xBB\xBF），会导致headers already sent错误，header()失效，整个响应头 fallback 到服务器默认编码
