必须用FastAPI+httpx+uvloop构建高并发网关，因Flask同步模型在1000+QPS下受GIL限制，而httpx.AsyncClient配合uvloop可大幅提升I/O密集型代理性能。
直接用 FastAPI + httpx + uvloop，别碰 Flask 做高并发网关——同步模型在 1000+ QPS 场景下会迅速暴露 GIL 瓶颈，不是调参能救的。
为什么必须用异步 HTTP 客户端（httpx）而不是 requests
requests 是同步阻塞的，每个转发请求都会独占一个 worker 线程；而网关本质是 I/O 密集型角色，大量时间花在等待后端响应上。用 httpx.AsyncClient 可让单个 event loop 并发处理数百个代理请求，资源利用率翻倍。
- 错误写法：
requests.request(...)在 FastAPI 路由里调用 → 实际退化为同步代理，吞吐量卡在 300–500 QPS - 正确姿势：用
async with httpx.AsyncClient(timeout=...) as client:，显式控制连接复用和超时 - 注意
httpx默认不复用连接池，需传limits=httpx.Limits(max_connections=100, max_keepalive_connections=20) - 别忽略
follow_redirects=False—— 网关不该自动跳转，否则破坏原始响应状态码
uvicorn 启动参数怎么配才不拖后腿
默认 uvicorn main:app 是单进程单线程，连本机压测都跑不满 CPU。生产必须调参，但不是越多 worker 越好。
- 推荐命令：
uvicorn main:app --workers 4 --loop uvloop --http h11 --timeout-keep-alive 60 -
--workers数建议 = CPU 核心数 × 1.5（例如 8 核配 12），超过后进程调度开销反而上升 -
--loop uvloop必开，比默认 asyncio 事件循环快 30%+，尤其在高连接数下优势明显 - 禁用
--reload（开发用）和--debug（生产环境会吃掉可观 CPU）
路由匹配和路径拼接最容易出错的三个点
看似简单的 /user/123 转发到 http://svc-user/user/123，实际藏着路径重复、斜杠丢失、查询参数丢失三类硬伤。
立即学习“Python免费学习笔记（深入）”；
- 别用
path.startswith(prefix)粗暴匹配 ——/users会被/user错误命中，应改用path == prefix or path.startswith(prefix + "/") - 拼接 target_url 时，如果
SERVICE_ROUTES["/user"]末尾带斜杠（"http://localhost:8001/"），再加"/" + path就变成双斜杠，某些后端服务会 404 -
request.url.query不等于request.query_params：前者是原始字符串（含编码），后者已解码。转发时应直接用str(request.url)或手动构造 URL，避免参数被二次 encode
缓存和限流必须下沉到网关层，不能甩给后端
高频健康检查、配置拉取、用户信息查询这类请求，如果每次穿透到后端，Redis 和数据库压力会指数级上升。网关自己就得扛住。
- 本地缓存用
functools.lru_cache(maxsize=1024)挡住重复的元数据请求（如 /health、/config），但注意它不支持 TTL，只适合不变数据 - 分布式缓存必须走
redis-py的aioredis或redis.asyncio，同步客户端会阻塞 event loop - 限流别手写计数器 —— 用
aioredis+ Lua 脚本实现原子令牌桶，否则多 worker 下计数不准，出现“超限放行”漏洞 - 所有中间件（鉴权、限流、缓存）顺序很重要：先限流 → 再鉴权 → 最后缓存，否则恶意请求可能绕过限流直击缓存逻辑
真正难的不是写转发逻辑，而是让每个请求在毫秒级完成路由决策、安全校验、缓存判断、反向代理、响应组装这一整条链路——任何一个环节没做对，性能就断崖下跌。多数人卡在路径拼接和连接复用上，反复压测看 time_wait 和 connection reset 才意识到问题不在业务代码。
