gin中直接用gin.context.writer写sse易断连，因未显式flush、未设content-type和cache-control头，且默认中间件（如gzip）会劫持响应体破坏流式特性。
为什么用 gin.Context.Writer 直接写入 SSE 流容易断连
弹幕实时推送依赖服务端事件（SSE），但 Gin 默认的 gin.Context.Writer 在写入时若未显式刷新、未设置正确 Header，浏览器会缓存响应或主动关闭连接。常见现象是：前几条弹幕能收到，之后连接静默中断，net/http 日志里看不到错误，但前端 EventSource 触发 onerror。
关键点在于：Flush() 必须显式调用，且需在每次写入后执行；同时要禁用 Gin 的默认中间件对响应体的劫持（比如 Recovery 或自定义日志中间件若提前读取了 body，会导致流失效）。
- 务必在 handler 开头设置：
c.Header("Content-Type", "text/event-stream")和c.Header("Cache-Control", "no-cache") - 禁用
gzip中间件（Gin 自带的gzip.Gzip()会缓冲输出，破坏流式特性） - 每次写入弹幕数据后，必须调用
c.Writer.Flush()；仅c.Writer.Write()不够 - 避免在 handler 中使用
c.ShouldBindJSON()等会读取 body 的操作——它会阻塞后续流写入
如何安全地在多 goroutine 场景下广播弹幕到所有 SSE 连接
Gin handler 是单次请求生命周期，不能直接持有连接引用。必须把活跃的 *gin.Context 或其底层 http.ResponseWriter 封装为可并发访问的结构，并配合 sync.Map 或通道做广播分发。
典型陷阱是：多个 goroutine 同时调用 c.Writer.Write() 导致 panic（write on closed response），或未加锁导致写入冲突。
- 不要把
*gin.Context存进全局 map——它的生命周期随请求结束而销毁；应提取c.Writer并包装为带 close 标记的结构体 - 推荐用
sync.Map存储连接 ID →chan string，每个连接启一个 goroutine 从该 channel 拉取消息并写入响应流 - 广播时遍历
sync.Map的 value（即各连接的 channel），向每个 channel 发送弹幕 JSON 字符串；channel 长度建议设为 1，防止积压阻塞广播主逻辑 - 客户端断开时，需触发 channel 关闭 + 从
sync.Map中删除键——可通过http.CloseNotify()（已弃用）或更可靠的方式：在写入 loop 中捕获write: broken pipe错误后清理
ffmpeg 提取音视频元信息与弹幕时间轴对齐的关键参数
弹幕需要按播放时间戳精准渲染，但原始音视频文件的时间基（timebase）和 PTS 不一定等于秒级单位。直接用 ffprobe 解析出的 duration 或 start_time 若不换算，会导致弹幕漂移。
最简方案是统一转成毫秒级浮点时间戳，并确保所有弹幕数据携带的是相对于 start_time 的偏移量（而非绝对 PTS）。
- 用
ffprobe -v quiet -show_entries format=duration,start_time -of default=nw=1 input.mp4获取基础时间信息 - 若需逐帧时间戳，用
ffprobe -v quiet -select_streams v -show_entries frame=pts_time,pkt_duration_time -of csv=p=0 input.mp4，注意pkt_duration_time可能为空，此时需 fallback 到平均帧率估算 - Golang 中解析
ffprobe输出建议用encoding/csv而非正则——字段顺序不稳定，CSV 模式更健壮 - 弹幕前端渲染时，务必用
video.currentTime对比弹幕time字段，不要依赖服务端下发的“当前播放秒数”——网络延迟会让这个值不可靠
Redis Pub/Sub 做弹幕中继时为何会出现消息丢失
用 redis.PubSub 在多个 Gin 实例间同步弹幕，看似简单，但默认配置下极易丢消息：订阅者启动慢于发布、重连间隙、或 Subscribe 后未及时 Receive() 导致缓冲区溢出。
Pub/Sub 是纯内存、无持久化的通信模型，不保证投递，也不支持 ACK。生产环境必须搭配 Redis Stream 或 Kafka 才能保序保漏，但简易系统可做有限妥协。
- 避免用
pubsub.Subscribe()后直接ch := pubsub.Channel()——这会丢失连接建立前发布的消息；改用pubsub.ReceiveMessage()循环拉取，配合time.AfterFunc处理超时重连 - 设置
redis.Options.ReadTimeout = 5 * time.Second，防止ReceiveMessage()卡死 - 每个 Gin 实例启动时先
PINGRedis，失败则 panic —— Pub/Sub 连接中断不会自动恢复，必须重启 goroutine - 若弹幕量大（>100 条/秒），考虑用 Redis Stream 替代 Pub/Sub：
XADD+XREADGROUP支持消费者组与未 ACK 消息重试，但需额外维护 consumer group 状态
Gin 的 HTTP 流式响应和 Redis Pub/Sub 都不是“开箱即用就可靠”的组件，真正难的不是写代码，而是识别哪些地方会静默失败——比如 Writer.Flush() 忘了调、sync.Map 里没删掉已断开的连接、或者 ffprobe 解析出的时间戳没除以 timebase。这些点不跑真实流量压测根本发现不了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
