必须加u修饰符，否则Unicode范围如[\x{4e00}-\x{9fff}]会失效或报错PREG_BAD_UTF8_OFFSET_ERROR；PHP默认不原生支持UTF-8多字节字符，中文需u修饰符确保正确按字符而非字节匹配。
PHP中用preg_match匹配中文的正确写法
直接上结论：必须加u修饰符，否则[\x{4e00}-\x{9fff}]这类Unicode范围会失效，甚至报错PREG_BAD_UTF8_OFFSET_ERROR。
PHP默认正则引擎不原生支持UTF-8多字节字符，中文属于Unicode区块，不加u时，正则会把一个中文字符（如“中”）当成2–3个独立字节处理，导致匹配失败或越界。
正确写法示例：
$text = "姓名：张三，年龄：25";
if (preg_match('/姓名：([\x{4e00}-\x{9fff}]+)，/u', $text, $matches)) {
echo $matches[1]; // 输出：张三
}
-
[\x{4e00}-\x{9fff}]覆盖常用汉字（基本汉字区），不是全部中文字符（比如中文标点、扩展A/B区汉字需额外补充） -
/u必须写在正则末尾，且前面不能有空格；漏写或写成/U（大写）都会失效 - 确保
$text本身是UTF-8编码，否则即使正则对了也匹配不到——常见于从GBK数据库或文件读取后未转码
匹配更全的中文字符（含标点、全角符号）
仅靠[\x{4e00}-\x{9fff}]会漏掉「，。！」「～」「《》」「〇」「々」等，实际场景建议用更宽泛的组合。
立即学习“PHP免费学习笔记（深入）”；
推荐写法（兼顾可读性与覆盖率）：
// 匹配汉字 + 中文标点 + 全角ASCII（如全角数字、字母）
preg_match('/[\x{4e00}-\x{9fff}\x{3400}-\x{4dbf}\x{20000}-\x{2a6df}}\x{3000}-\x{303f}\x{ff00}-\x{ffef}]+/u', $text, $matches);
-
\x{3400}-\x{4dbf}：CJK扩展A区（生僻字） -
\x{20000}-\x{2a6df}}：CJK扩展B区（需PHP 7.0+，且PCRE编译支持UTF-32） -
\x{3000}-\x{303f}：中文标点、注音、平假名、片假名 -
\x{ff00}-\x{ffef}：全角ASCII字符（如“ＡＢＣ”“１２３”） - 如果只处理简体常用文本，
[\x{4e00}-\x{9fff}\x{3000}-\x{303f}]+已够用，性能更好
用mb_ereg替代？不推荐
有人想到用mb_ereg系列函数避开PCRE的UTF-8问题，但实际更麻烦：
-
mb_ereg不支持Unicode属性类（如\p{Han}），写法冗长 - 性能比
preg_match低约30%–50%，尤其长文本下明显 - 部分环境（如某些Docker镜像）默认禁用
mbstring扩展，易出Call to undefined function错误 - 语法不兼容PCRE，迁移和调试成本高
除非你已被preg的u修饰符卡死（比如老旧PHP 5.2且无法升级），否则坚持用preg_match加u。
常见报错和绕过陷阱
最常遇到的不是匹配不到，而是PHP直接报错或返回false却不提示原因：
-
Warning: preg_match(): Compilation failed: PCRE does not support \L, \l, \N, \P, \p, \U, \u, or \X→ 说明PCRE版本太老（[\x{4e00}-\x{9fff}]代替\p{Han} - 匹配结果为空但没报错 → 检查输入字符串是否为UTF-8：
var_dump(mb_detect_encoding($text))，不是就用mb_convert_encoding($text, 'UTF-8', 'GBK')转 - 用
str_replace预处理时破坏了UTF-8（比如用substr截断中文）→ 改用mb_substr - 正则里混用
.*和中文范围，导致贪婪匹配跨段落 → 改用.*?或明确限定边界
真正难的不是写对正则，而是确认整个数据流（输入来源→编码检测→转码→正则执行）每一步都落在UTF-8轨道上。漏掉任意一环，u修饰符就形同虚设。
