不能用gin.default()启动视频流服务，因其默认启用logger（明文记录含token的视频url）、recovery（panic时暴露源码路径）且绑定0.0.0.0:8080（无认证/限速/访问控制地暴露全部视频）；应改用gin.new()配合白名单中间件、显式绑定局域网ip、调优超时与缓冲，并优先使用支持range的c.file()。
为什么不能用 gin.Default() 启动视频流服务
直接跑 gin.Default() 会默认启用 Logger 和 Recovery，这对点播服务是危险的：日志里会明文记录每个 GET /video/xxx.mp4 请求的完整 URL，而 URL 中若含 token 或 session ID（比如 /video/123.mp4?token=abc），就会被写进日志文件；Recovery 在 panic 时返回带源码路径的 HTML 错误页，攻击者可能通过反复触发异常探测服务结构。更关键的是，gin.Default() 默认绑定 0.0.0.0:8080 —— 视频流服务若暴露在局域网全接口上，等于把整个视频目录对所有设备开放，无认证、无限速、无访问控制。
c.File() 和 c.Stream() 的选型依据
服务静态视频文件，优先用 c.File()，它底层调用 http.ServeFile，支持 Range 请求（拖拽、快进）、自动设置 Content-Length 和 Content-Type，浏览器能正确识别 MP4/AVI 等格式并启用原生播放器控件。只有当你需要动态拼接分片、加密封装或实时转码时，才用 c.Stream() 手动控制 io.Reader 输出流 —— 但此时你得自己处理 Range 头解析、状态码（206 Partial Content）、Content-Range 响应头，稍有疏漏就会导致视频卡顿或无法拖动。
-
c.File()要求路径必须是绝对路径，相对路径（如"./videos/abc.mp4"）会 404；建议启动前用filepath.Abs()解析 - MP4 文件需确保已做 “moov atom 提前”（即使用
ffmpeg -i in.mp4 -c copy -movflags +faststart out.mp4处理），否则浏览器首次加载极慢 - 避免在路由中暴露真实文件系统路径，例如不要用
r.GET("/videos/:path", ...)直接拼接./videos/ + path，防止../etc/passwd路径遍历
如何安全地限制局域网访问并禁用公网暴露
视频点播只服务内网设备，必须显式绑定到局域网 IP（如 192.168.1.100）或本地回环，绝不能留空或写 0.0.0.0。同时，Go 的 http.Server 可配合 net/http/pprof 或自定义中间件做来源 IP 白名单：
- 启动时指定地址：
r.Run("192.168.1.100:8080")，而非r.Run(":8080") - 用中间件检查
c.ClientIP()是否在192.168.0.0/16或10.0.0.0/8段内，不在则c.AbortWithStatus(403) - 若部署在 Docker 中，宿主机运行时加
--network=host或显式映射-p 192.168.1.100:8080:8080，避免桥接模式下端口被意外转发
大文件传输下的超时与内存控制
视频文件动辄几百 MB，Go 默认的 HTTP 超时（30 秒）和内存缓冲（http.MaxBytesReader 未设限）会导致连接被粗暴中断或 OOM。必须手动配置 http.Server 实例：
- 关闭读超时（
ReadTimeout设为 0），因视频流是长连接；但设WriteTimeout为 5 分钟，防客户端卡死占连接 - 用
http.TimeoutHandler包裹路由，避免单个请求无限阻塞 - 对
c.File()调用不额外加载文件到内存，但需确保磁盘 I/O 不成为瓶颈 —— 若并发高，考虑用io.CopyBuffer配合 1MB 缓冲区替代默认 32KB
真正容易被忽略的是：视频文件权限。Linux 下若 Go 进程无读取权限，c.File() 会静默返回 404 而非 403，排查时得先 ls -l 确认文件可被运行用户访问。
