转码任务全部成功，媒体清单也返回了 200，用户仍然反馈“视频总是卡”。问题可能在某个分片、播放器选档、终端解码或网络波动中。要继续排查，首先要把“卡”拆开：是点开后等不到第一帧，播放中反复等待，还是画面连续但明显落后于现场？
本篇使用转码篇生成的三档 HLS，在同一个播放器中观察稳定网络、限速、请求延迟和分片失败。实验由本地服务注入条件，不调用真实 CDN，也不把合成素材的结果包装成生产优化收益。
首帧、卡顿与直播延迟是三种指标
首帧时间回答“用户多久开始看到画面”。起点可以是点击播放，也可以是应用发出加载请求，但同一份报告必须固定。本实验从点击“开始实验”计时，到浏览器报告第一帧提交显示为止；支持时使用 requestVideoFrameCallback，否则以 playing 作为近似，并注明精度差异。
卡顿发生在已经开始播放之后，播放器因缺少可播放数据暂时等待。它既可以按次数计算，也可以按累计时长或受影响会话比例计算。本地示例统计首帧之后的 waiting 到 playing 区间；正式指标还应排除主动暂停、拖动、页面后台等情况，处理异常结束的区间。
直播延迟回答“正在看的画面比采集时刻晚多少”。它需要采集端与播放端可比较的时间依据，或画面内时钟等测量手段。播放器距离清单直播边缘的距离只是其中一部分，无法直接覆盖编码、接入、转码和源站积压。
因此，首帧更快不代表直播延迟更小，卡顿更少也不一定代表追赶更积极。一个播放器可以预存较多数据后开始播放，获得平滑体验，但看到的内容更旧。优化目标需要产品场景决定，不能把三个指标混成一个“性能分数”。
把缓冲理解为时间预算
播放器下载的是字节，消费的是媒体时间。一个四秒分片若用一秒下载完成，就为后续抖动留出更多余量；若持续需要六秒下载，缓冲最终会被耗尽。单个请求偶尔慢不一定卡顿，连续落后于播放进度才更危险。
图中反馈环路的关键是“后续档位”。播放器无法撤销已经播放的内容，切档也需要下载新分片并满足解码边界。因此限速后画质不一定立即下降，卡顿也可能延后出现；观察窗口过短，会把缓存尚未耗尽误判为策略已经解决问题。
缓冲也不是越多越好。直播缓冲增加观看延迟，移动端还要承担内存和下载浪费；用户很快离开时，预下载的内容可能从未播放。反过来，过小的缓冲让轻微网络波动就变成停顿。应按直播、点播和互动需求分别设定策略。
ABR 如何选择清晰度
自适应码率通常结合下载吞吐估计、缓冲长度、档位带宽和解码能力决定后续请求。吞吐可以由下载字节数和耗时推算，但不同播放器对握手、首字节等待、缓存命中及采样平滑的处理不完全相同。讨论算法时，应注明播放器和版本。
如果直接把最近一次高速下载当成长期可用带宽，网络短暂变好就可能触发激进升档；如果降档过慢，又会消耗本就不足的缓冲。常见设计会保留安全余量，并让升降档具有不同条件，以减少来回切换。具体阈值需要结合业务实验，不能从一个演示抄成通用参数。
档位阶梯本身也限制算法。最低档包含音频后的实际需求若高于可用网络，ABR 已经降到最低仍然会卡顿。此时应考虑更低档、音频模式或明确的网络提示。继续调整选档算法无法创造不存在的带宽，也不能让不支持某种编码的设备获得解码能力。
服务端需要提供准确的能力描述，客户端仍要做实际支持检测。硬件解码可用性、分辨率、帧率、编码档次、位深和系统版本都可能影响结果。相关工程边界可继续阅读自适应流媒体中的能力协商。
实验环境与可观察事件
使用 hls.js 1.7.3 和前篇三档 VOD。播放器从最低档开始，展示当前视频高度、选档编号、缓冲秒数、首帧时间及卡顿区间，并记录错误和切档事件。播放器源码、服务端与配置见实验目录说明。
bash generate.sh "$PWD/output"
node server.mjs "$PWD/output"
# 打开 http://127.0.0.1:18890/player.html
# 开发者工具 Network 中启用 Disable cache，再开始情景实验。
禁用缓存是为了让网络注入实际作用于请求。若分片已在浏览器缓存中，第二次点击播放可能根本不经过本地限速逻辑，看起来就像低带宽仍然支持高清。缓存验证应另开一组实验；不能一边复用本地缓存，一边把结果当作冷启动网络测试。
示例把分片响应按固定节奏分批发送，或在发送前增加等待。这是逐请求模型，不是所有连接共用同一条带宽，也没有模拟真实丢包、拥塞控制和移动网络切换。它适合解释因果和验证事件记录，不能代替运营商网络测试。
四个情景分别说明什么
稳定网络：建立对照
先保持默认网络档位，点击开始，确认画面和声音轨道可解码，再观察播放器从 360p 升到更高档。不要只截取画质最好的时刻；同时记录首帧是否出现、缓冲是否增长和整个观察区间是否发生等待。媒体请求成功是对照条件的一部分。
本次初始稳定网络观察窗口约十七秒，播放器由 360p 切到 720p，未记录首帧后的卡顿。这只说明该次本地播放顺利，不能推导所有设备或完整视频都不会卡顿。精确事件和采样记录附在实验结果中。
带宽不足：最低档也可能不够
将情景切到每个分片请求 450 kbps，禁用缓存后重新开始。最低档视频目标码率就有 600 kbps，加上音频和封装后更高，因此下载持续落后于播放是可以解释的。实测播放器保持低档并反复等待，首帧等待也明显增加。
另一次实验从正常播放中途切换到限速，用来观察“带宽骤降”。已有缓冲让影响延后出现；应把切换时刻、随后选档变化和缓冲下降放在同一时间轴里分析，而不是要求按钮按下的一瞬间立刻卡顿。变化发生在新发出的请求上，已在传输的响应保留原条件。
请求延迟：吞吐够用仍要付等待成本
选择分片额外等待 1.8 秒，然后重新开始。响应主体可以很快返回，但首字节等待已经消耗时间预算。与限速相比，这个场景帮助区分“持续传输慢”和“每次请求开始得晚”。源站排队、跨区域回源和连接建立都可能贡献类似等待，但本地实验并不证明线上具体是哪一种。
分片失败：错误恢复不能只看最终成功
选择接下来两次分片返回 503，观察播放器错误事件、重试和恢复。随后成功并不意味着这两次失败没有用户代价；可能已经增加首帧时间或消耗缓冲。报告应保留错误发生及恢复过程，不能只保留最后一次成功请求。
重试还必须有边界。若清单持续引用不存在的分片，重复请求同一个地址不会使内容出现。播放器需要根据错误类型决定重试、重新加载清单、回到可用窗口或结束播放；服务端则要调查是否存在发布顺序、清理策略或权限问题。
CDN 缓存为什么既有帮助也会制造问题
分片通常可以作为不可变对象缓存，多位观众共享内容，降低回源压力；直播清单持续变化，需要更及时的更新或适当的验证策略。若对二者一概使用长缓存，观众可能拿到过期清单；若所有分片都不缓存，又失去分发复用的主要收益。
缓存键和鉴权必须一起设计。把每个用户的随机参数纳入缓存键，可能破坏共享；忽略影响权限或内容版本的参数，又可能造成错误复用。是否先鉴权、哪些参数参与缓存以及回源如何校验，应以具体 CDN 的配置和安全模型为依据。
本地服务器给分片返回短期缓存和 ETag，清单使用 no-store。可以先请求分片得到 ETag，再带 If-None-Match 请求验证 304。这个实验只说明 HTTP 缓存协商，不是 CDN 命中率测试，也没有证明边缘节点或源站缓存已经生效。
源站与边缘排障时，要把状态码、缓存状态、回源耗时、对象版本和地域关联起来。同一个 URL 返回 200 但内容过期，与返回 404 是不同故障；某个地区失败与所有地区失败也应进入不同排查路径。缩短缓存不是所有故障的通用修复，它还可能放大回源。
网络正常时，也要检查解码和时间线
分片按时下载不代表解码器已经产出可显示画面。编码能力不匹配、时间戳间隙、缓冲区追加失败和终端负载过高，都可能让网络面板看起来正常，而视频仍然停顿。应同时观察媒体错误、丢帧信息和画面时间推进，再决定是降低档位、修复封装还是调整播放器。
实验播放器在启动时可能记录跨越小时间间隙的非致命事件。事件名称本身不能证明发生了用户可感知卡顿，需要对照首帧、等待区间和连续播放时间。把所有错误事件都计为失败，会误报；只看最终成功又会漏掉恢复成本。
让播放指标能指导工程动作
建议以播放会话为单位记录环境、输入流版本、协议、播放器版本、首帧、等待区间和错误分类，再按设备、地区与网络分组。服务端通过流和输出版本连接日志；避免把用户标识直接放成监控标签，造成隐私和高基数压力。
统计时保留失败分母。只对成功播放的用户计算平均首帧，会遗漏一直没看到画面的人；只比较平均卡顿，会掩盖少数设备的严重问题。应同时报告成功率、分位数、受影响比例和样本量，并保持两个版本的观察窗口与人群可比。
发现卡顿后，先看是否缺少可播放缓冲，再看分片是否及时到达；及时到达却不能播放，再查解码、时间线和播放器错误。清单本身停止推进时，则回到接入、转码和打包链路。这个顺序让播放器与后端团队使用同一组事实讨论问题。
当媒体、网络和播放器证据能够连起来，优化就不再只是调整几个缓冲参数。下一篇将把这些体验信号纳入流状态和故障恢复，避免系统显示“运行正常”，观众却早已停在旧画面。
可下载完整实验包，按说明在本地复现。