preg_replace() 是清理 PHP 日志敏感信息的正确方式，需按语义编写精准正则（如IPv4、手机号、password=值等），配合 i/u 修饰符，避免误删结构信息；禁用 preg_match_all()+循环替换以防偏移错乱。
用 preg_replace() 清理 PHP 日志中的敏感信息
直接上手：日志里混着 IP、手机号、token、密码字段？别用 str_replace() 硬换，得靠 preg_replace() 做模式化擦除。核心是写对正则，再配好修饰符。
常见错误是写太宽泛的模式，比如 /\d+/ 一把梭——结果把时间戳、行号、HTTP 状态码全干掉了。得按字段语义匹配：
-
/\b(?:[0-9]{1,3}\.){3}[0-9]{1,3}\b/匹配 IPv4（加\b防止匹配到 123.456.789.012 中的子串） -
/\b1[3-9]\d{9}\b/匹配大陆手机号（注意边界，避免误伤 138123456789 中的前 11 位） -
/password\s*=\s*["']?[^"'\s]+["']?/i匹配password=xxx或Password: 'abc123'类型
实际调用时务必加 i（忽略大小写）和 u（UTF-8 安全），尤其日志含中文路径或用户名时：
$clean_log = preg_replace([
'/\b(?:[0-9]{1,3}\.){3}[0-9]{1,3}\b/',
'/\b1[3-9]\d{9}\b/',
'/(token|auth|key)\s*[:=]\s*["\']?[^"\'\s]{10,}["\']?/i',
], '[REDACTED]', $raw_log);
为什么不能用 preg_match_all() + 循环替换
有人先 preg_match_all() 找出所有匹配项，再逐个 str_replace() ——这会破坏日志结构。比如同一行有多个 IP：[2024-01-01] GET /api from 192.168.1.100 and 10.0.0.5，两次 str_replace() 可能因字符串偏移错位，第二次替换把 10.0.0.5 替成 [REDACTED].0.5。
立即学习“PHP免费学习笔记（深入）”；
preg_replace() 是原子操作，一次扫描、一次定位、一次替换，位置精准。性能也更好——不用反复遍历字符串。
另外注意：默认 PCRE 是贪婪匹配，.* 会吞掉整行。要提取字段值再脱敏？改用非贪婪 .*? 或明确字符集，比如 password\s*=\s*["\']([^"\']*)["\']，然后用 preg_replace_callback() 处理捕获组。
清理后保留原始日志格式的关键点
日志不是纯文本，是带结构的：时间戳、模块名、级别、消息体。乱删空格或换行会让 tail -f 或 ELK 解析失败。
- 别用
/\s+/替换空白——会把多空格缩成单空格，破坏对齐日志（如 Apache 的%h %l %u %t "%r" %s %b） - 替换内容长度尽量接近原内容，比如用
[REDACTED]（9 字符）替代 15 位 token，比全换成X更安全 - 若需保留字段占位但清空值，用
password=***而非password=，避免解析器误判为键值缺失
测试时拿真实日志片段跑一遍，再用 diff 对比前后，重点看时间戳、HTTP 方法、状态码是否完好。
PHP 8.2+ 的 PREG_UNMATCHED_AS_NULL 有什么用
这个标志和「清理日志」本身关系不大，但常被误用。它只影响 preg_match_all() 的返回数组：当某捕获组没匹配到时，填 null 而非空字符串。而日志清理几乎全是 preg_replace() 场景，不涉及捕获组提取，所以不用管它。
真正容易被忽略的是 PCRE JIT 编译和回溯限制。超长日志（比如单行 10MB 的 POST body dump）可能触发 PREG_BACKTRACK_LIMIT_ERROR。此时要么调大 pcre.backtrack_limit（不推荐），要么拆分行处理，或改用更轻量的 str_contains() + 白名单字段判断做前置过滤。
