必须常驻，但不能裸跑；需配置readtimeout（≤15s）、writetimeout（≤30s）、idletimeout（如90s），复用连接与sync.pool buffer，元数据通过atomic.value热更新，所有业务逻辑实时load最新配置。
必须常驻，但裸跑等于自毁；高并发短剧播放不是靠堆机器，而是靠连接复用、buffer复用、元数据热加载和精确的超时控制。
为什么不能用 short-lived 进程跑短剧分发
短剧播放是长连接流式服务，用户拖动、倍速、切片请求频繁，单 session 常持续 2–10 分钟。若用 CGI/fork 模式启新进程：
-
fork()开销在万级 QPS 下直接吃满 CPU，尤其 TLS 握手重建成本远高于复用连接 - 每次冷启丢失
http.Server的 keep-alive 连接池、TLS session ticket、sync.Pool缓存 - 剧集元数据（OSS 路径、DRM 密钥、分片索引）需重复加载，I/O 和解析耗时无法摊薄
- 无法做跨请求限流（如“同一 IP 5 分钟最多 3 路并发”），状态必须驻留内存或强依赖 Redis
http.Server 必须调哪些超时参数
默认配置下，慢客户端或网络抖动会快速耗尽 net.Listener 的 fd，导致新连接被拒绝（错误：accept: too many open files）。关键三项必须显式设置：
-
ReadTimeout：建议 ≤ 15s，防恶意大 header 或半开连接 -
WriteTimeout：建议 ≤ 30s，匹配视频分片最大传输窗口（如 10s HLS ts + buffer） -
IdleTimeout：必须设（如 90s），配合KeepAlivePeriod: 30s，避免空闲连接堆积
漏掉 IdleTimeout 是线上最常见 fd 泄漏根源——连接没断但不发数据，http.Server 不会主动 close。
视频流分发里怎么复用 buffer 和 context
高频分配 []byte 是 GC 压力主因，尤其在 720p/1080p 分片场景（单帧常 >100KB）：
- 用
sync.Pool管理固定尺寸 buffer，例如预分配 512KB 池：var videoBufPool = sync.Pool{New: func() interface{} { return make([]byte, 0, 512*1024) }} - 所有流式写入必须包裹
context.WithTimeout(r.Context(), 25*time.Second)，超时后立即 cancel，防止 goroutine 泄漏 - 禁止裸写
io.Copy(w, reader)；改用带超时的io.CopyN(w, reader, size)或分块reader.Read(buf)+ctx.Err()检查
元数据热更新怎么避免 reload 时卡顿
新剧上线、CDN 切换、权限调整不能触发重启——否则正在播放的用户会卡顿 3–5 秒。可靠做法是：
- 元数据结构体用
atomic.Value存储指针，写入时Store(&newConfig)，读取时Load().(*Config) - 监听文件变化用
fsnotify.Watcher，而非轮询；变更后异步加载，成功再原子替换 - 路由层不用全局
http.ServeMux，改用自定义http.Handler实现ServeHTTP，内部持有一个atomic.Value指向当前 handler 实例 - 提供
/healthz?reload=metadata端点，仅用于人工触发，不暴露给前端
最容易被忽略的是：热更新后旧 goroutine 仍可能引用老元数据（比如正在写入的分片路径），所以所有业务逻辑必须从 atomic.Load() 获取最新句柄，不能缓存在局部变量里。
