preg_replace替换失败却没报错，因为其在正则语法错误、PCRE编译失败或超时（如ReDoS）时静默返回null而非原字符串；必须检查返回值是否为null，并调用preg_last_error()捕获具体错误。
preg_replace 为什么替换失败却没报错？
因为 preg_replace 在正则语法错误、PCRE编译失败或超时（如遭遇 ReDoS）时，会静默返回 null，而不是原字符串。这和 str_replace 的“不匹配就返回原串”行为完全不同。
实操建议：
- 每次调用后必须检查返回值：
if ($new_content === null) { /* 处理错误 */ } - 启用 PCRE 错误报告：在开发环境加
ini_set('pcre.jit', 0)并捕获preg_last_error()，比如if (preg_last_error() !== PREG_NO_ERROR) { throw new RuntimeException('PCRE error: ' . preg_last_error_msg()); } - 避免用户输入直接拼接进正则：用
preg_quote($user_input, '/')转义，否则$user_input = 'a.b+c'会导致模式变成/a.b+c/—— 这不是字面匹配，而是“a + 任意字符 + b + 一个或多个 c”
中文匹配总失效？90% 是 u 修饰符没加
PHP 的 PCRE 默认按字节处理，UTF-8 中文是多字节字符。不加 u 修饰符时，\w 不匹配汉字，. 不跨字节，甚至 /姓名：(.+)/ 可能只捕获到“姓”字后面半个乱码。
常见现象：
立即学习“PHP免费学习笔记（深入）”；
- Notepad++ 里能匹配，PHP 里
preg_match返回 0 - 替换结果出现 符号，或只替换前半截
-
\p{Han}、\p{L}等 Unicode 属性完全不生效
正确写法必须带 u：preg_replace('/姓名：(\p{Han}+)/u', '姓名：（已确认）', $content)。注意：文件本身也得是 UTF-8 编码（无 BOM 更稳妥），否则 file_get_contents 读出来就是乱码，再强的正则也救不回来。
大文件不能用 file_get_contents？流式替换怎么保正则完整
超过 50MB 的文件，一次性读入内存容易 OOM；但流式逐行读取又会让跨行匹配（比如 HTML 标签、JSON 对象、多行注释）彻底失效——正则根本看不到换行前后的上下文。
务实解法只有两个：
- 如果业务允许，把“跨行”需求降级：例如只替换每行开头的配置项，用
fgets+preg_replace('/^host\s*=\s*.*/m', 'host = 127.0.0.1', $line)，m修饰符让^和$匹配每行首尾 - 真需跨块匹配（如替换整个
<script>...</script>），只能分块读取并手动维护缓冲区，保留末尾若干字符（比如 2KB）作为下一块的前缀，同时限制最大匹配跨度（如最多跨 3 个块），否则逻辑爆炸且难调试
别信“边读边写原文件”的方案——fopen($file, 'c+') + fseek + fwrite 极易破坏文件长度和二进制结构，尤其 Windows 下换行符处理更不可靠。
替换后文件变空或换行错乱？FILE_BINARY 不是可选项
file_put_contents($path, $content) 在 Windows 上默认用 TEXT 模式写入，会把 \n 自动转成 \r\n，而 PHP 读取时是原始字节，一来一回就可能让 JSON 或 ini 文件格式损坏；更糟的是，如果 $content 为 false 或空字符串，它也会安静地写入空文件，不报错。
关键动作：
- 写入时强制加
FILE_BINARY标志：file_put_contents($path, $content, FILE_BINARY | LOCK_EX) - 写入前校验：
if (!is_string($content) || $content === '') { throw new InvalidArgumentException('内容为空'); } - 生产环境务必加
LOCK_EX，防止并发写入时互相覆盖 - 敏感文件操作前先备份：
copy($path, $path . '.backup.' . date('Ymd-His'))
最隐蔽的坑是：你写了 FILE_BINARY，但上游 preg_replace 返回了 null，file_put_contents 就把 null 当字符串写进去——结果文件头几个字节变成 0x00，后续全乱码。所以 null 检查必须在写入之前。
