规则命中顺序要写清楚
七层入口往往同时存在多条转发规则，必须明确命中顺序：常见约定是精确域名优先于通配域名、更长的路径前缀优先于更短路径，同一层级再按规则配置或序号先后。规则一多就容易出现相互覆盖，因此要把规则清单化维护，并在每次变更后回归关键路径。
基本信息
| 域名维度 | 精确匹配优先于通配匹配 |
|---|---|
| 路径维度 | 更长前缀优先于更短前缀 |
| 同层级 | 按规则序号或配置先后决定 |
| 兜底 | 默认服务器组承接未命中的请求 |
| 治理方式 | 规则清单化并加注释，变更后回归关键路径 |
典型使用场景
- 同一域名下按 /v1 与 /v1-beta 分流到不同后端组
- 多租户网关按子域名做通配转发，同时为个别租户配置精确规则
- 灰度发布：把部分路径指向新版本后端，其余走旧版本
- 域名迁移期用兜底组承接未登记路径，避免直接 404
- 排查「请求走错后端」时核对规则命中顺序
匹配示例
| 请求 | 命中规则 | 说明 |
|---|---|---|
| api.example.com/v1/ping | 最长前缀 /v1 | 常规业务请求 |
| api.example.com/v1-beta/x | 最长前缀 /v1-beta | 长前缀优先，不会落到 /v1 |
| x.example.com/ | 通配域名规则 | 无精确匹配时生效 |
| 未登记域名 | 默认服务器组 | 兜底承接 |
规则清单化核对
规则清单化核对
a.example.com / -> group-a
api.example.com /v1 -> group-b
api.example.com /v1-beta -> group-c（更长前缀优先于 /v1）
*.example.com / -> group-default（精确规则优先）规则较多的入口按业务线分组维护并保留变更记录；出现覆盖冲突时，清单比控制台列表更容易比对。
新增规则前先评估它落在哪几条既有规则的前面，长前缀规则插入位置不当会让原路径的请求整体改道。
变更后的回归项
- 逐个域名验证首页与关键接口是否仍走原后端
- 确认新增路径已生效且未影响灰度与预览环境
- 在规则台账里补记本次变更内容与验证结论