gin 不内置视频流媒体传输能力，仅可作为轻量级控制层或分发入口；真正流媒体需依赖外部工具或自定义响应逻辑，gin 仅负责正确写回字节流并设置 headers。
Gin 本身不内置视频流媒体传输能力，它只是一个 HTTP 路由框架，但可以作为流媒体服务的轻量级控制层或分发入口。真正做流（如 HLS、MP4 分片、RTMP 推流对接）得靠外部工具或自定义响应逻辑，Gin 只负责把字节流正确写回 ResponseWriter 并设置好 headers。
为什么 Gin 不适合直接处理大视频流？
Gin 默认使用标准 http.ResponseWriter，所有响应内容都会经过中间件链和缓冲区。如果直接用 c.Data() 或 c.Stream() 向客户端持续写入视频数据，容易因超时、中间件拦截（比如日志、CORS）、或未关闭连接导致流中断。
- 默认
gin.Default()带有Recovery和Logger中间件，它们会等待整个 handler 执行完才输出日志——对长连接流来说，这等于卡住整个响应生命周期 -
MaxMultipartMemory等配置只影响上传，不影响响应流；但若你误启用了 gzip 中间件，它会尝试压缩整个响应体，导致流式播放失败 - HTTP/1.1 下必须手动设置
Content-Type、Content-Length（或用Transfer-Encoding: chunked），否则播放器无法识别流边界
如何用 Gin 正确返回 MP4 流（支持 Range 请求）？
点播类视频（如用户下载或 HTML5 <video></video> 播放）依赖 HTTP Range 请求实现拖拽和起始位置跳转。Gin 本身不解析 Range，需自己处理 If-Range、Range header 并返回 206 Partial Content。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 不要用
c.File()：它会忽略 Range，直接返回 200 + 全文件，且无法控制 buffer 大小 - 推荐用
http.ServeContent()封装文件读取逻辑，配合io.ReadSeeker实现按需分片返回 - 关键 headers 必须显式设置：
Content-Type: video/mp4、Accept-Ranges: bytes、Cache-Control: public, max-age=31536000 - 示例中常漏掉
http.ServeContent的modtime参数——设为time.Now()会导致浏览器反复请求，应传文件真实ModTime()
用 Gin 对接 FFmpeg 或 MinIO 视频流的常见姿势
生产环境很少让 Gin 直读磁盘视频文件。更常见的是：FFmpeg 实时转码推流到 RTMP 服务器（如 nginx-rtmp），或从 MinIO/OSS 拉取分片后拼装 HLS index.m3u8 + ts 文件。Gin 在这里只做路由代理或鉴权网关。
- 对接 MinIO：用
minio-go的GetObject返回io.Reader，再通过io.Copy(c.Writer, reader)流式转发，但务必禁用所有中间件，并调用c.Status(http.StatusOK)显式设状态码 - 生成 HLS：Gin 可以动态生成
index.m3u8内容（文本响应），但每个.ts文件应由静态文件服务器或 CDN 提供，避免 Gin 成为 I/O 瓶颈 - 鉴权场景下，别在
c.Redirect()后直接返回流——重定向会丢失原始连接上下文；应在同一 handler 内完成 token 校验 + 流转发
真正难的不是写几行 c.Data()，而是控制连接生命周期、适配不同播放器的 HTTP 行为差异、以及在高并发下避免 goroutine 泄漏。很多线上问题都出在没关掉日志中间件，或者忘了设 Conn.Close() 超时——这些细节比语法更重要。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
