匹配中文字符时preg_match返回false，是因为PCRE默认不支持UTF-8多字节字符，未加u修饰符会导致正则引擎解析失败而非无匹配；必须使用/u修饰符、确保PHP文件及输入字符串均为UTF-8编码，并可用preg_last_error()检测PREG_BAD_UTF8_ERROR等具体错误。
匹配中文字符时为什么 preg_match 返回 false？
因为默认 PCRE 模式不支持 UTF-8 多字节字符，没加 u 修饰符就会直接失败，不是“没匹配到”，而是正则引擎解析失败。
- 必须在正则末尾加上
u修饰符，例如：/[x{4e00}-x{9fff}]+/u - 确保 PHP 文件本身是 UTF-8 编码（无 BOM），且输入字符串也是 UTF-8（可用
mb_detect_encoding验证） -
preg_match对非 UTF-8 字符串返回false，不是0；错误时可调preg_last_error()查具体原因，比如PREG_BAD_UTF8_ERROR
用 preg_replace 替换多次出现的 HTML 标签要注意什么？
盲目写 /]+>/ 会误杀含 > 的属性值（如 onclick="alert('>')"），而且不处理嵌套或注释，实际场景中极易出错。
- 简单清洗可用
strip_tags()，比正则更安全、更快 - 若必须用正则，至少加
s修饰符让.匹配换行，并限制贪婪程度，例如：/]*>/s（仍不推荐用于复杂 HTML） - 替换为空字符串时，注意连续标签可能产生多余空格，建议后续用
preg_replace('/s+/', ' ', $str)整理空白
preg_match_all 提取多个 URL 时怎么避免重复捕获？
常见写法 /(https?://[^s]+)/ 在遇到长文本时容易把 URL 后面的标点（如句号、逗号）也吞进去，导致提取结果带干扰字符。
- 用单词边界
不可靠（URL 中有连字符、下划线），更稳妥的是用否定字符类 + 明确结束条件，例如：/(https?://[^s"{}|\^`[]]+)/ - 如果要兼容括号内的 URL（如 “参见：(https://a.com)”），需额外处理包围符号，不能只依赖
s - 使用
PREG_SET_ORDER比默认PREG_PATTERN_ORDER更易读，结果直接是每个匹配的完整数组
为什么 preg_replace_callback 的回调函数接收不到完整匹配？
回调函数第一个参数是完整的匹配结果数组，但新手常误以为只传入捕获组 —— 实际上 $matches[0] 是全匹配，$matches[1] 开始才是子组。
立即学习“PHP免费学习笔记（深入）”；
- 回调函数签名必须是
function($matches) { ... }，不能漏掉参数 - 若正则里用了命名捕获（如
(?P<year>d{4})</year>），可通过$matches['year']访问，但依然存在$matches[0] - 回调中修改
$matches不影响外部，返回值才是替换内容；返回null会导致该次替换为空字符串
