Beego 不适合直接做音视频流媒体分发接口，因其本质是面向 Web API 的 MVC 框架，缺乏长连接管理、协议解析（RTMP/RTSP）、TS 分片、I帧对齐等流媒体核心能力；它仅可作为流控网关，负责鉴权、生成 token、查状态、启停推流，并通过重定向或返回播放 URL 将实际流分发交由 SRS 等专业服务处理。
Beego 不适合直接做音视频流媒体分发接口。它本质是面向 Web API 和传统 HTTP 服务的 MVC 框架，底层基于 Go net/http，不具备处理长连接、低延迟帧级调度、RTMP/RTSP 协议解析、TS 分片管理或 I 帧对齐等流媒体核心能力。
如果你硬要在 Beego 里“暴露一个流媒体接口”，实际只是返回一个重定向、静态文件路径或 HLS 的 .m3u8 文件——真正的流分发仍需交给专业服务（如 nginx-rtmp-module、SRS、LiveKit 或自研流服务器），Beego 只能做控制面（鉴权、生成 token、查流状态、启停推流）。
Beego 中如何安全对接流媒体服务（如 SRS）
典型做法是让 Beego 作为“流控网关”，不碰音视频数据本身：
- 所有拉流请求先经
Beego的/stream/play接口，校验app、stream、token（如 JWT）和过期时间 - 校验通过后，用
http.Redirect跳转到真实流地址（如http://srs-ip:8080/live/stream1.flv），或返回200+ JSON 包含播放 URL 和有效期 - 推流端调用
/stream/push接口时，Beego记录流元信息（设备 ID、编码参数、ONVIF Profile S 是否启用）、写入 DB，并触发回调通知 SRS 创建 stream group - 务必关闭
Beego的AutoRender和RecoverPanic对流接口的影响，避免中间件拦截二进制响应
为什么不能在 Beego Controller 里读取 RTMP 流并转发
因为：RTMP 是基于 TCP 的私有协议，握手阶段包含 connect、createStream、publish 等 AMF 编码消息，Beego 的 Controller 无法解析这些原始字节流；即使你用 context.ResponseWriter 强行接管连接，也会破坏 net/http 的连接复用机制，导致超时、粘包、goroutine 泄漏。
常见错误现象包括：
- 客户端连上就断，日志报
http: response.WriteHeader on hijacked connection - FLV 头缺失或错位，
ffplay提示Invalid data found when processing input - 并发推流 >50 路时，
Beego进程 CPU 持续 100%，但实际无流发出
Beego 需要配合哪些配置才能支撑流控场景
关键不是功能增强，而是规避默认行为带来的干扰：
- 禁用
SessionOn：流控接口通常无状态，开启 Session 会强制写 cookie，影响 CDN 缓存和跨域拉流 - 调整
MaxMemory：若需接收小段元数据（如 GB28181 的 SIP REGISTER body），需设为 ≥2MB，否则ParseForm直接 panic - 路由显式声明
:splat：例如/:app/:stream/*splat，避免路径中含点号（.flv）被 Beego 自动截断 - 静态文件服务绕过 Beego：HLS 的
.ts和.m3u8应由 Nginx 直接alias到 SRS 的 hls 目录，不要走 Beego 的StaticDir
rtsp://ip:554/Streaming/Channels/101?transportmode=unicast&profile=Profile_1，而 GB28181 设备用的是 SIP URI 格式，Beego 控制器必须按设备类型动态拼接，且不能暴露内部拓扑。这个映射关系一旦写死，后续接入新协议（如 SVAC）就会卡住。 
