根本原因是PCRE默认按单字节处理字符串，未加u修饰符时无法正确解析UTF-8多字节字符，导致截断、错位、匹配失败或乱码；必须添加u修饰符启用UTF-8模式，并确保源字符串、文件编码、数据库及HTTP输入均为合法UTF-8。
PHP preg_match 用 UTF-8 字符串时匹配失败或乱码
根本原因不是正则写错了，而是没告诉 PCRE 引擎当前字符串是 UTF-8 编码。默认情况下 preg_match 把字节当 ASCII 处理，遇到中文、emoji 等多字节字符就会截断、错位，表现就是匹配不到、offset 错乱、甚至返回 false 而不报错。
解决办法只有一条：在正则模式末尾加 u 修饰符，强制启用 UTF-8 模式。
-
u修饰符必须存在，缺了就按单字节处理 —— 即使源字符串本身是合法 UTF-8 也不行 - PHP 文件编码必须是 UTF-8（无 BOM），否则
"/中文/u"这种字面量可能被解析成乱码 - 如果从数据库或 HTTP 请求读取字符串，要确认它确实是 UTF-8 编码，可用
mb_detect_encoding($str, ['UTF-8'], true)辅助判断
中文提取、emoji 匹配等常见场景怎么写正则
加了 u 之后，\w、\d、. 等元字符才真正支持 Unicode：比如 \w 能匹配汉字、日文假名；. 能匹配一个 Unicode 字符（而非一个字节）。
但注意：\w 默认不包含中文标点、全角数字，需要显式补充范围：
立即学习“PHP免费学习笔记（深入）”；
// 提取连续中文（含常用中文标点）
preg_match_all('/[\x{4e00}-\x{9fff}，。！？；：“”‘’（）【】《》、]+/u', $text, $matches);
// 匹配 emoji（基础版，覆盖大部分常用 emoji）
preg_match_all('/[\x{1f300}-\x{1f6ff}\x{1f900}-\x{1f9ff}\x{2000}-\x{206f}\x{fe00}-\x{fe0f}]/u', $text, $matches);
// 匹配“中文+英文+数字”的混合词（如“测试abc123”）
preg_match('/[\x{4e00}-\x{9fff}a-zA-Z0-9]+/u', $text, $matches);
preg_replace 处理中文时替换结果变乱码
乱码通常来自两方面：一是没加 u 修饰符，二是替换内容里混入了非 UTF-8 编码的字符串（比如从 GBK 数据库读出未转码的字段）。
- 确保
preg_replace的 pattern 和 replacement 都在u模式下运行：preg_replace('/\s+/u', ' ', $text) - replacement 中若含变量，先用
mb_convert_encoding($var, 'UTF-8', 'auto')统一转码，避免把 GBK 字节流直接拼进 UTF-8 字符串 - 慎用
e修饰符（已废弃），改用preg_replace_callback+u，回调函数内可安全调用mb_substr等多字节函数
为什么 mb_ 系列函数有时比 preg 更稳
正则再小心也依赖编码一致性，而 mb_ 函数（如 mb_substr、mb strpos）天然按字符而非字节操作，对 UTF-8 更友好，尤其适合简单切分、查找、长度判断。
- 要取前 10 个汉字？用
mb_substr($text, 0, 10, 'UTF-8')比写/^.{10}/u更直观、更少出错 - 要找某个中文关键词位置？
mb_strpos($text, '配置项', 0, 'UTF-8')比preg_match快且无编译开销 - 正则真正不可替代的场景是：复杂模式、上下文约束、捕获分组 —— 其他时候优先考虑
mb_*
$_POST 或 PDO::FETCH_ASSOC 返回的字符串看似是中文，实则是 GBK 字节流塞进了 UTF-8 上下文 —— 此时加再多 u 也没用。 
