Token过期时http.Client不会自动刷新，需绑定连接实例预刷新并分离超时；签名须含connID和timestamp防重放，WebSocket宜在Ping前续期。
长连接中 Token 过期时 http.Client 不会自动重试或刷新
go 的 http.client 本身不感知 token 生命周期，更不会在请求失败后自动触发刷新逻辑。一旦 token 过期（比如返回 401 unauthorized），当前连接上的后续请求会持续失败——尤其在 websocket 或自定义 tcp 长连接场景下，没有 http 重定向或中间件拦截机制，这个问题更隐蔽。
常见错误现象是：连接保持活跃，但业务请求批量返回 401 或签名验证失败，日志里看不到明显异常，误以为是服务端问题。
- 不要依赖
http.Transport的RoundTrip拦截做统一刷新——它无法区分“首次请求”和“重试请求”，容易陷入死循环 - Token 刷新必须与具体连接实例绑定，不能全局共享一个
token变量，否则多连接并发刷新时可能覆盖或错用 - 若使用
net.Conn自建长连接（如 MQTT、自定义二进制协议），签名字段通常嵌在包头，需在每次写包前动态计算，不能缓存签名结果
context.WithTimeout 和刷新超时控制必须分离
Token 刷新本身需要网络请求（调用鉴权服务），而长连接的业务请求又依赖这个 Token。如果把刷新逻辑塞进业务请求的 context 超时里，会导致：一次刷新失败就卡住整个连接，或刷新耗时过长拖垮业务 RT。
正确做法是给刷新操作单独配超时，并允许降级：
- 用独立的
context.WithTimeout(ctx, 3*time.Second)包裹刷新调用，绝不复用业务请求的 context - 刷新失败时，优先返回旧 Token（若未完全过期）或进入退避重试（如指数退避 1s/2s/4s），而非直接断连
- 避免在
Write方法里同步刷新——应提前在后台 goroutine 中预刷新，或在连接空闲时检查有效期
签名计算必须包含连接唯一标识和时间戳防重放
无感刷新不只是换 Token，更要保证签名不被中间人重放。单纯用新 Token 重新 sign 请求体，攻击者仍可截获旧请求包反复发送。
签名字段设计至少要混入两个动态因子：
-
connID：从连接建立时生成的 UUID，或 TLS session ID，确保每条连接签名空间隔离 -
timestamp：毫秒级时间戳，服务端校验窗口建议 ≤ 5 秒，过期即拒收 - 签名原文建议为
connID + timestamp + method + path + body_hash，而非仅对 Token 签名
注意：不要在签名中加入随机 nonce 并维护状态——长连接可能断线重连，服务端无法可靠追踪 nonce 是否已用过。
WebSocket 场景下刷新时机选在 Ping 帧前后最稳妥
WebSocket 协议本身不提供“心跳带认证”的机制，但客户端可控 Ping 时间点。利用这个窗口做 Token 续期，既不影响业务帧流，又能规避并发冲突。
实操建议：
- 在每次发送
Ping前，检查 Token 剩余有效期是否 - 收到服务端
Pong后，再检查刷新是否完成；未完成则跳过本次续期，避免 Ping/Pong 期间签名不一致 - 禁止在
OnMessage回调中触发刷新——该回调可能在任意 goroutine 执行，易引发竞态
复杂点在于：不同连接可能共用同一个 Token 刷新 endpoint，但刷新响应必须严格按 connID 分发，否则 A 连接刷新成功却把新 Token 写给了 B 连接，后者立刻被踢下线。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
