重新开始默认屏蔽第三方脚本

17 Apr, 2026

记得很多年前第一次使用 uBlock Origin，我就按官方文档设置了 中等模式，默认屏蔽第三方脚本和第三方框架，就此用了很久。那时还年轻的我，更多是一种网络调优的 nerd 心态：拦掉多余连接，网页加载飞快，看着 uBO 面板上「自安装后已拦截」总数不断飙升，有一种不足为外人道的掌控感。

当时的我显然并没有那么「在意」隐私，很快便感受到了厌烦：大量网站因为脚本无法加载而显示异常，需要二次手动放行才能正常显示。特别是后来我订阅了更全面的聚合规则集——既然拦截规则已经足够精细，又何必多此一举？于是我取消了这两条全局屏蔽。

时过境迁，多年后的今天，我又重新开始思考这个问题。最初是刷到 这篇文章，一周后，又在 Hacker News 上看到 又一个案例。我也好奇地尝试访问这个臃肿页面。在我的多重拦截 ¹ 下，网页没有那么大，加载速度也还算快。可即便如此，面板上逐渐增加的连接和提示的脚本总数依然令人瞩目。

近年来，由于兴趣、工作流的转变，我对外网的访问频率与日俱增，每天花大量时间在浏览器上不断点击、跳转、刷新页面，以至于代理流量都开始吃紧。这促使我对网页拦截有了更多思考。

文字是可见的，图片和视频也是可见的，但 JavaScript 脚本却不可见。很多时候我们只是在一味地阅读，然后离开，这些不可见的脚本却静默地消耗了大量无用的流量和带宽。更进一步说，这也不只是流量问题，而关乎 web 的本质。最初按照设想，网页应该是文件，访问网页相当于下载文件，且用户可以彻底掌控它。可实际上，网页却发展得更像程序，是可以交互的黑箱。

最终，我决定重新默认屏蔽第三方脚本，对最常访问的站点，还会进一步收紧——屏蔽全部第三方，或屏蔽所有脚本二选一，有的网站适合前者，有的网站适合后者。

令我意外的是，默认下网页被破坏的情况比过去少多了。我只花几分钟修复 x.com（放行 twimg.com）、bilibili.com（放行 hdslb.com）等主要网站，就基本完工了。似乎是现代前端技术栈的演进，让核心脚本托管在第三方域名下的做法变少了。

也许 John Gruber 是对的。