4K 连续播放卡顿的根因找到了 —— 不是带宽不够，也不是缓冲区太小，是一段 4K 视频在拍平时把内存烧穿了。
变更
- 4K 连续卡顿的真凶：拍平视频段的代码是平方级的（P11-235）。YouTube 一段 4K 视频在协议里由
500~700 个小块组成（720p 只有 2431 块），而把它们拼成一条连续流的代码是「每拼一块就把已拼好的16 秒降到 1 秒上下**，视频缓冲水位从卡死在 5 秒
部分整段复制一次」——一段 18MB 的 4K 视频因此要分配 5GB 以上（23MB 那段约 8GB），每 5 秒一段
⇒ 每秒约 1GB 的垃圾内存，电视盒子被 GC 追着跑，画面就一顿一顿。改成一次分配 + 逐块拷入后，
真机实测 4K 的「数据到手 → 交给播放器」从 **9
涨到 40 秒级，GC 警告消失。这也解释了为什么只有 4K 出问题：块数随段大小增长，平方项只在
段变大时爆炸，720p/手机上都感知不到。 - 电视端不再「一笔多搬一段」，读块改为池化复用（P11-234）。4K 大段本来就贵，多搬会让 GC 窗口
更长；现在按设备堆位宽自动判断，移动端保持原有行为与 50 秒缓冲不变。 - 修掉「一笔音频请求赔掉整条会话」（P11-232）。此前音频请求会为了多等一个音频段而把唯一的流
押在十几 MB 的视频段上，撞上超时上限后整条会话被丢弃 ⇒ 视频断流、判定卡死、整场重载。现在
「多等一段」只对当前选中的视频轨生效。 - 频道页「最热 / 最早」排序不再报「视频加载失败」，也不再静默降级到「最新」（P11-231、P11-233）。
已知
- 电视端 ≥1440p 的缓冲上限（alpha.14 加的 20 秒）在真机日志里未观察到生效（4K 缓冲仍能涨到 ~39 秒）。
本次已从分配源头解决内存问题，该上限暂留观察，不急于调整。 - 电视端 4K 仍受盒子内存约束（Java 堆约 448MB）：4K 缓冲堆到 40 秒约占百余 MB，属可用范围但不宽裕；
若后续在播放中叠加其他重负载，仍需留意。 - alpha.5~alpha.15 里记的已知项仍未变。