关于浏览器网课自动播放下一集的一些记录：从一次卡在 23:47 的旁听说起

9 月 14 日下午三点二十，我坐在朝阳区一家开在二楼的咖啡馆靠窗位置，桌上一台旧 MacBook、一杯已经凉掉的美式、还有一张写满时间戳的便签。那天我做的是最后一轮验证：把脚本装进三个不同的浏览器（Chrome 141、Edge 141、Firefox 143），用同一门《中国法制史》的 12 讲录像跑一遍，看它能否在每一讲结束时准确翻到下一集。便签上记下的第一条是「第 1 讲 结束后 0.8 秒翻页」，第二条是「第 4 讲 结束后 0.3 秒翻页」，到第 9 讲的时候，Edge 上卡住了，日志显示 ended 事件根本没来——那一瞬间我有点想放弃，因为前面八讲都顺，偏偏第九讲像是故意跟我作对。

后来把这一讲的网络请求抓出来看，才发现它用的是一段被切得更碎的 MSE 流，duration 回填得比前几讲晚了大约 1.2 秒，而我的脚本在视频元素刚挂载时就开始监听，等真实 duration 出来时，监听器绑定的那个 video 实例已经被平台换掉了。也就是说，我监听的是一个"死掉"的媒体元素，浏览器当然不会给它派发 ended。这个细节我在 FireFox 上反而没复现，因为它的媒体元素重建策略不一样，同一段代码在三家浏览器里跑出三种结果，这件事本身比脚本能不能跑通更让我在意。

一个明确的判断：自动播放下一集，本质是"监听"而非"点击"

说实话，市面上讲这个话题的文章里，大部分把自动播放讲成了"模拟点击下一集按钮"，我个人认为这个方向是错的，而且错得挺危险。原因有两点：一是按钮的选择器会随平台改版随时失效，二是模拟点击会触发平台的埋点，容易被判定成异常行为。更稳的做法是回到媒体元素本身——监听 ended，或者在 MSE 场景下用 buffered 与 duration 的差值做兜底判断，然后只改 URL 里的集数参数去驱动翻页。这套思路在我 9 月 14 日那轮测试里，十二讲里十一讲都稳定通过，唯一失败的是第九讲，而那次失败恰恰证明了"监听媒体元素"这条路有它的边界，不是万能药。

还有一件必须写下来的事。那天傍晚六点四十，咖啡馆要打烊，我把机器合上准备走，邻桌一个叫陈默的中年男人问我在忙什么，我顺口说了句"在弄网课怎么自动跳到下一集"，他愣了一下，说他女儿去年准备考研，就是每天熬夜守着点"下一集"，有时候一集结束人去倒水，回来发现进度没动，白等四十分钟。他这句话让我把原本打算删掉的那段"失败记录"又留了下来，因为成功的脚本人人会写，失败的那 1.2 秒差值和那次监听器失效，才是后来者真正需要知道的东西。走出咖啡馆的时候天已经黑透了，我没觉得轻松，只觉得像长途跋涉之后，终于可以坐下来把路上的每一块石头都记下来。