根本原因是未加u修饰符，pcre引擎按字节解析utf-8多字节字符导致编译失败；必须写成/x{4e00}-x{9fa5}+/u，且文件、字符串、正则三者编码须均为utf-8。
preg_match('/[x{4e00}-x{9fa5}]+/'返回false，不是没匹配到，是编译失败
根本原因：PCRE 引擎默认按字节解析，遇到 UTF-8 多字节字符（如“你”）会直接报错，而不是跳过或忽略。漏掉 u 修饰符时，/[x{4e00}-x{9fa5}]+/ 这种写法根本无法通过编译，preg_match 返回 false，且可能伴随 Warning: preg_match(): Compilation failed。
- 必须加
u：正确写法是/[x{4e00}-x{9fa5}]+/u，u不是可选，是强制要求 -
x{4e00}写法要带花括号：写成N00或u4e00都无效；PCRE 不识别u，只认x{HHHH} - 文件编码必须为 UTF-8 无 BOM：编辑器里存成 ANSI 或 GBK，源码里的
x{4e00}就会被读作乱码，导致模式字符串本身已损坏
为什么 p{Han} 更推荐，但用了还是失败？
p{Han} 确实比手写码点区间更全、更简洁，但它同样依赖 u 修饰符和底层 PCRE 的 Unicode 属性支持。失败通常不是语法错，而是环境没对齐。
- 必须写成
/p{Han}+/u：缺u时p{Han}直接被当成非法转义，编译失败 - 验证 PCRE 是否支持 Unicode 属性：
var_dump(pcre_version());输出中需含Unicode property support；旧版 PHP（如 5.6 未打补丁）可能不支持 -
p{Han}不包含中文标点、全角数字、日文假名：它只匹配汉字脚本（Han script），别指望它命中“，”、“。”，或“あ” - 输入字符串也得是 UTF-8：
mb_check_encoding($str, 'UTF-8') === false时，先用mb_convert_encoding($str, 'UTF-8', 'GBK')转换
匹配中文时常见误判：纯中文 vs 含中文
业务逻辑常混淆这两个概念，正则写法差一个符号，语义就完全相反。
- “只含中文”（纯中文）：用
/^p{Han}+$/u，^和$锚定首尾，中间只能是汉字 - “含中文”（至少一个）：用
/p{Han}/u，去掉量词和边界，只要出现就命中 - 混合内容提取（如“订单编号：123，客户：张三”）：用
preg_match_all('/p{Han}+/u', $str, $matches)，结果在$matches[0]；别用mb_ereg，已废弃 - 避免贪婪吞太多：
/p{Han}+.*[a-zA-Z]/u中的.*可能跨行吃掉中间所有内容，改用/p{Han}+s+[a-zA-Z]+/u更可控
调试时 preg_match 返回 false，怎么快速定位？
不能只看返回值，false 只说明出错了，但不知道错在哪。必须立刻查 preg_last_error()，否则永远在猜。
- 紧挨着
preg_match调用后检查：if (preg_match($pattern, $str) === false) { echo preg_last_error_msg(); } - 常见错误码：
PREG_BAD_UTF8_ERROR（输入非 UTF-8）、PREG_BAD_PATTERN_ERROR（括号不配对、转义错）、PREG_BACKTRACK_LIMIT_ERROR（回溯超限，长文本易触发） -
preg_last_error()是全局状态：中间调了别的preg_*函数就会覆盖，必须“调完立刻查” - 怀疑编码问题？用
bin2hex($str)看真实字节流，或json_encode($str)看是否输出"\uXXXX"格式
u，缺一不可。少一个，preg_match 就不是“匹配不上”，而是“根本没开始匹配”。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
