HTML无内置弹幕屏蔽功能，需用MutationObserver监听动态插入的弹幕节点并实时过滤关键词，对匹配项调用remove()彻底移除；uBlock等规则因弹幕高频动态性效果极差。
HTML 本身没有“弹幕屏蔽”这个内置功能，所有弹幕都是网站用 JavaScript 动态渲染在视频层之上的 DOM 节点（比如 <div class="danmaku">），屏蔽本质是「阻止特定节点显示」或「提前移除它们」。直接改 HTML 源码无效，因为弹幕内容根本不在初始 HTML 里。
<h3>为什么 document.querySelector('.danmaku') 有时找不到元素</h3>
<p>弹幕是动态插入的：优酷、Bilibili 等平台的弹幕容器通常在视频播放后才创建，甚至按时间轴分批加载。执行 JS 时若太早（比如 DOMContentLoaded 阶段），<code>.danmaku 类可能还不存在。
- ✅ 正确做法：监听
MutationObserver，观察弹幕容器（如#barrageContainer或.barrage-list）的子节点变化 - ❌ 错误做法：只在页面加载完就跑一次
document.querySelectorAll('.danmaku').forEach(el => el.remove())，大概率漏掉后续弹出的弹幕 - 注意：部分平台用
canvas渲染弹幕（如 Bilibili 高性能模式），此时 DOM 中根本没有.danmaku元素，CSS 或 remove() 完全无效
关键词屏蔽：用 MutationObserver + 正则过滤文本内容
真正可靠的关键词屏蔽，必须在弹幕节点插入 DOM 的瞬间检查其 innerText，并决定是否隐藏或丢弃。不能只靠 CSS display: none，否则仍会触发渲染、占内存、甚至被某些平台检测为“异常行为”而限流。
- 监听目标容器（例如
document.getElementById('barrageContainer')） - 对每个新插入的节点，取
node.textContent或node.innerText，用RegExp.test()匹配关键词（如/广告|推广|微信|qq/i） - 匹配成功时，调用
node.remove()（比node.style.display = 'none'更彻底） - ⚠️ 注意：有些弹幕文本藏在子节点（如
<span>xxx</span>），需递归提取纯文本，避免漏判
uBlock Origin 规则能屏蔽弹幕吗？效果很有限
uBlock 的 ## 语法只能屏蔽静态结构的元素，对弹幕这种高频、动态、无固定 class 名的节点基本无效。你写 example.com##.danmaku，可能刚生效一秒，新弹幕就用 .dm-item-12345 这类随机 class 上线了。
立即学习“前端免费学习笔记（深入）”；
- ✅ 可尝试的 uBlock 规则（仅对极少数结构固定的旧版站点有效）：
example.com##div[style*="position:absolute"][style*="white-space:nowrap"] - ❌ 别写
##.js-danmaku—— 现代平台早已弃用稳定 class，且弹幕常嵌套在canvas或transform层中，CSS 选择器根本选不到 - 真实情况：uBlock 对弹幕的拦截率通常低于 20%，它不是为此场景设计的
移动端 WebView 里屏蔽弹幕要额外防「重绘抖动」
在 Android/iOS WebView 中注入屏蔽脚本，容易引发弹幕层频繁增删导致的视觉抖动（尤其是 canvas 弹幕切换为 DOM 模式时）。这不是逻辑错误，而是渲染管线冲突。
- 推荐方案：在弹幕容器上加
will-change: transform，减少重排开销 - 避免每来一条弹幕都调用
remove()，改为批量处理（如每 100ms 收集一次，统一过滤） - 关键细节：WebView 的
userAgent可能被识别为“非标准环境”，部分平台会降级弹幕逻辑（比如强制切回低性能 DOM 模式），这时你的屏蔽规则反而更易生效——但别依赖这点
最麻烦的不是写代码，而是弹幕系统本身就在对抗屏蔽：随机 class、文本拆分、base64 编码关键词、canvas 渲染、服务端动态混淆……真正的关键词屏蔽，永远是猫鼠游戏。写死一个正则或一个选择器，不出两周就失效。
