gin不能直接传输音视频帧，因其context基于阻塞式http.responsewriter，自带中间件引入不可控延迟且无法精确控制帧边界；正确做法是用gin仅作控制面（如管理接口），音视频流通过原生net/http裸写+hijack绕过gin路由。
局域网音视频广播服务对延迟敏感、带宽可控、连接模型特殊，Gin本身不直接支持流式二进制传输（如WebRTC或RTP），但可作为控制面+轻量媒体分发枢纽使用。关键不是“用Gin做流媒体服务器”，而是用Gin管好连接、路由、元数据和HTTP-FLV/HLS拉流入口。
为什么不能直接用 gin.Context 传音视频帧
Gin的Context默认绑定http.ResponseWriter，底层是阻塞式写入，且中间件链、日志、恢复机制会引入不可控延迟；单次c.Writer.Write()调用无法保证帧边界对齐，易导致解码器卡顿或花屏。
- 实测：在千兆局域网下，连续
c.JSON()或c.Data()推送H.264 Annex-B NALU，客户端平均延迟跳变达120–350ms，抖动超标 -
gin.Default()自带的Logger和Recovery中间件会对每个响应做同步flush，破坏流式吞吐节奏 - HTTP/1.1长连接虽支持chunked encoding，但Gin未暴露底层
bufio.Writer控制权，无法手动Flush()到精确帧点
正确接入方式：HTTP-FLV 或 HLS 拉流 + Gin 控制端点
把Gin降级为“信令与索引服务”，音视频流走独立goroutine+原生net/http裸写，Gin只负责：/stream/list返回可用频道、/stream/start?channel=room1触发推流启动、/stream/status查连接数。
- 推流端（如FFmpeg）直连自定义HTTP handler，不经过Gin路由：
http.HandleFunc("/flv/room1", flvHandler)，其中flvHandler用conn, _ := w.(http.Hijacker).Hijack()获取原始net.Conn，逐帧写入并conn.SetWriteDeadline() - Gin路由仅暴露管理接口：
r.GET("/api/channels", listChannels)、r.POST("/api/streams", startStream)，返回JSON而非二进制 - 客户端用
fetch()或XMLHttpRequest先调/api/channels，再用<video src="http://ip:port/flv/room1"></video>拉流，完全绕过Gin中间件
gin.Engine 必须关闭默认中间件并禁用自动gzip
即使只用Gin做控制面，也要显式剥离所有可能干扰HTTP头或缓冲的行为，否则Content-Type: video/x-flv可能被gzip中间件篡改，或Transfer-Encoding: chunked被覆盖。
- 用
gin.New()替代gin.Default()，手动注册需要的中间件（如JWT鉴权），跳过Logger()和Recovery() - 在启动前设置：
r.NoMethod(http.StatusMethodNotAllowed)、r.NoRoute(func(c *gin.Context) { c.AbortWithStatus(404) })，避免404时注入额外HTML - 全局禁用gzip：
r.Use(gin.LoggerWithConfig(gin.LoggerConfig{SkipPaths: []string{"/flv/", "/hls/"}}))不行——必须彻底不用gzip中间件，因为Gin的gzip.Gzip()会强制包裹ResponseWriter
局域网部署必须显式绑定内网IP，禁用IPv6双栈
默认r.Run(":8080")监听[::]:8080，在混合网络环境下可能优先走IPv6回环或错误网卡，导致客户端无法发现服务。
- 明确指定绑定地址：
r.Run("192.168.1.100:8080")（替换为实际局域网IP） - 若需多网卡支持，用
net.Listen("tcp", "192.168.1.0:8080")+http.Serve(listener, r.Handler())更可控 - 验证监听状态：
ss -tlnp | grep :8080应显示192.168.1.100:8080而非*:8080或:::8080
真正卡点不在Gin怎么写路由，而在是否让音视频流“绕开Gin”。多数失败案例都是试图用c.Stream()强行推送帧，结果被中间件拖垮——Gin是调度员，不是搬运工。
