根本原因是编码链断裂：读取、处理、写入三环节编码不一致。php默认按字节流读取，不解析bom或猜测编码；str_replace二进制安全但要求所有字符串编码统一；file_put_contents原样落盘，不自动转码；须统一检测、转换、写回编码，并确保脚本、服务器、html、数据库四端编码对齐。
PHP替换文件内容时出现中文乱码，根本原因不是str_replace或file_put_contents本身出错，而是编码链断裂：读取、处理、写入三个环节的字符编码不一致。只要任一环是GBK而其余是UTF-8，就会崩。
为什么file_get_contents读出来就是乱码？
PHP默认按原始字节流读取，不解析BOM，也不猜测编码。如果文件实际是GBK，而你的脚本在UTF-8环境下直接用file_get_contents读，得到的就是一串错位字节——后续所有替换都基于错误输入，结果必然乱。
- 先确认真实编码：
file -i filename.txt（Linux/macOS），或用VS Code右下角查看 - 别信编辑器“显示为UTF-8”——它可能只是强行渲染，实际存储仍是GBK
- 如果文件带BOM（
\xEF\xBB\xBF），file_get_contents会原样读入，但PHP不会自动剥离，可能导致正则匹配失败或开头多出字符
str_replace能安全替换中文吗？
可以，但前提是参与替换的所有字符串编码一致。str_replace是二进制安全函数，它只做字节级匹配，不关心语义。所以：
- 如果
$subject是GBK编码，$search和$replace也必须是GBK，否则一个中文字符被拆成两个字节去匹配，大概率找不到 - 避免混用：
str_replace('你好', '您好', $content)—— 这三个字符串必须同编码，否则白替 - 复杂场景（如带中文的正则）必须加
u修饰符：preg_replace('/\p{Han}+/u', 'XXX', $content)，且确保$content已是UTF-8
file_put_contents写入后中文变方块或问号？
写入乱码几乎全是“编码错配”：你把UTF-8字节当GBK写进了GBK文件，或反之。PHP从不自动转码，file_put_contents就是原样落盘。
- 写入前务必确认目标文件期望的编码——不是“你想用什么”，而是“它本来是什么”
- 统一内部处理为UTF-8：读取后立刻用
mb_convert_encoding($content, 'UTF-8', $detected_encoding)转正，所有逻辑在此编码下进行 - 写入前再转回目标编码：
mb_convert_encoding($new_content, $target_encoding, 'UTF-8') - 需要BOM时手动加：
$content = "\xEF\xBB\xBF" . $content;（仅对UTF-8有效，GBK加了反而乱）
最容易被忽略的是：PHP脚本自身编码、Web服务器响应头、HTML meta、数据库连接字符集，这四者必须全部对齐为UTF-8（或全部GBK）。单改file_put_contents那一行没用——乱码是系统性失配，不是某个函数的锅。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
