能可靠判断字符串是否包含中文的是preg_match('/[\x{4e00}-\x{9fa5}]/u', $str)，必须加u修饰符，因PCRE不支持\u语法，且\x{4e00}-\x{9fa5}覆盖常用简繁汉字但不含扩展区及标点。
直接用 preg_match('/[\x{4e00}-\x{9fa5}]/u', $str) 就能可靠判断字符串是否包含中文，但必须加 u 修饰符，否则在 UTF-8 环境下会匹配失败或误判。
为什么不能用 /[\u4e00-\u9fa5]/？
PHP 的 PCRE 引擎不支持 \u 这种 JavaScript 风格的 Unicode 转义。写成 /[\u4e00-\u9fa5]/ 会直接报错：Compilation failed: PCRE does not support \u。必须改用 \x{4e00} 这种花括号包裹的十六进制 Unicode 表示法，并配合 u 修饰符启用 UTF-8 模式。
/[\x{4e00}-\x{9fa5}]/u 能覆盖哪些中文？
这个范围基本覆盖常用简体、繁体汉字（U+4E00–U+9FA5），但不包括：
- 扩展区 A（如“?”
\x{3400}–\x{4dbf}） - 扩展区 B 及之后（如“?”等生僻字）
- 全角 ASCII 符号（如 、。、！）或标点（它们不属于汉字 Unicode 区块）
若业务需兼容古籍或户籍系统级生僻字，应叠加扩展范围，例如：/[\x{3400}-\x{4dbf}\x{4e00}-\x{9fa5}\x{9fb0}-\x{9fff}]/u。
立即学习“PHP免费学习笔记（深入）”；
更轻量但有风险的替代方案：/[\x7f-\xff]/
这个表达式靠「非 ASCII 字节」粗筛，原理是 UTF-8 中文占 3 字节（首字节在 \x7f-\xff 范围），但它会把所有非 ASCII 字符（比如 emoji、俄文、日文假名、韩文）都当“中文”误判：
-
preg_match('/[\x7f-\xff]/', 'Hello ?')→ 返回 1（误报） -
preg_match('/[\x7f-\xff]/', 'こんにちは')→ 返回 1（误报） - 优点：不依赖
u修饰符，PHP 4 起就可用，对编码不敏感 - 缺点：零精度，仅适合纯中英混合且无其他语言字符的封闭场景
常见错误和绕不开的坑
以下写法在实际项目里高频出错：
- 漏掉
u修饰符 →preg_match('/[\x{4e00}-\x{9fa5}]/', $str)：UTF-8 字符被当单字节拆解，永远不匹配 - 用错括号或转义 →
/[\x4e00-\x9fa5]/u（缺花括号）：只匹配\x4e、\x00等零散字节，逻辑崩坏 - 混淆“含中文”和“全中文” → 检查是否含中文该用
/[\x{4e00}-\x{9fa5}]/u，而/^[\x{4e00}-\x{9fa5}]+$/u是验证整串是否纯中文，二者不可混用 - 没处理空字符串或 null →
preg_match对null返回false，建议前置is_string($str) && $str !== ''校验
真正要稳，就老实用 /[\x{4e00}-\x{9fa5}]/u，别贪快换别的正则——中文识别这事，边界模糊比性能损耗更致命。
