前天晚上十一点四十，剧集在第七集末尾静音状态下自动跳到了第八集，播放器却把进度条卡在了 00:03。我把 DevTools 的 Media 面板打开，盯着 canplaythrough 事件计数从 1 跳到 2 只花了 370 毫秒——这件事本身比剧本更吸引我。
10 月 24 日晚在 MacBook Air 上用 Chrome 119.0.6045.199 打开某流媒体站点，第七集播完时页面尝试自动切到第八集，但播放器没有起播。我在控制台看到 NotAllowedError，原因是该站点的 Media Engagement Index 在 0.5 以下。手动点击播放后，下一集才被放行。整个过程里，页面上的倒计时文案写了 3 秒，实际只等了 3 秒零 180 毫秒——这个数字我截了图。
这本书 2019 年由 O'Reilly 出版，作者是 Silvia Pfeiffer。第 4 章第 87 页的脚注写着：“当 src 切换过于频繁时，浏览器可能会忽略 preload 提示。” 我照书里的建议在切集前把 preload 改回 metadata，再改回 auto，观察了两次切换，第二次的 canplaythrough 果然快了约 220 毫秒。这本书有点旧了，但脚注里的观察今天还成立。
周二上午十点半的站会，老周端着保温杯说了一句话，我记在笔记本上：“用户点第一集是意图，自动跳下一集是惯性；惯性可以预测，但不能替用户做决定。” 他说这话时，我们正在看一段 6 秒的录屏：播放器在倒数 5 秒时自动切集，用户刚好在这 5 秒里点了暂停，结果暂停又被新一集覆盖。老周把这种覆盖称为“意图冲突”，并要求把倒计时改成可撤销的 8 秒。
在 W3C 的 Autoplay Policy 草案里，关于“粘性激活”的段落提到：用户与页面发生一次受信任的交互后，后续的自动播放不应被同一策略反复拦截。我对照着查了 Chromium 的 MEI（Media Engagement Index）阈值——默认是 0.5，低于这个值的站点需要显式交互。这个 0.5 不是标准，是 Chromium 的实现选择。我在页面里写 恢复原来的49图库资料免费打开49图库app下载 时，顺便把这段规范出处贴在注释里，提醒自己别把实现细节当成规范。
10 月 25 日下午，我把切集前后的两段视频用 VideoDecoder 逐帧解码，发现第 7 集最后一帧到第 8 集第一帧之间有 3 帧黑场，持续约 100 毫秒。这不是播放器的问题，是转码时 GOP 边界对齐留下的空隙。我把这个发现写进缺陷单，顺手在 imtoken钱包app下载2.0 的调试笔记里贴了同样的截图：黑场帧的 PTS 从 41.933 跳到 42.033，肉眼看不出来，但录屏逐帧看得到了。
《流媒体系统：架构与工程实践》第 6 章第 201 页，作者用了一整页讲“自动下一集”的缓存失效问题：当用户以 1.5 倍速观看时，客户端预取下一集的时机如果按“剩余 60 秒”计算，实际留给预取的绝对时间只有 40 秒。书里给的数字是 40 秒，并建议把预取窗口从固定剩余时长改成按播放速率动态计算。我按这个逻辑改了一版代码，切集的黑场从 3 帧降到 1 帧，但没继续追下去——不是所有问题都值得追到底。
10 月 23 日下午六点十七分，我在北京地铁 10 号线从知春路到西土城这一段，看到对面乘客的手机屏幕上，播放器在集末弹出“即将播放下一集”的浮层，浮层里有一个很小的“取消”按钮。她点了取消，然后锁屏。这个动作只用了两秒，但我注意到她的拇指在屏幕上停顿了一下才点中——按钮的可点击区域太小了。我把这个观察记在手机备忘录里，第 3 条写的是“倒计时 5 秒，取消按钮大约 36×20 像素”。
WHATWG HTML 标准对 autoplay 属性的描述只有一句话：它向浏览器提示可以尽可能早地开始播放，但播放是否发生取决于“用户允许”。问题是，“用户允许”如何被记住、记多久、跨不跨标签页，标准不答。我在工作笔记的同一页把这句话圈了三次，旁边用红笔写了一个问题：“如果用户允许过一次，第二天打开同一站点还要不要重新问？” 这个问题在我脑子里转了三个版本，到今天也没有完全满意的答案。
Jake Archibald 在 2023 年 8 月的一篇关于媒体加载的博文里写道：预加载给用户的是一种“正在准备”的错觉，而真正决定切集顺滑与否的是解码器状态和首帧时间。我重读这篇博文时，顺手用 49图库恢复指南 里的方法做了一个对照测试，把首帧时间从 480 毫秒压到 310 毫秒，但体感差异只有在我自己知道数字的情况下才明显——这大概是所有性能优化里最诚实的部分。
周五下午两点，公司三楼小会议室，白板上画了两条线：一条是用户意图，一条是产品惯性。前端组的阿岚说，自动播放下一集是产品惯性，不是交互，所以不应该继承用户激活状态。另一个人说，如果用户已经在看这一集，下一集是同一个观看行为的延续，应该视为同一个交互上下文。我站在第二个人那边，但没完全说服自己——因为一旦“延续”成立，界限就变得模糊了。这场争论没有结论，白板上的两条线到现在还没擦。
从 9 月 26 日到 10 月 26 日，我站上共记录 1,284 次“下一集”尝试，其中 71 次被浏览器自动播放策略拦截，比例约 5.5%。这 71 次里，有 49 次发生在用户当天第一次访问时，22 次发生在无痕窗口。我把这些数字和观察写进内部文档，同时在本站的 新版4949图库 页脚里放了一条更短的说明。数字本身不惊人，但 5.5% 的拦截率意味着每 20 次切集就有一次需要用户手动点一下，这个摩擦不该被忽略。
我叫江晚，是一个在浏览器媒体管线边上做前端工程的人。过去两年，我的大部分工作时间都花在播放器上：起播时间、切集策略、错误恢复，以及那些在日志里只出现一次、却需要花一整个下午复现的边缘情况。我写这个站，是因为我发现在中文互联网上，关于“浏览器视频自动播放下一集”的讨论要么停留在产品体验层面，要么直接跳到代码片段，中间那段“为什么是这样”的规范与实现之间的地带，很少有人认真写下来。
这个站不追求更新频率，只记录我实际调试过的现场、翻过的书页和与人争论过的会议室。大部分文章都有一个具体的日期、一个具体的人名或一次具体的测量数字，因为我相信具体比正确更有用。我引用规范也引用同事的话，不是为了显得严谨，而是因为这些东西本来就是我工作里真实存在的一部分。
如果你也在做类似的事，或者你恰好发现了我测错的数字，欢迎来信指正。我更愿意把这里当成一本公开的实验笔记，而不是一个“博客”。
“自动播放不是播放器的能力，而是用户和网站之间那份还没被写清楚的协议。”