uBlock Origin 的志愿开发团队近日表示，将不再持续更新专门针对 Facebook 的广告过滤规则。今后，当 Facebook 通过改版或代码调整绕过现有规则时，uBlock Origin 不会再主动为每一次变化补上新规则。
这不是广告拦截器突然失效，而是一次维护边界的重新划定：面对一个持续观察、快速迭代并主动对抗过滤器的广告平台，开源志愿者很难无限期投入同样的追赶成本。
一场很难结束的猫鼠游戏
传统广告拦截通常依赖几类信号：广告请求访问独立域名、页面元素带有稳定的广告标记、脚本从固定路径加载，或者广告容器具有可预测的结构。过滤器据此编写网络请求规则和页面隐藏规则。
问题在于，平台可以改变这些信号。例如，广告内容可能与普通内容共用请求域名，广告标记可能动态生成，页面结构可以频繁调整，甚至广告和信息流内容可以在服务端混合后再发送给浏览器。这样一来，规则维护就不再是一次性配置，而变成持续的逆向分析工作。
Facebook 的案例尤其典型：广告、推荐内容和普通帖子都可能出现在相似的信息流结构中。拦截规则过于宽泛，会误伤正常内容；规则过于保守，又容易放过新的广告展示方式。对于依靠志愿者维护的项目，这种取舍会直接影响投入产出比。
这项决定意味着什么
对用户而言，结果可能是某些 Facebook 广告重新出现，但并不代表 uBlock Origin 的通用能力被放弃。其他网站的规则、通用隐私保护和网络请求拦截仍然属于不同的维护范围。
对开源项目而言，这个决定也说明过滤规则不是稳定的产品接口。它们依赖网站当前的实现，网站一旦改变 DOM、请求路径、脚本逻辑或内容投放方式，规则就可能失效。
更重要的是，广告拦截与平台对抗之间存在明显的信息不对称：平台拥有完整的代码、日志和发布节奏，而过滤器维护者通常只能观察浏览器端结果。平台每次改变一种实现方式，维护者都需要重新确认哪些请求或元素可以安全拦截。
可以怎样实践：用 uBlock Origin 自定义规则做小范围验证
如果你需要处理某个具体页面问题，可以先使用 uBlock Origin 的“元素选择器”或“记录器”观察页面，再把确认过的规则添加到“我的过滤器”中。下面是一个示例模板，其中的选择器和域名只是演示写法，不能保证适用于 Facebook 当前页面，也不建议直接用宽泛规则批量隐藏信息流内容：
! 仅用于演示 uBlock Origin 过滤器语法
! 网络请求过滤：确认请求确实是广告资源后再使用
||ads.example.test^$domain=example.test
! 元素隐藏：只隐藏明确带有广告标记的容器
example.test##[data-ad-label="sponsored"]
! 如果误伤正常内容，可以用更具体的祖先和属性组合
example.test##article[data-content-type="advertisement"]
操作步骤可以保持在一个可回滚的小范围内：
1. 打开 uBlock Origin 设置页
2. 进入“我的过滤器”
3. 添加一条经过验证的规则
4. 点击“应用更改”
5. 刷新页面，检查广告是否消失以及正常帖子是否仍然可见
6. 出现误伤时删除规则并重新应用
实际使用时，优先选择精确匹配的域名、属性和值。不要一开始就使用类似 example.test##div 这样的宽泛选择器，也不要仅凭元素名称判断它一定是广告。页面中的推荐内容、视频播放器和普通帖子可能复用相同的 HTML 结构。
维护成本才是核心问题
手写规则适合解决个人设备上的局部问题，却不适合替代公共过滤列表。一个规则要进入公共列表，通常需要考虑多个版本、不同语言页面、移动端布局、误伤风险以及后续维护责任。Facebook 这类高频变化的网站会把每一项成本都放大。
因此，停止主动追赶并不等于技术失败，更像是项目把有限的维护资源重新分配给更可持续的目标。用户也需要接受一个现实：广告拦截器不是对所有网站、所有时间点都有效的永久承诺。
给用户和维护者的建议
用户可以保留 uBlock Origin 的通用保护能力，同时把 Facebook 的过滤效果视为“尽力而为”。遇到广告重新出现时，先确认是不是规则失效、页面缓存问题或网站改版，不要盲目叠加大量第三方规则。
维护者则应明确记录规则的适用范围、误伤边界和失效条件。对于无法稳定区分广告与正常内容的网站，停止投入某一组专用规则，可能比持续发布脆弱补丁更诚实，也更有利于长期维护。
这场对抗不会因为一次公告而结束，但它提醒了所有使用内容过滤工具的人：过滤规则是一种随网站实现变化而变化的工程产物。选择规则时要看维护成本，遇到失效时要保留回滚路径，并接受“能拦多少”取决于平台当前实现的事实。