compilation failed是pcre编译期错误，正则未进入匹配阶段；常见原因包括字符类中-位置不当、定界符未闭合、误用\u而应使用\x{4e00}加u修饰符、php 7.3+后字符类范围校验更严格等。
preg_match Compilation failed 是编译期错误，不是运行时匹配失败
看到 Compilation failed 就说明正则根本没进匹配阶段——PCRE 在解析你写的 pattern 字符串时当场崩溃了。这时候 preg_match() 还没开始干活，preg_last_error() 也拿不到有效值（它只管运行时错误），必须从 pattern 本身找问题。
- 常见触发点：方括号
[]里用了未转义的-（比如[a-z0-9]写成[a-z09]或[0-9a-z]但-不在开头/结尾）、定界符漏写（/abc没闭合）、\u这种 JS 风格 Unicode 转义直接扔进 PHP 正则（PHP 只认\x{4e00}） - PHP 7.3+ 对字符类范围校验更严格，
[A-z]这种跨 ASCII 码段写法会报invalid range in character class - 用
#或~替代/当定界符，能立刻避开路径、URL 里大量斜杠导致的转义灾难
中文匹配报 Compilation failed: PCRE does not support \u at offset
这是最典型的“抄错语法”错误。你在 pattern 里写了 /[\u4e00-\u9fa5]/，PHP 的 PCRE 引擎根本不认识 \u —— 它只支持 Perl 兼容写法 \x{4e00}，而且必须配合 u 修饰符启用 UTF-8 模式。
- 错：
preg_match("/[\u4e00-\u9fa5]+/", $str)→ 直接报错 - 对：
preg_match("/[\x{4e00}-\x{9fa5}]+/u", $str)→u不能少，大括号也不能省 - 更稳：先用
mb_check_encoding($str, 'UTF-8')确认字符串是合法 UTF-8，否则加u反而让整个匹配失效
升级 PHP 后突然 Compilation failed，大概率是字符类写法不规范
PHP 7.2 升到 7.3+ 后，PCRE 库对字符类（[]）的语法检查变严。以前能蒙混过关的写法，现在直接编译失败。
-
[a-zA-Z0-9_-]放在末尾的-是安全的；但[a-z-A-Z]中间那个-会被当成范围连接符，而z-A是非法范围 → 报invalid range - 解决方案：把
-放最前或最后，或明确转义为\- - 其他危险写法：
[0-9a-fA-F]（9a是非法范围）、[\w-]（\w和-之间没空格也不行）
Compilation failed 但 pattern 看不出错？试试临时禁用 JIT
极少数情况，JIT 编译器在解析阶段就崩了（比如 pattern 太长、嵌套太深），会伪装成编译失败。这不是你 pattern 写得不对，而是 PCRE JIT 的兼容性问题。
- 现象：pattern 在 PHP 7.4 下正常，8.2 下报
Compilation failed，且错误 offset 位置飘忽不定 - 验证方法：在 php.ini 里设
pcre.jit=0，重启 PHP，再试一次。如果 OK，就是 JIT 的锅 - 注意：这只是诊断手段，不是长期方案；生产环境关 JIT 前要压测，避免回溯爆炸
- 在字符类里位置不对、\u 被当字面量、定界符在字符串拼接时被意外截断，这些细节在错误信息里只给 offset，不指明语义。php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
