正则中|应在分层建模后用于聚合语义等价的维度取值，而非简单枚举；需用括号明确分组、^$锚定，并推荐命名捕获提升可维护性。
正则中的 |（竖线）是“或”逻辑，但它不是简单地匹配多个字符串，而是在**同一层级、同一位置**提供可选分支。在多维业务状态码场景中，直接堆砌 A|B|C|D 往往低效且难以维护——真正有效的做法是**按维度分层建模，再用 | 组织语义等价的取值集合**。
按业务维度拆解状态码结构
多数系统状态码并非随机字符串，而是有隐含结构。例如：
200-01-001（成功-支付域-创建订单）
403-02-005（拒绝-用户域-权限不足）
500-03-999（异常-订单域-未知错误）
可抽象为：HTTP 状态码 + 业务域编码 + 具体错误码，三者间用短横线分隔。
此时不应写成 200\-01\-001|200\-01\-002|403\-02\-005|...，而应先识别维度边界：
- 用
^(\d{3})-(\d{2})-(\d{3})$捕获三段结构 - 再对每段独立定义合法取值范围，用
|组织语义组
用 | 聚合语义等价的状态子集
分支结构的价值在于表达“这一位置上，接受以下任意一种合法含义”。例如：
- 聚合所有“成功类”响应：
(200|201|204) - 聚合“用户相关”业务域：
(01|02|05)（假设 01=登录、02=权限、05=资料） - 聚合“客户端错误”大类：
(400|401|403|404|422)
组合起来就是：^(200|201|204)-(01|02|05)-\d{3}$ → 匹配“用户域的成功操作”^(400|401|403|404|422)-(01|02|05)-\d{3}$ → 匹配“用户域的客户端错误”
避免常见陷阱：优先级与括号作用域
| 的绑定优先级低于连接和分组，不加括号极易误匹配。例如：
- ❌
200|201-01-001实际等价于(200)|(201-01-001)，只匹配纯“200”或完整“201-01-001” - ✅
(200|201)-01-001才表示“200-01-001 或 201-01-001” - ✅ 更安全写法：
^(200|201)-(01|02)-(001|002)$，显式限定每段范围
建议始终用括号包裹每个 | 分支组，并配合 ^ 和 $ 锚定，防止部分匹配。
扩展：结合命名捕获提升可读性与后续处理
当状态码维度变多或需提取语义时，命名捕获让正则更易维护：
^(?P<http>200|201|204)-(?P<domain>01|02|05)-(?P<code>\d{3})$
匹配后可直接通过名称访问：
match.group('http') → '200'
match.group('domain') → '02'
这样既保留 | 的聚合能力，又为业务逻辑提供清晰语义接口。
