必须常驻，但不能裸跑；需配合连接复用、资源隔离、热加载和健康探针，否则上线即雪崩。短剧分发是高并发低延迟长连接流式服务，短生命周期进程会导致fork开销、TLS重建、缓存缺失等问题；须配置超时、复用buffer、热更新元数据，并防范fd耗尽、日志阻塞、ticker泄漏等崩溃点。
Go 语言常驻内存开发短剧分发系统，核心不是“能不能常驻”，而是“要不要常驻”以及“怎么避免常驻带来的副作用”。直接结论：必须常驻，但不能裸跑；需配合连接复用、资源隔离、热加载和健康探针，否则上线即雪崩。
为什么不能用短生命周期进程跑短剧分发
短剧分发本质是高并发、低延迟、长连接的流式服务——用户拖动进度、倍速播放、频繁切片请求，每个 session 都可能持续数分钟甚至更久。若每次 HTTP 请求都启一个新进程（比如用 CGI 或简单 fork），fork() 开销、TLS 握手重建、缓存预热缺失会直接打穿 QPS 上限。
- Go 的
http.Server默认启用 keep-alive，但若进程级重启，连接池、TLS session ticket、内存缓存全丢 - 短剧元数据（如分片索引、DRM 密钥、鉴权 token）加载耗时，每次冷启重复加载浪费 CPU 和 I/O
- 无法做跨请求的限流/熔断（例如单用户 5 分钟内最多 3 路并发播放），状态必须驻留内存或强依赖外部存储
常驻进程下如何安全管理连接与内存
关键不是“让程序不退出”，而是“让连接不卡死、内存不泄漏、goroutine 不失控”。重点在 http.Server 的配置与生命周期钩子。
- 设置
ReadTimeout和WriteTimeout（建议 ≤ 30s），防止慢客户端占满net.Listener文件描述符 - 必须启用
IdleTimeout（如 90s），避免空闲长连接无限堆积；搭配KeepAlivePeriod控制 TCP keepalive 探测间隔 - 所有视频流分发逻辑必须包裹在带超时的
context.WithTimeout()中，禁止无约束select{}或死循环 - 使用
sync.Pool复用视频分片 buffer（如[]byte），避免高频 GC；切忌直接make([]byte, size)分配大块内存
热更新配置与元数据而不重启进程
短剧业务变更频繁：新剧上线、下架、权限调整、CDN 域名切换。硬重启会导致连接中断、播放卡顿、监控断点。必须支持运行时重载。
立即学习“go语言免费学习笔记（深入）”；
- 元数据（如剧集 ID → OSS 路径映射表）用
sync.Map存储，配合文件监听（fsnotify）或 etcd watch 实现自动刷新 - 路由规则（如 /play/{id} → 后端集群）通过
http.ServeMux替换为自定义http.Handler，支持原子替换 - 禁止直接修改全局变量；所有可变配置走结构体 +
atomic.Value，读取时Load().(*Config) - 提供
/healthz?reload=metadata等管理端点，但需加签验证（如 HMAC + 时间戳），防止未授权触发
常驻进程最易被忽略的三个崩溃点
很多团队跑通功能就上线，结果压测一小时后 OOM 或 goroutine 泄漏，问题往往藏在细节里：
-
http.Transport作为客户端（调用鉴权服务、统计上报）时，没设MaxIdleConnsPerHost，导致 DNS 解析失败后不断新建连接，最终 fd 耗尽 - 日志写入用
os.OpenFile但没做 rotate，单个service_registration.log涨到 20GB+，Write变成同步阻塞，拖垮整个 event loop - 用
time.Ticker做定时清理过期缓存，但没在Stop()时Stop()它本身，goroutine 持续泄露，几小时后达数万
常驻不是终点，是运维起点。真正的难点不在启动那一刻，而在它连续跑 7 天后，你还敢不敢 ssh 进去看 pprof/goroutines。
