str_replace不能直接处理文件路径，必须配合file_get_contents和file_put_contents读写文件；换行符需归一化；正则替换用preg_replace；大文件需流式处理；编码与BOM需用bin2hex检测。
str_replace 不能直接处理文件路径
它只操作字符串，不读写文件。你传一个 $path 给 str_replace()，什么都不会发生——函数根本不知道那是文件。必须显式读取、替换、再写回。
常见错误现象：代码跑完没报错，但文件内容一动不动。原因就是漏了 file_get_contents() 和 file_put_contents() 这两步。
- 中小文件（file_get_contents() + str_replace() + file_put_contents() 最稳妥
- 务必检查
file_get_contents()返回值是否为false（文件不存在、权限不足、路径错误都会导致） -
file_put_contents()默认覆盖原文件；加FILE_APPEND是追加，不是替换，别误用
特殊字符替换失败的常见编码陷阱
PHP 字符串函数是字节安全的，但不自动识别编码。UTF-8 BOM、GBK 中文空格、Windows 的 \r\n 都可能让 str_replace() 失效——比如你搜 " "，实际文件里是 chr(194).chr(160)（NBSP），就完全匹配不上。
使用场景：处理用户上传的 CSV、日志、或跨平台编辑过的配置文件时，这类问题高频出现。
立即学习“PHP免费学习笔记（深入）”；
- 先统一转码：
mb_convert_encoding($content, 'UTF-8', 'auto')，但注意可能丢字（尤其含 GBK 乱码时） - 更可靠的是明确约定源文件编码，比如强制用
file_get_contents($path, false, stream_context_create(['http' => ['encoding' => 'UTF-8']]))不现实，实际靠文档或上游约定 - 换行符归一化：
str_replace(["\r\n", "\n", "\r"], "\n", $content)，避免因换行差异导致替换位置偏移
需要正则匹配时必须用 preg_replace
str_replace() 只能做固定字符串替换，遇到“所有标点”“连续空白”“HTML 标签”这类需求，必须切到 preg_replace()。
参数差异明显：preg_replace() 第一个参数是模式（带分隔符，如 '/[^a-zA-Z0-9]/'），第二个是替换内容，第三个才是目标字符串；而 str_replace() 前两个参数顺序相反。
- 去掉所有中文标点：
preg_replace('/[\x{ff01}-\x{ff5e}\x{3002}\x{ff1f}\x{ff0c}\x{ff1b}\x{ff1a}\x{ff08}\x{ff09}]/u', '', $str) - 替换多个不同空格（普通空格、NBSP、全角空格）：
preg_replace('/[\s\x{a0}\x{3000}]+/u', ' ', $str) - 注意
/u修饰符——没它，Unicode 字符匹配基本失效
大文件必须流式处理，否则内存爆炸
几百 MB 的日志或导出数据，用 file_get_contents() 会直接触发 Fatal error: Allowed memory size exhausted，甚至进程被系统 OOM killer 干掉。
性能影响：逐行读写比一次性加载慢，但可控；原子性更重要——中间出错不能留半截损坏文件。
- 用
fopen()打开源文件和临时文件（如$tmp = $path . '.tmp'） - 循环
fgets()读一行 →str_replace()或preg_replace()→fwrite()写入临时文件 - 全部成功后，用
rename($tmp, $path)原子替换（Linux/macOS 下是原子操作，Windows 上有小概率失败需重试） - 千万别用
file()把整文件读成数组——它内部还是调file_get_contents()，一样爆内存
bin2hex(substr($content, 0, 32)) 看开头几个字节，确认真实编码和不可见字符类型，再决定怎么替换。 
