WebSocket是实时位置推送唯一合理选择，需用gorilla/websocket、校验Origin、绑定userID、用sync.Map存连接、chan广播坐标、定时探活清理超时连接。
用 net/http + WebSocket 做实时位置推送，别碰轮询
HTTP 轮询（比如每秒 GET /location）在真实场景中会迅速压垮服务端，连接数、延迟、电池消耗全超标。WebSocket 是唯一合理选择——它复用单个长连接，客户端发一次坐标，服务端可即时广播给订阅者。
Go 官方库不带 WebSocket 支持，必须用 gorilla/websocket（事实标准）。别用 gobwas/ws 或自行解析帧，稳定性差、文档少、升级易崩。
- 初始化连接时务必校验
Origin头防跨站滥用，尤其涉及用户位置时 - 每个连接需绑定唯一
userID（从 JWT 或 session 解析），不能靠 IP 或连接 ID 区分用户 - 写消息前检查
conn.WriteMessage()返回 error，连接断开时要主动close()并从广播池移除
sync.Map 存在线连接，别用普通 map 加锁
高频位置上报（如车载设备每 500ms 一报）下，用 map[*websocket.Conn]bool 配 sync.RWMutex 会导致锁竞争严重，CPU 毛刺明显。直接上 sync.Map 更轻量，且天然支持并发读写。
但注意：sync.Map 的 Range() 是弱一致性快照，广播时若需确保不漏人，得先用 LoadAll()（v1.21+）或手动遍历 Keys() 后逐个 Load()，避免边遍历边被删导致 panic。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 键建议用
userID string，值存*websocket.Conn和最后上报时间戳int64 - 定时 goroutine 清理超时连接（如 90 秒无新坐标），调
conn.WriteMessage(websocket.PingMessage, nil)探活比单纯看时间戳更可靠 - 不要把整个坐标结构体塞进 map 值里——只存连接和元数据，坐标走广播通道
用 chan struct{ userID string; lat, lng float64 } 做广播中枢
所有位置更新统一写入一个中心 channel，由单独 goroutine 拉取并推送给对应连接。这能解耦上报逻辑与网络 I/O，避免 WriteMessage() 阻塞 handler。
channel 容量设为 1024 足够应对突发（如 100 人同时移动），再大反而增加内存压力；用 select { case ch 丢弃溢出数据，比阻塞更可控——位置本身有天然时效性，旧坐标本就不该强推。
- 广播前对
lat/lng做简单范围校验（如-90 ），防恶意数据污染内存或触发 panic - 若需按地理围栏（geo-fence）推送，别在广播 goroutine 里算距离——提前建
rtreego索引，查完再发；否则每次广播都 O(n) 计算，1000 连接就卡死 - 别在 channel 里传指针或大结构体，
float64和string值拷贝成本低，安全
HTTPS + WSS 强制启用，HTTP 明文传位置等于裸奔
浏览器禁止非 HTTPS 页面建立 wss:// 连接，而 HTTP 上传位置数据会被中间人截获经纬度、时间、设备指纹，风险远超想象。自签名证书在测试环境可用，但生产必须用 Let’s Encrypt 或商业 CA。
Go 服务启动时若只监听 :8080，前端连不上；必须用 http.ListenAndServeTLS()，且证书链完整（fullchain.pem + privkey.pem）。Nginx 反向代理时，也要配 proxy_set_header Upgrade $http_upgrade; 和 proxy_set_header Connection "upgrade";，否则 WebSocket 握手失败，错误是 101 Switching Protocols 不出现。
- WSS 连接 URL 必须以
wss://开头，前端写成ws://在 Chrome 里直接被拦截，控制台只报 vague 的Failed to construct 'WebSocket' - 移动端 WebView（如 iOS WKWebView）对 TLS 版本敏感，禁用 TLS 1.0/1.1；Go 1.19+ 默认已关，老版本需显式设
tls.Config.MinVersion = tls.VersionTLS12 - 位置数据本身建议再 AES 加密一次（密钥由后端下发），不是为了防传输劫持（TLS 已解决），而是防日志误打、数据库泄露后明文暴露
实际最难的从来不是连上 WebSocket 或算个距离，而是怎么让 1000 个连接在弱网手机上不频繁断连、重连时不重复广播、断线期间的位置变化如何合并补偿——这些细节没日志、没监控、没压测根本看不出问题。
