我用7天把糖心视频的体验拆开：最关键的居然是缓存管理的误区（别说我没提醒）

我用 7 天把糖心视频的体验拆开：最关键的居然是缓存管理的误区（别说我没提醒）

开场白先说一句——把视频体验拆开做实验，跟随感官 “好用/卡顿/加载慢” 之外，常常能看到一些被忽略但决定体验走向的细节。花了 7 天，我把一套糖心视频（流媒体短视频+长视频混合场景）的端到端体验拆成若干维度验证，最后惊讶地发现：最能左右用户感受的，不是码率算法，也不是 CDN（当然 CDN 也重要），而是缓存管理里的几个根本性误区。

下面把过程、发现和可复用的落地建议都写清楚，开发、产品、运维、终端优化都能直接拿去用。

实验概览（我怎么做的）

• 环境：真实设备（Android/iOS/Chrome），受控网络（带宽调节、丢包注入），后端可控的 CDN + origin。
• 指标：启动时间（首帧/首可交互）、首缓冲时间、平均重缓冲次数、播放稳定性（码率切换次数）、缓存命中率、终端存储占用。
• 分析工具：Chrome DevTools、ExoPlayer debug、Charles/mitmproxy、服务端日志 + CDN cache hit ratio。
• 方法：先抓基线数据，再逐步只改缓存相关策略（manifest 缓存、分片缓存、缓存大小、预抓取策略、缓存失效策略等），保证每次变量可控。

七天拆解要点（精简版）

• Day 1 基线：清缓存后测首次体验，启动延迟明显，重缓冲在网络波动时高发。
• Day 2 Manifest 与清单策略：把 m3u8/MPD 误缓存成长时效会造成用户看不到新版内容。
• Day 3 分片缓存策略：默认把所有分辨率分片都预取会浪费带宽与磁盘，且影响真实播放分辨率切换。
• Day 4 磁盘缓存大小与驱逐策略：无限制缓存会把设备存满，导致系统回收缓存或 app 被杀，反而更差。
• Day 5 缓存层次（客户端、浏览器、CDN、origin）：配置冲突导致 manifest 在 CDN 里被“过度缓存”或分片被“不必要重拉”。
• Day 6 认证与缓存：携带短期 token 的 URL 与 cache-control 冲突导致缓存失效或安全隐患。
• Day 7 收敛策略：把缓存策略做成分层、限量、可观测后，整体体验明显好转。

核心发现：常见的缓存误区 1) “缓存越多越好” 预抓取和缓存若不受控，会占满磁盘、浪费流量、甚至让系统回收导致 app 被杀。尤其是在移动端，默认缓存无限制是个陷阱。

2) “Manifest 可以像分片一样长时间缓存” 播放清单需要较短的 cache-control，实时性要保证。分片可以较长时间缓存，manifest 不应长期缓存，否则用户看不到最新内容或清晰度逻辑失效。

3) “不同层（浏览器、service worker、CDN）缓存策略可以乱配” 同样的资源在不同层上有不同生命周期需求，配置不一致会造成缓存命中误判或频繁回源。

4) “预取所有码率没关系” 预取多个清晰度的分片在网络好时看起来“响应快”，但大多数场景下只会浪费带宽和缓存空间，并增加磁盘 IO，影响真实播放质量。

5) “身份授权与缓存能共存不需额外设计” 如果分片 URL 带短期 token，CDN/浏览器可能不会缓存或缓存错误版本。需要采用签名 URL + 合理 Cache-Control 或把鉴权移到 manifest 层。

可落地的解决方案（按角色分）

开发/工程

• 分层缓存策略：
• Manifest（m3u8/MPD）：Cache-Control: max-age=0, must-revalidate 或短时 max-age；CDN 可用更短的 s-maxage。
• 分片：适度长的 max-age + 版本化（文件名/路径带版本号）以便安全更新。
• 客户端缓存策略：
• 限制磁盘缓存总量（例如 200–500 MB，视产品定位调整），采用 LRU 驱逐。
• 对预取实行窗口策略：只预取当前播放位置前后的 N 个分片或时间段；对非当前清晰度则降低优先级或不预取。
• Service Worker / PWA：
• 静态资源用 Cache API，媒体分片用 IndexedDB + Streams 或直接让浏览器缓存，避免把大媒体放进 CacheStorage 导致内存问题。
• 鉴权与缓存：
• 把鉴权限制在 manifest 层（短时 token），分片使用签名 URL + CDN 缓存；或者让 CDN 做鉴权/缓存分离。
• 观测与报警：
• 监控缓存命中率、首缓冲时间、重缓冲次数和客户端磁盘占用；设置阈值告警。

产品/运营

• 把“可缓存时效”作为产品配置项：短视频与直播对 manifest 时效要求不同，产品侧要定义清晰的策略。
• 给用户可控缓存选项：离线下载容量上限、自动清理阈值、仅Wi‑Fi下载等。

测试/运维

• 在不同网络条件下跑回归测试，关注缓存层面指标：
• cache hit ratio（CDN/edge）、客户端缓存命中、回源率、带宽消耗。
• 对灰度发布，确保 manifest 版本化且回滚路径清晰。

用户层可做的简单操作（非技术人员也能用）

• 为节省空间：在 app 设置里限制缓存大小或手动清理（不是每次都清，但当存量接近上限时清理）。
• 遇到“明明更新了内容却看到旧版”这类问题：退出登录/清缓存并重启 app（短期解决），并把问题反馈给产品以便改进 manifest 策略。

简单检查表（上线前跑一遍）

• Manifest 的 Cache-Control 是不是短时或可强制刷新？
• 分片 URL 是否可版本化？是否支持 CDN 缓存？
• 客户端是否限制磁盘缓存并实现驱逐策略？
• 是否有过度预取逻辑？是否为不同分辨率设定预取优先级？
• 鉴权方式是否与缓存策略冲突？
• 是否能监控缓存命中率、回源率、客户端磁盘占用？

结论（不说教，只说事实） 缓存不是单纯越“多”越好，也不是交给 CDN 就万事大吉。合理的分层策略、合适的时效设定和可控的客户端限额，能把“用户看起来流畅”这个主观体验变成可度量的工程成果。把缓存当成一门艺术与学问去对待，会带来意想不到的体验提升。别忘了：在流媒体世界里，策略错位的缓存，比没有缓存更糟糕——这是我 7 天实测里最难忘的一课。