必须加u修饰符，否则pcre引擎按字节解析utf-8中文导致匹配失败；需确保文件utf-8无bom，\p{han}比[\x{4e00}-\x{9fa5}]更全，空白符类正则处理utf-8时也必须加u。
不加 u 修饰符，所有中文正则匹配都会失效或乱码——这不是兼容性问题，是 PCRE 引擎的底层行为，漏掉就等于没写。
preg_match 匹配中文返回 false 的真实原因
常见现象：preg_match('/[\x{4e00}-\x{9fa5}]+/', '你好') 永远返回 false，哪怕字符串确为 UTF-8 编码。
根本不是“环境没配好”，而是 PCRE 默认按字节解析：UTF-8 中的“你”是 3 字节 \xe4\xbd\xa0，引擎把它当三个独立字节处理，\x{4e00} 这种 Unicode 码点写法直接被忽略或报错。
- 必须加
u，否则\x{...}和\p{Han}全部无效 - 文件本身必须存为 UTF-8 无 BOM，否则源码里的
\x{4e00}可能被编辑器转成乱码再参与编译 -
mb_internal_encoding('UTF-8')不影响正则，只影响mb_*函数
用 \p{Han} 还是 [\x{4e00}-\x{9fa5}]？
\p{Han} 是更可靠的选择，但前提是 PHP 编译时启用了 PCRE Unicode 属性支持（现代版本基本默认开启）。
验证方式：var_dump(pcre_version())，输出中含 Unicode property support 即可。
-
/^\p{Han}+$/u覆盖汉字扩展 A/B 区、部首、康熙字典部件等，比[\x{4e00}-\x{9fa5}]更全 -
[\x{4e00}-\x{9fa5}]漏掉“㐀”“䶵”“?”等常用扩展字，也排除全角标点和中文符号（如“，”“。”，它们属\p{Pc}） - 别写成
/^[x{4e00}-x{9fa5}]+$/u——x不是\x，会直接触发编译失败
为什么加了 u 还出现乱码？重点查这三处
典型表现：preg_replace('/[ \t\n\r\v]+/u', '', '加强和改进党的作风') 输出“加强和改进党风”——“作”字变乱码。
原因：未加 u 时，\v 在 PCRE 中会匹配 U+0085（NEL，UTF-8 编码为 \xc2\x85），而“党”字 UTF-8 是 \xe5\x85\x9a，中间字节 \x85 被误识别为 NEL，导致截断。
- 所有含空白符类的正则（
\s、\v、[ \f\n\r\t\v]）只要处理 UTF-8 字符串，就必须加u - 避免混用：
\s在u模式下包含更多 Unicode 空白（如 、U+2028），而[ \t\n\r]是显式字面量，更可控 - 若需保留换行但删其他空白，用
/[ \t\v\f]+/u显式列出，别依赖\s的隐式行为
验证是否为纯中文、含中文、或清理乱码的写法
业务语义不同，正则结构差异很大，不能套用同一模式。
- 纯中文（不含空格/标点）：
/^\p{Han}+$/u或/^[\x{4e00}-\x{9fa5}]+$/u - 含中文（至少一个）：
/\p{Han}/u—— 删掉^、$、+，否则逻辑错误 - 中文+字母+数字：
/^[\p{Han}a-zA-Z0-9]+$/u，注意\p{Han}必须在字符组内，不可写成/^\p{Han}|[a-zA-Z0-9]+$/u - 清理损坏 UTF-8 字节：
preg_replace('/[\x00-\x08\x0B\x0C\x0E-\x1F\x7F-\x9F]|[\xC0-\xC1\xF5-\xFD][\x80-\xBF]++|[\x80-\xBF]/', '', $str)，这个正则专治传输中字节丢失导致的乱码
最易被忽略的一点：正则本身没问题，但上游数据已非合法 UTF-8（比如 GBK 字节流被当 UTF-8 读入），此时加 u 只会让匹配更早失败，得先用 mb_detect_encoding() 或 iconv('UTF-8', 'UTF-8//IGNORE', $str) 做预清洗。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
