调查一下现在网关前端资源的冲突检测

[wklken]

网关在新建资源 API 的时候

• 资源名是唯一的
• method+path 是唯一的【有检查】

但是，存在几种场景能够被录入：

1. 路由匹配问题: 参数名与具体值重复（匹配到哪一个是不确定的）

DELETE /api/v3/set/{bk_biz_id}/batch
DELETE /api/v3/set/{bk_biz_id}/{bk_set_id}

2. 参数名没有泛化, 两条一样的路由可以被录入 （匹配到哪一个是不确定的）

GET /api/v1/config/biz/{bizId}/apps/{appId}/template_revisions
GET /api/v1/config/biz/{bizI_d}/apps/{app_Id}/template_revisions

---

确认下当前的代码逻辑（给到具体链路，逻辑，图）

然后分析下，如果我们要优化这个逻辑，具体方案应该怎么处理？

[robot-wklken]

我按当前 master 代码把“资源冲突检测”链路梳了一遍。结论先说：

1. 现在真正的硬校验在后端，不在前端。
2. 现有硬校验只覆盖“名称冲突”“method+path 字面量完全相同冲突”“ANY 与同 path 其他 method 冲突”“单条 path 自身变量名是否合法/是否重复”。
3. 现有逻辑没有把 {bizId} / {bizI_d} 这种“参数名不同但路由形状相同”的路径当成冲突。
4. 现有逻辑也没有在保存前显式检查“静态段 vs 参数段”的重叠路由，例如 /set/{bk_biz_id}/batch 与 /set/{bk_biz_id}/{bk_set_id}。这类路径会被直接保存并继续发布；从当前仓库代码看，平台侧没有额外的发布前阻断逻辑，最终实际命中会落到下游 APISIX 路由匹配/优先级行为上。

当前链路：

flowchart TD
  A[dashboard-front\nsettings/edit/Index.vue handleSubmit] --> B[createResources / updateResources]
  B --> C[dashboard web API\nResourceListCreateApi.create / ResourceRetrieveUpdateDestroyApi.update]
  C --> D[ResourceInputSLZ]
  D --> D1[UniqueTogetherValidator: gateway+name]
  D --> D2[UniqueTogetherValidator: gateway+method+path]
  D --> D3[LowerDashCaseNameDuplicationValidator]
  D --> D4[PathVarsValidator]
  D --> D5[BackendPathVarsValidator]
  D --> D6[_validate_method: ANY vs same-path other methods]
  D --> D7[_validate_match_subpath]
  D --> E[ResourcesSaver.save]
  E --> F[(core_resource / proxy / context)]
  F --> G[发布阶段 RouteConvertor._convert_uris]
  G --> H[URIRender: {id} -> :id]
  H --> I[APISIX route uris]

Loading

具体代码点：

• 前端新建/编辑提交只是收集表单后直接调接口：src/dashboard-front/src/views/resource-management/settings/edit/Index.vue:219-287、src/dashboard-front/src/services/source/resource.ts:101-108
• 前端本地校验很轻：
  • 基础信息只校验名称必填 + 正则：src/dashboard-front/src/views/resource-management/components/BaseInfo.vue:181-196
  • 请求配置只校验 path 必填 + 正则；method+path 的前端唯一性校验只在 clone 场景里防止“原样复制”：src/dashboard-front/src/views/resource-management/components/FrontConfig.vue:102-146
  • “校验并查看地址”只检查 backend path 变量和环境变量展开，不做资源冲突判断：src/dashboard-front/src/views/resource-management/components/BackConfig.vue:567-603。对应后端接口只是做 backend path/环境变量校验和地址预览：src/dashboard/apigateway/apigateway/apis/web/resource/serializers.py:836-867、src/dashboard/apigateway/apigateway/apis/web/resource/views.py:637-708
• 后端保存时的真正校验在 ResourceInputSLZ：
  • gateway + name 唯一
  • gateway + method + path 唯一
  • lower-dash/camel 同名冲突
  • path 变量名格式、同一路径内重复变量名
  • backend path 变量必须是前端 path 变量子集
  • ANY 与同 path 其他 method 互斥
    见 src/dashboard/apigateway/apigateway/apis/web/resource/serializers.py:307-388 和 src/dashboard/apigateway/apigateway/apis/web/resource/validators.py:31-151
• 发布阶段会把 {param} 渲染成 :param 后下发路由：src/dashboard/apigateway/apigateway/controller/convertor/route.py:130-149,192-212,243-252、src/dashboard/apigateway/apigateway/controller/uri_render.py:39-60

为什么你提的两类场景还能录入：

1. 参数名不同但路由形状相同

   • 现在的唯一性判断是字面量 method + path。
   • 所以：
     • GET /api/v1/config/biz/{bizId}/apps/{appId}/template_revisions
     • GET /api/v1/config/biz/{bizI_d}/apps/{app_Id}/template_revisions
   • 对当前校验来说是两个不同字符串，所以能过。
   • 但发布时二者都会变成“同一类参数位路由形状”（只是参数名不同），系统当前没有在发布前做“路由形状归一化冲突检测”。

2. 静态段与参数段重叠

   • 例如：
     • DELETE /api/v3/set/{bk_biz_id}/batch
     • DELETE /api/v3/set/{bk_biz_id}/{bk_set_id}
   • 当前系统不会在保存时判断“同一个具体请求是否可能同时命中两条路由”。
   • 发布时我也没有看到给普通参数路由单独设置显式 priority；当前 priority 逻辑只用于 match_subpath=true 的场景。
   • 也就是说，平台侧没有把这类重叠关系显式建模并阻断。

补充：导入资源的校验也有同样缺口。
ResourceImportValidator 只校验字面量 method+path、ANY 冲突、名称冲突、match_subpath 等，不做“参数名归一化”或“路由重叠”检测：src/dashboard/apigateway/apigateway/biz/openapi/validate.py:102-215

建议的优化方案：

我建议分两层做，先把“确定有问题的”拦住，再处理“可能有歧义的”。

第一层：硬拦截同形冲突（推荐先做）
目标：解决 {bizId} vs {bizI_d} 这类问题。

做法：

• 新增一套“路由签名归一化”：
  • 静态段保留原值
  • {xxx} 一律归一为同一个占位符，比如 {}
  • match_subpath=true 额外标记尾部通配
• 例如：
  • /config/biz/{bizId}/apps/{appId}/template_revisions
  • /config/biz/{bizI_d}/apps/{app_Id}/template_revisions
    都归一成同一个签名
• 校验维度：
  • 同 method 下签名重复 => 冲突
  • ANY 需要和所有 method 一起比较
• 落点建议：
  • 抽成一个后端公共校验模块，比如 service/resource/route_conflict.py
  • ResourceInputSLZ 和 ResourceImportValidator 共用
  • 前端可以再补一个“实时提示”，但以后端硬校验为准

这个阶段收益最大，改动也最收敛。

第二层：识别重叠/遮挡冲突
目标：解决 /batch vs /{bk_set_id} 这类问题。

做法：

• 按 segment 比较两条路由是否可能匹配到同一个具体 URL：
  • literal vs literal：值不同则不冲突
  • param vs literal：可能冲突
  • param vs param：可能冲突
  • match_subpath / 尾部通配：额外判断前缀覆盖
• 把结果分两类：
  1. same_shape：完全同形，只是参数名不同 —— 直接拦截
  2. shadow_overlap：存在具体 URL 能同时命中两条 —— 建议先告警，评估存量后再升级成拦截

我更推荐先“同形冲突硬拦 + 重叠冲突告警”。
原因很简单：/users/me 和 /users/{id} 这类设计在很多系统里是有意存在的，如果一步到位全部硬拦，容易打到存量设计。

如果你们更强调“平台保证绝不歧义”，那也可以直接把 shadow_overlap 升级成硬拦截，但这会是一个策略决定，不只是技术实现。

落地顺序建议：

1. 先补后端统一路由签名函数
2. 接入 ResourceInputSLZ（新建/编辑）
3. 接入 ResourceImportValidator（导入）
4. 补 4 组测试：
   • 同形参数名冲突：{bizId} vs {bizI_d}
   • 静态段/参数段重叠：/batch vs /{bk_set_id}
   • ANY 与归一化后的 method/path 冲突
   • match_subpath 与普通路由前缀重叠
5. 前端再补“提交前提示”，但不要把前端提示当唯一防线

一句话结论：
当前系统校验的是“字符串是否重复”，不是“路由语义是否冲突”。
所以你提的两类 case 现在都能绕过去。要修，核心不是前端表单加正则，而是后端补“路由语义级”的统一冲突检测。