M3U8 播放失败排障：从链接到编码的定位流程

排障建议按照固定顺序做：先看链接可访问性，再看跨域和鉴权，最后看编码兼容。顺序错了会浪费大量时间。很多团队一遇到播放失败就先怀疑播放器，结果在前端调了半天才发现是签名过期或 CDN 缓存旧清单。把问题拆成“能否拿到资源”和“拿到后能否解码”两层，定位会更快，也更容易复盘沉淀为团队流程。

步骤 1：确认链接有效

• 直接在浏览器打开 m3u8，至少能返回文本内容。
• 检查分片 URL 是否可访问，避免 m3u8 可用但 ts 全部 403。
• 签名参数有时效，过期后需要重新生成 URL。
• 若是主清单，继续抽查一个子清单，避免只验证了入口地址。

步骤 2：检查 CORS

• 浏览器开发者工具看 Network/Console，是否存在 CORS 报错。
• 服务端至少要允许来源和必要请求头，分片与清单都要放行。
• 如果带 Cookie 或 Authorization，确认预检 OPTIONS 已正确处理。

步骤 3：区分“解码失败”与“网络失败”

• 有声音没画面：常见是编码兼容问题（例如 HEVC）。
• 频繁缓冲：优先怀疑网络波动和分片体积过大。
• 开头能播后面中断：直播源更新异常或 token 过期。
• 不同浏览器表现不一致：重点看编码与容器兼容，而非链路可达性。

步骤 4：需要转码时怎么做

• 优先转到 H.264 + AAC，兼容性最高。
• 先用低分辨率快速验证，再做高质量导出。
• 生产环境建议做任务队列，避免多个 ffmpeg 并发打满 CPU。

步骤 5：日志与监控闭环

• 记录失败时间点、请求 URL、状态码和播放器错误码，便于复现。
• 对 4xx、5xx、超时、重试次数建立监控，看是否在同一时段突增。
• 直播业务建议监控清单更新时间和最新分片生成延迟，提前发现断流风险。
• 把高频故障归类成固定模板，形成团队通用排障清单。

实际案例：排查"播放5秒后中断"问题

某用户反馈直播流能正常播放，但5秒后必定中断。按照排查流程分析：

• 链接检查：m3u8 能正常打开，前几个分片也能下载，排除基础连通性问题。
• 时间规律：每次都在5秒左右中断，怀疑是签名有效期过短或 token 刷新机制问题。
• 抓包分析：发现第6个分片请求返回 403，此时距离首次加载正好5秒。
• 根因定位：CDN 配置的签名有效期为5秒，而播放器缓冲策略需要预加载后续分片，导致预加载时分片已过期。
• 解决方案：将签名有效期延长至60秒，同时在播放器端优化缓冲策略，问题解决。

常见错误代码速查表

• Hls.ErrorTypes.NETWORK_ERROR：网络请求失败，检查链接、CORS、DNS。
• Hls.ErrorTypes.MEDIA_ERROR：媒体解码失败，检查编码格式、码率、容器封装。
• bufferStalledError：缓冲卡顿，检查网络带宽、分片大小、CDN 节点。
• manifestLoadError：清单加载失败，检查 m3u8 地址、签名有效期、服务端状态。
• levelLoadError：子清单加载失败，检查码率切换逻辑、子清单地址。

结论：用固定流程替代经验猜测

M3U8 问题看起来复杂，但只要按"链接可达 -> 跨域鉴权 -> 解码兼容 -> 转码与监控"这条路径排查，绝大多数故障都能在较短时间内定位。对线上系统来说，真正重要的不是某次救火成功，而是把可复用流程沉淀下来，让每个人都能按同一标准快速判断和处理。建议团队建立统一的排障文档，记录每次故障的现象、原因和解决方案，形成知识库持续迭代。