分支结构“|”是控制匹配路径的开关，分隔完整子表达式而非单字符；顺序影响结果，长模式需前置；必须用括号限定作用域，推荐非捕获组(?:...)减少干扰。
分支结构“|”不是简单地表示“或者”，而是控制匹配路径的开关。它让正则引擎在多个完整子模式之间做选择，而不是在单个字符层面切换。用错位置或忽略优先级，很容易导致意外匹配。
分支必须覆盖完整匹配单元
“|”分隔的是**完整的可独立匹配的子表达式**，不是单个字符或零散片段。比如匹配带括号或不带括号的区号，不能写成(0\d{2})|0\d{2}就完事——这样会把括号和数字拆开，导致(010或010)这类半截内容也被接受。
- 正确写法：
(0\d{2})[- ]?\d{8}|0\d{2}[- ]?\d{8}（两个完整电话格式） - 错误写法：
(0\d{2}|0\d{2})[- ]?\d{8}（括号冗余，没解决本质问题） - 更简洁写法：
(\(0\d{2}\)|0\d{2})[- ]?\d{8}（把括号作为可选整体纳入分支）
顺序影响结果，长模式要放前面
正则引擎从左到右尝试分支，一旦某个分支成功匹配，就不再检查后面的分支。如果短模式写在前面，可能“吃掉”本该由长模式处理的内容。
- 比如匹配美国邮编：
\d{5}-\d{4}|\d{5}是对的；反过来写\d{5}|\d{5}-\d{4}会导致12345-6789只匹配前5位12345，后半截被忽略 - 再如匹配文件扩展名：
\.tar\.gz|\.tar|\.gz比\.gz|\.tar|\.tar\.gz更可靠，避免.tar.gz被误判为.gz
用分组明确边界，防止 | 泛滥生效
“|”的默认作用范围是整个正则表达式，不加括号容易扩大影响。想限制它只在局部起作用，必须用(...)包裹。
- 错误：
^abc|def$→ 匹配以abc开头的任意字符串，或以def结尾的任意字符串 - 正确：
^(abc|def)$→ 只匹配abc或def这两个完整字符串 - 进阶：
https?://(www\.)?example\.(com|org)/—— 把域名后缀限定在com或org，其他部分不受|干扰
配合非捕获组减少干扰
纯用于逻辑分支、不需要提取内容时，用(?:...)代替(...)，避免额外捕获组编号混乱，也提升可读性。
- 例如：
(?:jpg|jpeg|png|gif)比(jpg|jpeg|png|gif)更干净，尤其在嵌套或替换场景中 - 在
Replace操作里，如果只关心整体匹配而不提取分组，非捕获组能减少Groups集合里的冗余项 - 调试时，捕获组数量少，更容易定位哪一段实际被匹配了
