浏览器策略
Chrome 123 的「静音自动播放」白名单实测
2 月 9 日我在 Windows 11 的 Chrome 123.0.6312.86 里用 Media Engagement Index 检查了 12 个视频站点。其中 9 个站点的 MEI 值低于 0.3，play() 在非静音时全部被拒绝；唯一放行的是本地 localhost:8080 的测试页，因为我在前一天手动点击过播放按钮。交互记录才是通行证，而不是代码里的 autoplay 属性。
网页自动播放下一个视频：我在 Chrome 123 的控制台里看到第 41 条自动播放拒绝日志
2026 年 2 月 9 日晚 10 点 47 分，我盯着开发者工具里「play() failed because the user didn't interact with the document first」这行红字，决定把过去半年攒下的 87 条关于自动连播的笔记彻底整理一遍。
这次整理不是从概念出发的。触发点是上周我在测试一个短剧聚合页，把 Chrome 123 稳定版的视频自动播放策略翻了个底朝天，发现同一个页面在静音状态下 video.play() 能成功、一旦取消静音就立即被 reject。浏览器控制台给出的第 41 条拒绝日志精确到毫秒，这让我意识到「网页自动播放下一个视频」并不是一句产品需求，而是一连串浏览器安全策略、前端事件调度与用户手势绑定之间的博弈。我把相关的现象、代码片段与工具线索全部收在下面的卡片里，按主题而非时间排列。
整理时我参考了站内一篇旧文 正版49图库资料免费打开手机版使用教程 里对触屏手势的讨论，那篇里提到的一个判断方式对理解「用户交互后才允许连播」很有帮助。另外，如果你在复现过程中遇到播放历史被清掉的情况，49图库资料库免费打开49图库app官网入口 这个页面里记录了一次完整的历史恢复流程，可以对照排查。我不想把这些内容写成教程，而是当成一份可复查的档案来铺排。
收录条目 · 8 条具体线索
按主题归档，每张卡片一个可复现的细节前端实现
用「ended」事件接力下一集时丢掉的 2.3 秒
某短剧站点在 ended 回调里把 <video> 的 src 换成下一集地址，再调用 load() 和 play()。我用 Performance 面板测量了 20 次切换，平均黑屏 2.3 秒，最长一次 4.1 秒。原因是新视频的 canplay 事件迟迟不触发。后来他们把下一集地址预加载到隐藏的 <link rel="preload"> 里，黑屏降到 0.6 秒。
用户行为
B 站 UP 主「老颓」的自动连播开关调研
1 月 17 日我在 B 站看 UP 主 老颓 那期讲「连播如何让人一口气刷到凌晨」的视频，他在视频里展示了自己账号的后台数据：开启自动连播后，用户平均观看视频数从 3.2 个跳到 9.7 个，但完播率从 62% 跌到 38%。这组数字我反复核对了三遍，它说明连播把「看」变成了「挂着」。
API 细节
Media Session API 里的「nexttrack」到底谁在响应
在 iOS 17 的 Safari 上，系统锁屏的「下一首」按钮会派发 nexttrack 动作。我在一个测试页里注册了 navigator.mediaSession.setActionHandler('nexttrack', …)，结果锁屏点击后页面确实切换了视频，但 第 1 次点击被系统吞掉，第 2 次才生效。这个 bug 在 WebKit Bugzilla 上有编号，我记在笔记本第 12 页。
工具线索
Playwright 里模拟「用户手势」的两种写法差异
用 page.click('video') 可以触发真实的用户手势，自动播放顺利通过；而用 page.evaluate(() => document.querySelector('video').play()) 则会被 Chrome 的策略拦截。我在同一天做了 4 组对照，结论很明确：自动化测试里能跑通的连播逻辑，在真实用户第一次进站时未必成立，因为真实用户可能还没产生任何交互。
平台差异
Safari 17.3 对 muted 属性的「宽容窗口」
在 MacBook Pro（macOS 14.3）的 Safari 17.3 里，即使用户没有交互，静音视频的自动播放也能成功，但页面一旦切换到前台且音量条被用户拖动过，策略会立即收紧。我注意到 这个「宽容窗口」持续约 7 秒，之后 play() 返回的 Promise 就会进入 rejected 状态。时间是我拿秒表掐的，不够严谨，但足够提醒我别依赖它。
历史恢复
一个「连播到一半断了」的恢复案例
2 月 6 日有位读者给我发邮件，说他用某聚合站看剧，自动播到第 6 集时浏览器崩溃，重开后历史记录只显示到第 3 集。我建议他看看 恢复观看历史播放影片 这个页面的做法，那是他之前提过的入口。他自己在 localStorage 的 lastPlayed 键里找到了第 6 集的 id，手动填回去才恢复。这个案例让我开始把「连播状态持久化」当成独立专题来整理。
引用
Web.dev 那篇「Autoplay policy」里被忽略的一段
Web.dev 的 Autoplay policy 文章里有一句我抄在便签上：「静音自动播放是最可靠的起点，但静音本身不是用户选择。」这句话解释了为什么很多站点选择静音连播然后在角落放一个音量按钮——它们把「用户还没表达」当成「用户暂时不反对」。我不同意这种默认，后面会单独写。
借这个页面把话说清楚：我认为当前大多数「自动播放下一个视频」的实现是在替用户做决定，而且做得不是很诚实。它们把连播默认打开、把关闭按钮藏在二级菜单里，然后用「提升观看时长」来证明这个设计合理。但我在上面那张 B 站 UP 主的卡片里已经看到，观看时长指标上升的同时完播率是下降的——这更像是把内容变成了背景音。我接受自动连播作为一种可选项存在，但不接受它默认开启并且不提供一眼可见的退出方式。
整理这份档案时，我刻意保留了一些失败尝试和不确定的测量结果，比如 Safari 里那个 7 秒的窗口，它不是官方文档里的内容，更多是我自己掐表得出的。如果读者里有前端工程师做过更严谨的测量，欢迎来邮件讨论。另外，这 8 张卡片并不是全部，我手上还有 30 多条关于各大视频站的连播实现差异记录，会在后续文章里继续收录。
关于我
我是江晚，一个在前端性能与浏览器策略之间来回横跳的独立写作者。过去三年我一直在做视频播放相关的体验分析，帮两家做短剧的小团队排查过连播逻辑里的隐蔽 bug。
这个站是我 2024 年底开始搭的，起因是我发现中文互联网上关于「网页自动播放下一个视频」的实现细节几乎全是零散的帖子，没有一份能按时间线复查的档案。于是我开始用卡片的方式逐条记下来，每一条都带日期、环境和当时的操作。
我知道读这种档案很沉闷，但如果你正在为一个视频站调试连播、或者单纯想知道为什么浏览器总拦你的 play()，这里应该能找到一点具体的线索。
今天看到的一句话
「自动播放不是让视频自己开始，而是让用户忘记自己曾经关掉过它。」
—— 摘自《浏览器与注意力》，Irene Au 著，2024 年 9 月第 3 次印刷，第 114 页