Webman 不是 API 网关替代品，缺乏动态服务发现、协议转换、header/query路由等核心能力；其路由仅匹配 path，正则语法严格为{id(d+)}，不支持可选参数，协议透传需手动实现且无连接池。
Webman 本身不支持协议转换，动态路由也仅限 HTTP 层路径匹配，无法实现网关级的动态服务发现或 gRPC/SSE 透传。 它不是 Kong 或 APISIX 的替代品，强行用它做“API 网关”会很快撞到能力边界和性能墙——尤其当你要处理 JWT 验签、限流计数、header 路由、多版本灰度等真实场景时。
Webman 的动态路由只在 HTTP path 上生效，不读取 header/query/cookie
Webman 路由系统（基于 FastRoute）只解析 $request->path() 和 HTTP 方法，Accept、X-Api-Version、Authorization 这些字段完全不参与匹配。你不能写 Route::get('/api/users', ...)->where('X-Api-Version', 'v2') 这种规则。
- 所有“条件路由”必须手动在中间件或控制器里判断，比如检查
$request->header('X-Api-Version')后再return $this->proxyTo('users-v2.service') - FastRoute 编译后是静态前缀树，加一堆
if判断会把路由逻辑拖进业务层，失去 O(1) 查找优势 - 若需按 header 分流，建议前置用 Nginx 做
map+proxy_pass，把不同 header 映射成不同 path，再交由 Webman 处理
正则参数写错会导致 FastRoute 直接崩溃，不是 404 而是 500
Webman 动态参数正则必须严格写成 {id(d+)} 格式，括号紧贴参数名、不能有空格、不能用 / 或 ) 等未转义字符。一旦出错，启动时抛 FastRoute\BadRouteException，服务根本起不来。
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
- 错误示例：
/user/{id:d+}（Slim 语法）、/user/{id}(d+)（解析器直接报错） - 正确示例：
/order/{id(d{1,20})}/{type([a-z]+)}，长度限制防回溯爆炸 - 末尾斜杠敏感：
/user/{id(d+)}不匹配/user/123/，要显式写成/user/{id(d+)}/?并关闭strict_slashes - 没有可选参数语法：
{id?}不被识别，只能拆成两条路由：/user和/user/{id(d+)}
协议转换只能靠自己拼 HTTP 请求，无连接池、无流式支持
Webman 没有内置 HTTP 客户端连接池，也没有对 gRPC、WebSocket、SSE 的协议适配层。所谓“协议转换”，实际是你在控制器里用 cURL 或 file_get_contents 手动发请求，再手动解析响应体——这对流式接口（如 text/event-stream）极易出错。
立即学习“PHP免费学习笔记（深入）”；
- 每次转发都新建 TCP 连接，高并发下快速耗尽
ulimit -n，出现大量Connection refused或Too many open files - SSE 场景需监听
onMessage拆包，但 Webman 的Response对象不支持 chunked write，容易卡住或截断事件流 - 想复用连接？得自己封装
curl_multi_init或引入guzzlehttp/guzzle并管理其HandlerStack，但这已脱离 Webman 原生路径 - 真正需要协议转换（HTTP ↔ gRPC、REST ↔ Dubbo），应交给专门组件（如
grpc-web网关、Nginxgrpc_pass），Webman 只做最外层的轻量路由分发
Webman 做 API 网关的最大陷阱，是误以为“能转发请求”就等于“具备网关能力”。它缺的不是代码行数，而是设计层面的抽象：服务发现靠写死 IP、熔断靠 try/catch、限流靠 Redis 计数器——这些本该下沉为基础设施的部分，全被推到了 PHP 应用层，CPU 和延迟自然顶不住。真要上生产，先想清楚哪部分必须 Webman 做，哪部分该甩给 Nginx / Envoy / APISIX。
