不能在网关层维护连接状态，因为TCP/HTTP/2/WebSocket等连接状态属传输层，由网关主动持有会破坏无状态性，导致负载不均、扩缩容失效；正确做法是交由标准库和网络栈管理，仅通过外置存储或透传协议（如traceID）处理请求级上下文。
为什么不能在网关层维护连接状态？
因为连接状态（如 TCP 连接生命周期、HTTP/2 stream ID、WebSocket session）天然属于传输层或协议层，一旦由网关实例主动 hold 住，就会破坏无状态前提。常见错误是：在 http.HandlerFunc 里把 net.Conn 存进全局 map，或用 sync.Map 缓存 upgrade 后的 *websocket.Conn —— 这会导致负载不均、故障扩散、水平扩缩容失效。
真正的无状态不是“不处理连接”，而是“不跨请求保留连接上下文”。Go 网关应把连接管理交给标准库的 http.Server 和底层网络栈，自己只做路由决策与转发控制。
- 所有连接复用必须通过
http.Transport的MaxIdleConnsPerHost和IdleConnTimeout配置驱动，而非业务代码手动管理 - WebSocket 升级后，连接归属权移交至 handler，但该 handler 不应跨 goroutine 共享该连接；若需广播或状态同步，必须走外部消息队列（如 Redis Pub/Sub）或事件总线
- 长连接保活（如 MQTT over WebSocket）的 ping/pong 心跳应由客户端发起，网关仅透传或按协议规范响应，不记录“谁连着”“连了多久”
如何让反向代理真正无状态？
Go 标准库的 httputil.NewSingleHostReverseProxy 默认就是无状态的，但它容易被误用出状态行为。关键陷阱在于：直接复用同一个 *httputil.ReverseProxy 实例时，若上游服务返回 Connection: keep-alive，且你没禁用连接池，http.Transport 会自动复用底层 TCP 连接 —— 这本身没问题，但若你在中间件里修改了 req.Header 或注入了实例相关字段（如 req.Context().Value("instance_id")），就悄悄引入了隐式状态。
正确做法是剥离所有请求级副作用：
- 永远不要在
Director函数中修改req.URL.Host后还复用原req.Header；应显式调用req.Header.Del("Authorization")等敏感头，避免凭据泄露 - 禁用不必要的连接复用：为每个 upstream 配置独立的
http.Transport，并设MaxIdleConns: 0（适用于短命、高并发转发场景） - 若需粘性路由（如灰度流量打到固定实例），必须通过上游服务自身实现（如 Consul 的 tag 路由），而非在网关内存里维护
map[string]string记录 “device_id → instance_ip”
分布式环境下怎么处理“看似需要状态”的场景？
比如限流要按 IP 统计 QPS、熔断器要跟踪下游失败率、日志要关联一次完整调用链 —— 这些都不是连接状态，而是**请求上下文状态**，必须外置存储或通过轻量协议传递。
具体选型取决于 SLA 和延迟容忍度：
- 毫秒级要求（如核心接口限流）：用本地 LRU cache + 布隆过滤器预检，配合定期异步写入 Redis（如
INCRBY ip:192.168.1.100 1+EXPIRE） - 强一致性要求（如支付类熔断）：使用 Redis 的
SETNX+ Lua 脚本做原子计数，避免多实例竞争导致阈值漂移 - 全链路追踪：靠
traceID字段透传（如X-Trace-ID），不依赖网关实例内存；OpenTelemetry SDK 自动注入，无需手写 context 传播逻辑
任何把“统计结果”存在进程内变量（如 var reqCount int64）的做法，在多实例部署下都会失效，且无法做容量预估。
GoFr 和 adaline/gateway 是怎么规避状态陷阱的？
它们的共同设计选择很务实：不封装连接，只封装行为。GoFr 的 gofr.Context 是 request-scoped 的，生命周期严格绑定单次 HTTP 请求；adaline/gateway 的 middleware chain 每次调用都新建 ctx，中间件之间靠 ctx.Value() 传递数据，但这个 ctx 不跨 goroutine、不跨请求、不持久化。
真正危险的是那些“看起来像工具函数”的状态载体：
-
globalRateLimiter *rate.Limiter：单实例可用，多实例就变成 N 个独立桶，完全失去限流意义 -
cache = map[string]interface{}：哪怕加了sync.RWMutex，也是单机锁，扩容后数据不同步 -
atomic.LoadUint64(&counter)：只适合监控指标聚合，不能用于策略决策（如“超过 1000 就拒绝”）
无状态不是技术限制，是架构契约——只要有一个地方偷偷记住了什么，整个网关的弹性、可观测性和运维确定性就塌了一角。
