抖音网页已经匹配到屏蔽词，视频却还在播放，问题可能出在“怎么切到下一条”。这次排查发现，旧脚本依赖的切换按钮在当前 Chrome 推荐页中找不到了，模拟方向键也不稳定。最终方案是复用网页自身的上下切换逻辑：Chrome 候选版已经通过连续跳过测试，正式版 0.0.4 使用相同代码；首次加载时偶发超时、其他浏览器兼容性仍需继续验证。

屏蔽词生效了，为什么还会看到视频

我维护的 douyin-web-enhancer 可以按视频文字、BGM 名称和弹幕文字过滤内容。视频和 BGM 命中规则后需要跳到另一条视频，弹幕则只隐藏对应文字。这些操作都在本地完成，不会替用户向平台提交“不感兴趣”。

跳过一条视频，需要完成两个动作：先判断它是否命中屏蔽词，再让网页切换视频。前一步正确，后一步失败，用户仍会看到不想看的内容。

2026-09-21 的故障就发生在第二步。检查时，脚本仍在运行，也能识别当前视频，但找不到旧实现依赖的上一条、下一条按钮。日志中的 next-control-unavailable 表示“切换控件不可用”。

手动按方向键或滚轮仍然可以切换，说明网页本身保留了切换能力，脚本需要换一条调用路径。不过，这次只确认了当前页面没有这些按钮，不能据此认定抖音已经在所有浏览器中统一移除了它们。

手动按键有效，脚本模拟按键却不稳定

最直接的想法是：既然人按向下键能切换，就让脚本模拟一次向下键。

这里有一个区别。人按键盘时，浏览器会处理键盘输入；网页脚本用 dispatchEvent() 创建的只是一个合成事件，两者的行为不保证相同。MDN 的说明也指出，这类合成事件的 isTrusted 为 false。但我们没有找到足够证据证明抖音正是因为这个字段拒绝切换，不能直接把它当作根因。

为了检查模拟按键是否可用，我暂时停用了过滤脚本，用独立测试脚本只发送一次按键，再观察视频是否切换。测试结果并不稳定：

测试方式 结果
视频稳定播放 1 秒后模拟按键 3 次都没有切换
稳定播放 8 秒后模拟按键 3 次都观察到切换
页面已经加载，再进入后续视频后模拟按键 2 次都没有切换

“等 8 秒有效”一度让人怀疑只是网页启动慢。但页面已经加载后，新进入的视频仍然会失败，这个解释无法覆盖全部现象。部分失败样本随后用浏览器方向键成功切换，不过两次操作有时间差，仍然无法确定究竟是什么状态阻止了模拟按键。

还有一次判断需要撤回。最早的测试中，两次视频切换曾被当作模拟按键成功。后来发现，测试没有考虑播放倍速：一条还剩 10 秒的视频，开 2 倍速只需 5 秒就会播完，可能在观察期间自然连播。那两次“画面换了”无法证明是脚本按键造成的。

因此，我没有采用“每条视频先等 8 秒”或不断重发按键的方案。过滤功能需要尽快跳过，而这组实验也没有证明延迟就能保证成功。详细分组和判断修正见按键测试记录及后续视频对照。

改为调用网页自己的切换逻辑

既然抖音网页仍能切换视频，下一步就是找到它自己怎么做这件事。

检查当时网页加载的 JavaScript 后，我找到了上下切换的内部入口。脚本可以请求网页切换，由网页继续处理列表边界、切换动画和播放器状态。这里所说的“原生导航”，就是复用这套网页已有的逻辑。

9 月 29 日的同页观察也确认：在下一条视频已经准备好的情况下，浏览器向下键与脚本自动跳过经过了相同的切换入口。

但找到一个切换函数还不够。网页更新界面后，内存里可能同时保留新旧两套状态，旧状态中也能找到同名函数。直接调用可能无效，或操作错地方。最初的测试就找到过来自旧状态的函数，因此没有调用。

现在，脚本会先确认切换对象属于当前推荐列表，并且对应当前视频。页面在后台、用户正在输入、弹窗打开或列表发生变化时，也会取消尝试。无法确认时就让当前视频继续播放，避免错误跳过。

这种方式依赖抖音内部实现，网页更新后仍可能失效。它没有获得抖音官方的兼容性承诺，检查失败后放行视频的处理也必须保留。原生导航调查记录记录了具体查找和验证过程。

能跳过一条，还要检查连续跳过和返回

单条视频能跳过，只验证了最简单的情况。实际使用时，可能连续两条都命中屏蔽词，也可能从下方往上浏览。

假设四条视频按顺序排列，中间两条需要屏蔽，预期行为是：

向下浏览：A 正常 → B 屏蔽 → C 屏蔽 → D 正常
向上浏览：D 正常 → C 屏蔽 → B 屏蔽 → A 正常

测试时就发现过一个错误：向上浏览时，第一条正确向上跳过，第二条却改成向下跳，回到了刚才的位置。修正后，连续命中的视频会沿用户进入时的方向继续跳过。

直播也带来了另一个问题。脚本原来只会确认普通视频，跳到直播预览时，曾误以为切换失败；从直播返回后，还会沿用上一条视频的处理状态。现在，确认进入直播后会清理上一条视频的状态，返回普通视频时重新判断。直播本身不参与关键词过滤。

这些场景在 Chrome 中分阶段验证：9 月 27 日的候选版完成了同一直播边界的三组上下测试；9 月 28 日的 0.0.12-test 对连续两条命中视频完成了两组上下往返，方向正确，最终停在未被屏蔽的视频上。

这说明所测场景能够正常工作。它还没有覆盖所有直播形式、较长动画或其他浏览器。具体调用和页面观察见验收记录。

为什么偶尔还是要等一下

调用入口正确，也可能暂时切不了：下一条视频还没加入网页的待播列表，或者上一轮切换动画尚未结束。

当前实现每隔 50ms 检查一次这两个条件，分别最多等 2.5 秒。条件满足就立即切换，超过对应上限则放行当前视频；切换动作发出后，还要确认页面是否确实换到了另一条。

例如，下一条在 0.4 秒时准备好了，脚本就可以继续，不会等满 2.5 秒。9 月 29 日的一次首次加载测试中，网页约 2.24 秒才补齐待播列表，脚本随即发起切换。

这些样本解释了部分等待，却不能证明历史超时已消失。如果网页一直没准备好，仍可能漏过一条本该屏蔽的视频。之前也没有抓到“同一未准备好的状态下，手动能切而脚本不能切”的完整对照，所以这部分仍保留为已知限制。

当前版本怎么用，还有哪些限制

正式版 0.0.4 于 2026-09-29 提交并推送。它使用已测试候选版 0.0.12-test 的运行代码，发布时调整了版本信息和说明，并通过 224 项自动化测试。

浏览器测试使用的是候选版，正式版安装后尚未单独复测。因此文章状态保留为“待复核”。这批新增证据主要覆盖 Chrome 推荐页的视频跳过；BGM、弹幕和 Edge 的旧测试不能当作新版本已经重新验收。

安装或更新时：

  1. 打开正式脚本源码，检查版本号为 0.0.4。
  2. 在 Tampermonkey 中新建脚本，或打开已有的“抖音 Web 增强”，完整替换源码并保存。
  3. 停用临时测试脚本和其他自动跳过脚本，刷新抖音推荐页。
  4. 在当前页的脚本菜单中编辑屏蔽词，多个词用 | 分隔。

已安装 0.0.12-test 的用户也需要手动替换，不能依赖自动更新降到 0.0.4。正式版补上了更新检查和下载地址，但自动更新尚未实际验证；相关字段的用途见 Tampermonkey 官方说明。

其他浏览器、跨标签页设置同步、系统声音和逐帧画面输出也还没有完成本版验证。脚本不保证被屏蔽的视频绝对不会出现一帧画面或发出短暂声音，完整范围见发布说明。

再次遇到命中后不跳过时，先保留当前页面和日志，再在同一条视频上试一次方向键。记录浏览器、Tampermonkey 和脚本版本，以及是否首次进入、往哪个方向浏览、是否经过直播。立即刷新可能丢掉失败现场；向项目 Issues反馈前，删去个人词表、账号信息、Cookie 和媒体地址。