hyperf/api-gateway不是生产级网关，仅支持显式静态路由，缺乏限流、JWT透传、服务发现、动态超时等核心能力；其本质是路由注册工具而非网关中间件，高并发场景必须绕过它，基于hyperf/http-server、自定义Router、连接池、rate-limit等底层组件重搭。
hyperf/api-gateway 不是高并发 API 网关，它连基础网关能力都不完整。想用 Hyperf 做高并发网关，必须绕过这个组件，从底层重搭。
为什么不能直接用 hyperf/api-gateway？
它本质是路由注册工具，不是网关中间件：
-
GatewayRoute::add()只支持静态、显式路径（如'/api/v1/users'），不支持通配符、正则、路径参数提取 - 没有限流模块，
$timeout默认 5 秒且不可动态调整，协程阻塞风险高 - 不集成服务发现，
$backend必须写死 IP:PORT，无法对接 Nacos/Consul - JWT 透传需手动在中间件里解析并调用
$request->withAttribute()，网关层零封装 - 日志、熔断、指标上报全无，出问题只能看
Connection refused这类裸错
高并发网关该用什么架构？
Hyperf 的真正优势在协程 + Swoole + 组件可替换性，要发挥它，得按以下结构组织：
- 入口：用
hyperf/http-server监听端口，禁用默认路由分发（避免和网关逻辑冲突） - 路由：自定义
RouterInterface实现，支持前缀匹配、Header 路由、权重灰度（例如根据X-Env: staging转发到测试集群） - 转发：用
Hyperf\Guzzle\ClientFactory配连接池（max_connections=100），禁用 DNS 缓存以防服务重启后解析失效 - 鉴权：独立中间件读取
Authorization头，用hyperf/jwt验证，失败直接return $response->withStatus(401) - 限流：接入
hyperf/rate-limit，按client_ip + path组合限流，令牌桶每秒 100 个
GatewayRoute::add() 的坑怎么填？
如果非要沿用它，至少堵住三个致命漏洞：
-
$path必须以/开头，且不能带末尾/——'/v1/users'✅，'v1/users'❌，'/v1/users/'❌ -
$backend只接受 HTTP 协议的直连地址，'https://user-svc'会报错；DNS 名称需确保容器内/etc/hosts或 CoreDNS 可解析 -
$methods务必显式传['GET', 'POST']，否则默认允许所有方法，DELETE /api/v1/*可能被恶意利用 -
$timeout设为3.0（单位秒），大于 5 秒易拖垮协程调度器；超时后不要重试，避免雪崩
生产环境必须加的三件事
没做这三项，别上生产：
- 健康检查：每个
$backend地址启动时 ping 一次，失败立即报错退出，防止网关起来但后端未就绪 - 连接池降级：当连接池耗尽，自动切到短连接模式（
max_connections=1），保基本可用，而非整体不可用 - Header 清洗：删掉
Proxy-、X-Forwarded-类 Header，防止客户端伪造源 IP 或协议
真正的高并发网关不在配置多炫，而在每一处默认值是否可控、每一个错误分支是否可兜底。Hyperf 提供了足够底层的钩子，但 api-gateway 组件把它们全藏起来了。
