livego 是最轻量开箱即用的 golang 流媒体服务，支持 rtmp/http-flv/hls，默认启用、端口固定、延迟低、稳定性高；它原生解析 rtmp 帧、共享内存缓冲、无需 ffmpeg 进程，避免崩溃、资源暴涨与黑屏问题。
LiveGo 是目前最轻量、开箱即用的 Golang 流媒体服务，适合快速验证推流逻辑或小规模部署。它不依赖外部数据库或复杂配置，所有协议（RTMP/HTTP-FLV/HLS）默认启用，端口固定、行为可预测——**如果你只需要“推一路流、拉多路播”，直接跑 LiveGo 比自己从零写 WebSocket 或 FFmpeg 调用更稳、延迟更低、出错更少**。
为什么不用自己封装 FFmpeg + net/http 做推流入口？
常见误区是：用 exec.Command("ffmpeg", ...) 接收 RTMP 流再转成 HLS 或 FLV。这看似灵活，实则踩坑密集：
- FFmpeg 进程崩溃后无自动重启机制，推流一断整个服务就哑火
- 每个推流请求起一个 FFmpeg 实例，CPU 和内存随并发线性上涨，4c8g 机器撑不过 5 路 1080p
- FFmpeg 输出的
playlist.m3u8文件需手动轮询更新，客户端常因缓存或未及时 reload 导致黑屏 - 无法原生支持 RTMP 推流鉴权（如校验
publish请求里的app和stream参数），只能靠反向代理前置拦截
LiveGo 内部用 goroutine 直接解析 RTMP 协议帧，不 spawn 外部进程，推流连接与 HTTP-FLV 拉流共享同一份内存帧缓冲区，避免重复解码和拷贝。
如何让 LiveGo 支持简单推流鉴权？
LiveGo 默认不带鉴权，但可通过修改 conf/livego.json 中的 rtmp.publish 配置启用基础 token 校验：
{
"rtmp": {
"publish": {
"auth": true,
"key": "your-secret-key"
}
}
}
此时推流地址需带上签名参数：rtmp://localhost:1935/live/stream?token=abc123，服务端会用 HMAC-SHA256 校验 stream + timestamp + key。注意：
- 时间戳必须在 URL 中显式传入，如
ts=1718474760，且与服务端时间偏差不能超过 300 秒 - 签名字符串格式为
stream:ts:key，例如live/test:1718474760:your-secret-key - 该机制只防误推，不防重放；如需强鉴权，得改
protocol/rtmp/handler.go的handlePublish函数，接入 Redis 或 JWT 校验逻辑
HTTP-FLV 拉流延迟为何比 HLS 低？关键在传输层
LiveGo 的 HTTP-FLV 服务（默认 :7001）本质是长连接 HTTP 流，响应头设为 Content-Type: video/flv 并禁用 chunked encoding，浏览器通过 fetch().body.getReader() 或 flv.js 直接消费二进制帧。而 HLS 必须等待 FFmpeg 切出完整 .ts 片段（通常 2–10 秒）并更新 m3u8，客户端还要额外做 playlist 解析和 segment 下载调度。
- HLS 端到端延迟 ≈ 3 × segment_time（典型 6–30 秒）
- HTTP-FLV 延迟 ≈ 网络 RTT + 编码 GOP 时间（典型 0.8–1.5 秒）
- 若用
flv.js拉流，务必关闭其enableWorker: true，否则 Web Worker 解析 FLV header 会引入额外 200ms 开销
LiveGo 默认不会主动断连重试，而是堆积缓冲区，导致拉流端卡顿加剧。生产环境必须配合 Nginx 做连接保活和超时控制，或改写 protocol/rtmp/conn.go 中的 readMessage 超时逻辑。这点文档几乎不提，但线上故障里八成出在这儿。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
