preg_match中捕获组必须用()包裹，匹配后按左括号顺序存入$matches数组，索引从1开始；普通组如(\d{4})易因新增分组导致索引错位，命名组(?<year>\d{4})可避免此问题并支持$matches['year']访问。
直接说结论：preg_match 中的捕获组必须用圆括号 () 包裹子模式，匹配成功后结果会按左括号顺序存进 $matches 数组，索引从 1 开始；不用命名就靠数字索引访问，但一加新分组就容易错位——所以关键不是“会不会写”，而是“怎么选类型、怎么防坑”。
普通捕获组 (\d+) 怎么写、为什么慎用
最常见写法，比如提取日期中的年份：/(\d{4})-(\d{2})-(\d{2})/。匹配 "2024-04-05" 后，$matches[1] 是 "2024"，$matches[2] 是 "04"，以此类推。
- 嵌套括号也按左括号出现顺序编号，
((a)(b))会产生三个捕获组：外层是[1]，内层a是[2]，b是[3] - 未匹配的组默认返回空字符串（
""），不是null，容易和真实空值混淆 - 如果正则里加了可选部分（比如
(\w+)?），而实际没匹配上，$matches[1]就是""，但你没法区分这是“没匹配”还是“匹配了空字符串” - 性能开销比非捕获组高，纯逻辑分组（比如
(https?|ftp)）别用它，该用(?:https?|ftp)
命名捕获组 (?<year>\d{4})</year> 解决什么问题
当你改正则时，只要新增一个 ()，所有后续数字索引全得手动调——命名组就是为这事生的。写成 /(?<year>\d{4})-(?<month>\d{2})-(?<day>\d{2})/</day></month></year>，就能直接用 $matches['year']，不依赖位置。
- 命名组同时保留数字索引和关联键名，
$matches[1]和$matches['year']都能取到值 - 名称支持字母、数字、下划线，但不能以数字开头，
(?...)是非法的 - 反向引用要用
\k'year'或\k<year></year>，不能写成\1 - 如果正则里混用命名和普通组，命名组仍按左括号顺序占编号，比如
(?<a>\w+)(\d+)</a>中，$matches[1]对应a，$matches[2]对应数字
preg_match 的 $matches 数组到底长什么样
很多人以为 $matches 就是“匹配内容列表”，其实它结构固定：$matches[0] 永远是完整匹配的字符串，之后每个捕获组占一个索引。但这个结构会被 flags 改变。
立即学习“PHP免费学习笔记（深入）”；
- 不加 flag：每个
$matches[i]是字符串，比如"25" - 加
PREG_OFFSET_CAPTURE：每个元素变成数组，$matches[1][0]是字符串，$matches[1][1]是它在原字符串里的字节偏移量 - 加
PREG_UNMATCHED_AS_NULL：没匹配上的组返回null而不是""，对判断更安全，但要记得检查类型 - 如果正则里有可选捕获组（如
(\w+)?）又没加PREG_UNMATCHED_AS_NULL，$matches[1] === ""可能是真匹配了空串，也可能是根本没匹配——这时候只能靠偏移量判断是否真的参与了匹配
非捕获组 (?:\w+) 什么时候必须用
它不进 $matches，也不占编号，只干一件事：改变优先级或分组逻辑。比如匹配 URL 协议但不单独提取：/(?:https?|ftp):\/\/([^\s]+)/，这里 (?:https?|ftp) 确保 http 和 https 被当做一个整体判断，但你不关心协议名，只想要后面那个域名。
- 正则越长，非捕获组省下的内存和 CPU 越明显，尤其在循环中反复调用
preg_match时 - 所有带
?开头的括号都不是普通捕获组：(?:...)、(?i:...)、(?=...)都不捕获 - 别为了“看起来整洁”把所有括号都改成
(?:...)，否则该提取的地方提不出来，白写了 - 嵌套时，
(?:a(b)c)中的(b)仍是捕获组，编号照常，外层(?:...)只是自己不捕获
真正容易被忽略的是：捕获组编号完全由左括号顺序决定，和是否命名、是否嵌套、是否非捕获无关；而 $matches 的结构又受 flags 控制——这两层耦合一旦没理清，$matches[2] 到底是哪个组、为什么有时是字符串有时是数组，就会反复踩坑。
