主线：YouTube 4K 自动升档从「升不上去 / 升上去就掉下来」做到「电视和手机都能自动上屏并稳住」，
另加 B站 动态流补齐与电视端焦点收口。本版整合 v3.1.0-alpha.1 ~ alpha.18，逐版本条目见下方各节。
主线一：4K 自动升档（alpha.5 ~ alpha.18）
- 不再只能手切（alpha.14）：自动升档能升上去了，缓冲比过去厚一倍。
- 不再「升上去就掉下来」（alpha.17）：降档判据重做，缓冲时长成为强制标准 —— 此前有一条
降档通道完全不看缓冲（20 秒窗口的带宽估计一跌破门槛就降，哪怕缓冲 30 秒还在涨，还连带封 90 秒）；
同时 4K 的水位线从 20 秒撤回、与所有档统一 8 秒（它原本与「按往返耗时算的补货线」相撞，
导致 4K 每个补货周期都被判一次「饿」）。 - 电视上也通了（alpha.18）：修掉「声明码率虚高 → 顶档永远进不去 → 更测不到」的死锁 ——
某档还没有实测时，改用同编码族已测出的「实测 / 声明」比例折算它的真实需求（只降权不抬权）。 - 卡顿真凶（alpha.16）：一段 4K 视频在拼装时是平方级内存分配（18MB 的一段要分配 5GB 以上，
每秒约 1GB 垃圾），电视盒子被 GC 追着跑 ⇒ 改为一次分配 + 逐块拷入，交接时间从 9~16 秒降到 1 秒上下。 - 判据按实测校准（alpha.8）：平台给的码率在拿不到媒体元数据时会回落到 VBR 峰值（真机见过
声明 46.49Mbps 而实际内容 7.26Mbps），档位需求改为取min(声明, 实测)。 - 按编码分组（alpha.5 ~ alpha.7）：修掉「清晰度在 4K 与 1440p 之间反复横跳、最后自动重载」，
以及它带进来的「一直停在 1080p、手切 1440p 却没问题」。 - 取流与续播（alpha.12、alpha.13）：大响应边收边用、拿够就停（不再整批收完才用）；
续播 / 切清晰度不再从片子开头重新拉；顺带修掉「起播就被自己降一档还锁 90 秒」。 - 不再看几分钟整场重载一次（alpha.10）：带宽够 ≠ 供得上 —— 加「交付节奏」判据 + seek 后 15 秒宽限。
主线二：B站 动态流（alpha.2 ~ alpha.3）
- 补上图文动态（此前一条都看不到）、看大图 / 进详情 / 看评论；YouTube 关注流不再淹没动态时间线。
主线三：电视端焦点（alpha.1、alpha.4、alpha.9、alpha.11）
- 卡片开始记住自己是谁（列表销毁重建或重排后焦点回到原来那张卡）；UP 页连续下翻不再突然跳回顶部；
从播放列表起播后返回不再丢焦点；「正在看动态却突然被弹回设置页」修掉。
其他
- 频道页：最新 / 最热 / 最早排序真正生效（含按语言本地化的 chip 文案），首屏「4K」胶囊补齐（alpha.15 等）。
- 起播遇到会话被判死不再白等 10 秒，判死后的等待从半分钟压到 17 毫秒（alpha.4、alpha.14）。
- 播放器 UP 面板「关注」在 YouTube 源上不再是死按钮（alpha.15）。
已知
- 声明码率虚高 3~6 倍那种视频（4K 声明 46.49Mbps / 实测 7.26Mbps）在新判据下尚未复测；
已复测的两场 4K 声明本来就准，折算只起了边际作用。 - 「初次折算」目前的实际语义是「本档当前没有实测就借用同族比例」—— 切轨离开某档时它的实测会随
缓存清理失效，下次评估会再次借用；与「只在本档第一次」的字面不同（行为上是有意为之）。 - 一笔主动放弃的请求会砸塌带宽估计（未处理）：缓冲偏低时 fetcher 主动把等待上限压到 8 秒，一次这样
的超时会往 20 秒窗口塞「零字节、8 秒」的样本，把估计从 28Mbps 拽到 14.3Mbps，而同期视频段其实正常入队。 - 顶档独有的差别只剩「冲顶失败后二次升档的坎」：失败后该档封 180 秒、降档后须缓冲 ≥30 秒才许再升、
持续带宽须 ≥ 声明 × 1.1、升档垫子 20 秒。 - 电视端 4K 仍受盒子内存约束（Java 堆约 448MB），叠加其他重负载时仍需留意。
- alpha.1 ~ alpha.18 各节里记的其他已知项不变。