PHP 8.2 新增 /n 修饰符，使所有未命名捕获组自动变为非捕获组，仅保留完整匹配结果；命名捕获组不受影响，兼容性考虑未设为默认，需显式启用。
PHP 8.2 新增 /n 修饰符：默认禁用未命名捕获组
PHP 8.2 开始，preg_* 函数支持 /n 修饰符，它会让所有未命名的 () 捕获组自动变为非捕获组 —— 即不存入 $matches 数组，也不参与回溯计算。
这和手动写 (?:...) 效果一致，但作用于整个正则表达式中所有未命名括号，无需逐个改写。
- 没加
/n：/(a)(b)(c)/匹配"abc"→$matches = ["abc", "a", "b", "c"] - 加了
/n：/(a)(b)(c)/n匹配"abc"→$matches = ["abc"]（只有完整匹配） - 命名组不受影响：
/(?<first>a)(?<second>b)/n</second></first>仍会把first和second放进$matches - 如果同时需要部分捕获，建议显式用
(?:...)或命名组，避免依赖/n的全局行为
为什么 /n 不是默认行为？兼容性与性能取舍
/n 是可选修饰符，不是 PHP 8.2 的默认规则。老代码里大量依赖 $matches[1]、$matches[2] 取值，强制变更会直接破坏逻辑。
启用 /n 后的实际收益集中在两方面：
立即学习“PHP免费学习笔记（深入）”；
- 减少内存占用：大文本中多层嵌套括号若不需捕获，
/n能显著降低$matches数组大小 - 提升匹配速度：省去捕获开销和回溯时的状态保存，尤其在贪婪量词+嵌套括号场景下更明显
- 但注意：它不能替代正确设计的正则。比如用
(.*)+/n依然可能因回溯爆炸而卡死
其他 PHP 8.2 正则相关变更：memory_reset_peak_usage 无关但常被混淆
有开发者看到 PHP 8.2 更新日志里提到 memory_reset_peak_usage，误以为它和正则内存控制有关 —— 实际上这个函数和 preg_* 完全无关，它只重置 memory_get_peak_usage() 的返回值，用于基准测试时隔离不同操作的内存峰值。
正则本身的内存使用仍由 PCRE 引擎内部管理，PHP 层面无新接口暴露。若你遇到 PREG_JIT_STACKLIMIT_ERROR 或超时，该函数帮不上忙。
真正要注意的是：PHP 8.2 对 PCRE2 库的绑定更严格，默认启用 JIT 编译，但某些正则（如含大量递归或条件断言）可能触发 JIT 禁用回退，此时性能反而下降 —— 这类问题得靠 preg_last_error() 和 pcresyntax 工具排查，不是加个修饰符能解决的。
升级后第一件事：检查现有正则是否意外依赖未命名捕获
如果你的项目已跑在 PHP 8.2，但没主动加 /n，那一切照旧；但一旦开始尝试用它，必须确认所有读取 $matches[1]、$matches[2] 的地方都已适配 —— 尤其是验证类、路由分发、日志解析等关键路径。
容易被忽略的点：
-
preg_replace_callback的回调函数里，$matches参数同样受/n影响，别假设索引一定存在 - 第三方库（如 Symfony HttpFoundation 的路由组件）若封装了
preg_match，要查清它是否透传修饰符 - CI/CD 流水线里若混用 PHP 8.1 和 8.2 环境，
/n会导致测试失败（PHP 8.1 不识别该修饰符，报PREG_BAD_UTF8_ERROR类似错误）
