gin.Context.Set() 存弹幕数据会丢数据，因其生命周期仅限单次 HTTP 请求，异步处理时 Context 已被回收；应改用 channel、消息队列或 context.WithValue() 透传必要信息。
为什么用 gin.Context.Set() 存弹幕数据会丢数据
因为 gin.Context 生命周期仅限单次 HTTP 请求，而弹幕上报后常需异步写入 Redis 或转发到 WebSocket 连接池 —— 若在 handler 里用 Set() 存原始数据，等异步 goroutine 真正执行时，Context 已被回收，Get() 返回 nil。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 上报接口（如
POST /api/danmaku）只做校验和快速响应，把结构化数据（user_id、content、video_id、timestamp）直接传给 channel 或消息队列 - 避免在 handler 内启动无缓冲的 goroutine 处理耗时逻辑；用带缓冲的
chan *Danmaku（例如容量 1024）+ 单独消费 goroutine - 若必须透传上下文信息（如 trace ID），改用
context.WithValue()构造新 context 并显式传入 goroutine，而非依赖 gin.Context 的生命周期
WebSocket 连接管理不能只靠 gin-gonic/contrib/sessions
session 库本质是 HTTP cookie + 服务端存储，对长连接无感知。用户刷新页面或网络抖动重连时，旧 WebSocket 连接未关闭，新连接又建立，导致同个 user_id 出现多条在线记录，弹幕重复广播。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用内存 map +
sync.RWMutex维护连接映射：map[string][]*websocket.Conn（key 是video_id），每次新连接加入前先清理该视频下已断开的 conn - 为每个
*websocket.Conn设置SetReadDeadline和SetWriteDeadline（如 30s），并在读/写错误时主动调用conn.Close()并从 map 中删除 - 不要依赖前端发 “logout” 消息来清理连接 —— 客户端不可靠，必须靠心跳或 TCP 断连事件触发清理
time.Now().UnixMilli() 在高并发弹幕场景下不够用
毫秒级时间戳在单机压测时看不出问题，但当每秒上千条弹幕涌入，且需按时间排序显示时，大量弹幕会撞在同一毫秒，导致前端渲染顺序错乱（后到的弹幕排在前面）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用单调递增序列号辅助排序：全局原子变量
atomic.AddInt64(&seq, 1)，拼成ts_ms * 1e6 + seq % 1e6作为逻辑时间戳（保证同一毫秒内严格有序） - 若部署多实例，改用 Redis INCR 做分布式序号，或直接上
github.com/google/uuid的UUIDv7（含时间+随机+序列） - 避免在 WebSocket 广播前对弹幕列表做
sort.Slice—— 排序应由写入时的逻辑时间戳决定，广播只需按 channel 收到顺序发
Redis LPUSH + LTRIM 做弹幕缓存有隐性丢包风险
单纯用 LPUSH danmaku:video_123 "msg" + LRANGE danmaku:video_123 0 99 看似合理，但当 LRANGE 和 LPUSH 之间发生 LRTRIM，可能截断正在读取的中间段，导致新连接拉取历史弹幕时缺帧。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 改用 Redis Streams：
XADD danmaku:video_123 * content "xxx" user_id "u1" timestamp "171..."，天然支持按 ID 范围读取和消费者组 - 若坚持用 list，用
RPOPLPUSH将新弹幕先推到临时 list，再原子性地LPUSH到主 list 并LTRIM，避免读写竞争 - 历史弹幕拉取接口（
GET /api/danmaku/history?video_id=123&since=171...）必须返回游标（next ID），而不是固定长度数组，方便前端分页补全
真正难的不是接住弹幕，而是让每一条都可追溯、不重复、不错序 —— 这三件事在连接波动、进程重启、扩容缩容时都会露出马脚。
