能，LiveGo用纯Go解析RTMP帧并共享内存缓冲区，支持RTMP/HTTP-FLV/HLS三协议，默认端口固定、无需外部依赖，实测4c8g机器可稳撑20+路1080p流。
直接跑 LiveGo 就能撑住小规模推拉流，别急着自己封装 FFmpeg + HTTP 服务——90% 的崩溃、延迟高、黑屏问题都来自进程管理失控和缓冲区重复拷贝。
LiveGo 能否替代自研 RTMP 入口？
能，而且更稳。它不是“另一个 FFmpeg 封装”，而是用纯 Go 解析 RTMP 协议帧，所有推流连接共享同一块内存缓冲区，HTTP-FLV 和 HLS 拉流直接读帧，不触发额外解码。
- RTMP 推流连接断开后自动清理 goroutine，无残留进程
- 1080p 流在 4c8g 机器上可稳定支撑 20+ 路并发（实测数据，非理论值）
- 默认启用 RTMP/HTTP-FLV/HLS 三协议，端口固定（1935/7001/8080），行为可预测
- 不依赖外部数据库或配置中心，conf/livego.json 改完 reload 即生效
如何给 LiveGo 加推流鉴权？
改 conf/livego.json 里的 rtmp.publish.auth 和 rtmp.publish.key，签名必须带时间戳且偏差 ≤ 300 秒，否则拒绝接入。
- 推流地址格式：
rtmp://localhost:1935/live/stream?token=abc123&ts=1718474760 - 服务端用
HMAC-SHA256校验字符串：stream:ts:key（如live/test:1718474760:your-secret-key） - 该机制只防误推，不防重放；如需防重放，得改
protocol/rtmp/handler.go中的handlePublish，接入 Redis 记录已用ts或 JWT 校验
HTTP-FLV 延迟为何比 HLS 低？
关键不在编码，而在传输层设计：HTTP-FLV 是长连接流式响应，而 HLS 必须等完整 .ts 切片写入磁盘并更新 playlist.m3u8 后客户端才能加载。
立即学习“go语言免费学习笔记（深入）”；
- LiveGo 的 HTTP-FLV 默认走
:7001，响应头设Content-Type: video/flv，禁用 chunked encoding - flv.js 可直接消费二进制帧，端到端延迟通常控制在 1–2 秒内（局域网实测）
- HLS 默认切片时长 4 秒，加上客户端缓存和 m3u8 reload 延迟，实际播放延迟常达 8–15 秒
- 若强行缩短 HLS 切片（如设为 1 秒），会显著增加 I/O 和 HTTP 请求压力，
m3u8频繁变更还易导致客户端解析失败
真正卡点不在框架选型，而在缓冲区生命周期管理和鉴权与业务逻辑的耦合程度——LiveGo 把协议解析和帧共享做在底层，但 token 校验、流名路由、权限映射这些，还得你亲手接进 handler 或前置网关里。
