用 gin.default() 会丢掉 websocket 升级请求，因其默认启用 logger() 和 recovery() 中间件，logger 会提前读取并消耗请求体，破坏 upgrade 握手所需的空请求体与原始请求头，导致浏览器报 err_connection_refused 或服务端静默失败。
为什么用 gin.Default() 会丢掉 WebSocket 升级请求
因为 gin.Default() 默认启用了 Logger() 和 Recovery() 中间件，而 Logger 会在响应写入前读取整个请求体——这对普通 HTTP 没问题，但 WebSocket 握手（Upgrade: websocket）要求请求体为空且不能被提前消费。一旦 Logger 调用 r.Body.Read()，握手头就被破坏，浏览器报 ERR_CONNECTION_REFUSED 或服务端静默失败。
实操建议：
- 用
gin.New()初始化路由，手动注册必需中间件，跳过Logger - WebSocket 路由必须在其他中间件之前注册（尤其避免任何读 body 的中间件）
- 检查请求头：
r.Header.Get("Connection") == "Upgrade"且r.Header.Get("Upgrade") == "websocket"是基本守门条件
如何安全地复用 net/http 的 Upgrader 处理 Gin 路由
Gin 本身不内置 WebSocket 支持，必须桥接标准库的 http.Upgrader。关键不是“能不能用”，而是“怎么避免并发 panic”和“连接生命周期失控”。
实操建议：
- 定义全局单例
upgrader := &websocket.Upgrader{CheckOrigin: func(r *http.Request) bool { return true }}，生产环境务必改写CheckOrigin - 在 Gin handler 里直接调用
upgrader.Upgrade(w, r, nil)，不要试图把*gin.Context转成http.ResponseWriter—— Gin 的c.Writer不满足http.Hijacker接口 - 升级成功后，立刻用
defer conn.Close()，并在 goroutine 中处理读写，防止阻塞 HTTP 复用连接
gin.Context 里取不到真实客户端 IP 怎么办
实时路况 API 对地理位置敏感，但反向代理（Nginx、Cloudflare）会让 c.ClientIP() 返回 127.0.0.1 或代理内网地址。这不是 Gin 的 bug，是 HTTP 协议层转发导致的。
实操建议：
- 信任
X-Real-IP前，先确认 Nginx 配置了proxy_set_header X-Real-IP $remote_addr; - 更稳妥的做法是解析
X-Forwarded-For最左非私有 IP：strings.Split(c.Request.Header.Get("X-Forwarded-For"), ",")[0]，再过滤掉10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 - 如果用 Cloudflare，优先读
Cf-Connecting-Ip头，它比X-Forwarded-For更可信
路况数据高频推送时，conn.WriteMessage() 阻塞怎么办
WebSocket 连接是全双工但非线程安全的：多个 goroutine 并发调用 WriteMessage 会 panic；而单个 goroutine 串行写又容易因网络抖动卡住，拖垮整个服务。
实操建议：
- 为每个连接维护独立的写 channel：
ch := make(chan []byte, 32)，启动一个专属 writer goroutine 消费它 - 发送前做长度检查：
if len(data) > 64*1024 { return }，超长消息直接丢弃，避免缓冲区雪崩 - 设置写超时：
conn.SetWriteDeadline(time.Now().Add(5 * time.Second))，超时后关闭连接，别重试
真正麻烦的从来不是“怎么推”，而是“推不动时怎么优雅降级”——比如把丢弃的消息聚合进下一帧，或切到 SSE 保底。这些细节没出现在框架文档里，但压测时第一个暴雷。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
