YouTube Music 取流的 Cookie·PoToken·player.js·EJS/HLS 四层缓存与回退

登录态与会话

YouTube Music 的取流涉及多层会话管理：

登录 Cookie：保留有效身份 Cookie，支持轮换
匿名 visitor：为登录用户同时维护匿名 bootstrap 会话
PoToken 会话：与 Cookie 独立维护的播放器令牌

登录态的 Cookie 轮换、会话参数、player.js 和挑战结果会优先复用缓存，减少重复挑战。

player.js 缓存与失效处理

player.js 是 YouTube 取流的关键播放器脚本。应用会缓存 player.js 的解析结果以减少冷启动开销。当缓存的 player.js 版本或签名失效时：

优先尝试刷新 player.js 本体
刷新后仍失败则进入 EJS 回退路径
EJS 也被平台拒绝时进入 HLS 渐进流回退

EJS/HLS 回退

EJS 和 HLS 是 YouTube 取流的两条降级路径：

EJS（Embedded JavaScript）：直接请求播放器的 JavaScript 渲染音频流地址
HLS（HTTP Live Streaming）：请求 m3u8 清单后按分片拉流

应用不会在同一被拒绝的播放候选上反复重试——签名或播放候选被拒后，该候选会被标记失效，直接跳到下一层回退，避免陷入重试循环。

多级回退流程图

YouTube 取流请求
 ├─ Cookie/PoToken 会话 → 播放器签名 → 播放候选
 │   ├─ 候选有效 → 正常播放
 │   └─ 候选失效 → 标记 + 跳 EJS
 ├─ EJS 回退 → EJS 播放候选
 │   ├─ 候选有效 → 正常播放
 │   └─ 候选失效 → 标记 + 跳 HLS
 └─ HLS 回退 → m3u8 分片拉流
     ├─ 成功 → 正常播放
     └─ 失败 → 跳过 / 停止

会话状态恢复

Cookie 轮换、匿名会话切换和挑战结果刷新都有缓存策略，不会每次取流都走完整认证流程。这些优化在频繁播放 YouTube 内容时能显著减少首次取流时间。