PHP替换文件内容乱码主因是读取、处理、写入三环节编码不一致，需统一为UTF-8：用file -i或编辑器确认源文件真实编码，读取后用mb_convert_encoding转为目标编码，str_replace无需u修饰符但preg_replace必须加u，写入前确保字符串编码与目标文件匹配，并手动添加BOM（如需）。
PHP替换文件内容时出现乱码，基本就是UTF-8没对齐——不是str_replace写错了，而是读进来、处理中、写出去这三个环节的编码状态不一致。
file_get_contents读取UTF-8文件为什么还是乱码
因为PHP默认按字节流读取，不解析BOM，也不自动识别编码。即使文件是UTF-8，如果它带BOM（\xEF\xBB\xBF），而你的脚本在无BOM环境下运行，开头就可能多出三个不可见字节；更常见的是，文件其实是GBK但被当成UTF-8读了。
- 先确认真实编码：
file -i filename.php（Linux/macOS）或用VS Code右下角查看 - 不要直接
echo file_get_contents('xxx.txt')测试——浏览器可能按自身缓存编码渲染，误导判断 - 读取后立刻检查前几个字节：
bin2hex(substr($content, 0, 3)) === 'efbbbf'可判断是否有UTF-8 BOM - 若不确定原始编码，慎用
mb_detect_encoding($content, ['UTF-8', 'GBK', 'BIG5'], true)——它只是启发式猜测，误判率高
str_replace和preg_replace在UTF-8下怎么不崩
str_replace本身是二进制安全的，不关心编码，所以只要输入字符串编码正确，它就不会“制造”乱码；但preg_replace必须加u修饰符，否则中文会被当多个字节切开匹配，导致截断或空匹配。
- 简单替换优先用
str_replace，比如str_replace('旧文本', '新文本', $content) - 正则替换必须带
u：preg_replace('/中文\d+/', '替换内容', $content, -1, $count)→ 改成preg_replace('/中文\d+/u', ...) - 避免用
substr或strlen定位替换位置——它们按字节算，UTF-8中文会算错长度；改用mb_substr和mb_strlen - 批量替换多个关键词时，别用循环套
str_replace，改用strtr($content, $replace_map)，效率更高且保持编码透明
file_put_contents写入后中文变方块或问号
根本原因：写入的字节流和目标文件期望的编码不匹配。PHP不做隐式转码，file_put_contents就是原样写入你给它的字节。
立即学习“PHP免费学习笔记（深入）”；
- 确保你要写的内容已经是UTF-8编码——如果来源是GBK数据库或旧文件，先调
mb_convert_encoding($str, 'UTF-8', 'GBK') - 写入前手动加UTF-8 BOM（仅当目标程序如Excel/Notepad需要）：
$content = "\xEF\xBB\xBF" . $content; - 不要依赖编辑器“自动保存为UTF-8”，用VS Code或Notepad++手动“另存为→UTF-8无BOM”再测试
- 如果目标文件原本是GBK，你又必须保持GBK格式，那就得反向转：
mb_convert_encoding($content, 'GBK', 'UTF-8')再写入
最容易被忽略的点是：Web服务器（Nginx/Apache）和PHP自身的default_charset设置，会影响header()默认行为，但对file_get_contents和file_put_contents完全无效——这两个函数只认你传进去的字节，不看任何配置。
