目录
1. 撕开“秒级恢复”的假面：协议选型与缓冲区的生死博弈
为什么 HTTP Live Streaming (HLS) 原生不支持秒级恢复？
核心策略：并不是“恢复”，而是“预加载的欺骗”
1. 抛弃标准的 .ts 切片下载逻辑
2. “幽灵缓冲区”的设计
3. HLS/DASH 的致命缺陷：分片边界对不齐
4. 这里的坑：MP4 Box 结构头
5. 关于“断点续传”的真实例子
2. 暴力介入：重写播放器的心跳与“跳坑”逻辑
浏览器的谎言：waiting 事件的迟钝
核心设计：500ms 频率的“ICU 监护仪”
1. 冻结帧检测 (Frozen Frame Detection)
2. 暴力唤醒：Force Nudge
致命的“微裂缝”：Micro-Gap Skipping
独立音频恢复策略：声音先行
鉴权令牌的过期与“无感刷新”
3. 服务端的降维打击：为“秒级恢复”定制的 FFmpeg 战术
1. 为什么“Open GOP”是断点续传的噩梦？
2. 构建“逃生通道”：定制化的 Baseline 档位
3. 音视频交织 (Interleaving) 的微操
4. 码率控制：VBR vs CBR 的生死抉择
5. 一个被忽视的细节：SPS/PPS In-Band
4. 最后一公里的生死时速：QUIC 0-RTT 与 CDN 边缘的一刀切
1. 为什么 TCP 是移动端恢复的“绊脚石”？
2. 拥塞控制的哲学：抛弃 Cubic，拥抱 BBR
3. CDN 的“Range回源”陷阱与切片缓存
4. 预热与预连接：Pre-connect 的艺术
5. 最后的防线：HTTP/2 Server Push (慎用)
5. 体验层的终极欺骗：心理学防线与混沌工程
1. 别急着转圈：延迟加载指示器 (Delayed Spinner)
2. 降级为“电台模式”：Audio-Only Fallback
3. 预判性缓存与“隧道效应”
4. 混沌工程：如何证明你的系统真的能抗住？
1. 撕开“秒级恢复”的假面：协议选型与缓冲区的生死博弈
很多做音视频开发的兄弟都有个误区，觉得搞定弱网恢复就是调调 retry count 或者改改 HLS 的 manifest 刷新时间。
大错特错。
如果你的KPI是“网络中断后1秒内恢复”，且要求“95%以上的成功率”，常规的开源播放器配置（无论是 hls.js, Dash.js 还是 Exoplayer）默认策略全是垃圾
