Service Worker 仅能拦截同源页面主动发起的第三方广告请求，无法劫持其他网站的请求；需满足HTTPS、正确注册及作用域覆盖等条件，对iframe内广告无效，推荐结合CSP或浏览器扩展实现可靠屏蔽。
Service Worker 本身无法直接拦截第三方广告域名的请求，除非这些请求发生在当前站点的上下文中（即由你的页面主动发起），且满足跨域策略和注册条件。这是由浏览器安全机制决定的——你无法通过自己注册的 Service Worker 去劫持其他网站（如 ads.example.com）的页面所发出的请求。
前提：只有“同源”或“受控页面”才可被拦截
Service Worker 只能控制它被注册的 origin 下的页面（例如 https://your-site.com）。如果用户访问的是 https://news-site.com，而该站注册了自己的 SW，那你部署在 your-site.com 的 SW 完全不会运行，更无法干预其广告请求。
所以真正可行的场景是：
- 你在自己的网站（
your-site.com）中嵌入了广告脚本（如 Google AdSense、腾讯广点通等）； - 这些广告资源（图片、JS、iframe）由你的页面主动加载（例如
<script src="https://ad-cdn.net/ads.js"></script>）； - 你的 Service Worker 已正确注册并激活，且作用域覆盖当前页面。
拦截方式：在 fetch 事件中匹配并阻断
在 Service Worker 的 fetch 事件监听器中，检查请求 URL 的 hostname 或 path，对匹配的第三方广告域名返回空响应（如 new Response("", { status: 200 })）或直接 return Promise.reject()（会触发网络错误）。
示例代码片段：
self.addEventListener('fetch', event => {
const url = new URL(event.request.url);
const blockedHosts = [
'ad-cdn.net',
'doubleclick.net',
'googlesyndication.com',
'taboola.com'
];
if (blockedHosts.some(host => url.hostname.includes(host))) {
// 返回空响应，避免资源加载
event.respondWith(new Response('', { status: 200 }));
return;
}
// 允许其他请求正常进行
event.respondWith(fetch(event.request));
});
注意：url.hostname.includes(host) 是宽松匹配（比如匹配 secure.ad-cdn.net），若需精确匹配可用 url.hostname === host 或正则。
限制与注意事项
以下情况 Service Worker 无法生效：
-
iframe 广告：若广告以第三方 iframe 形式嵌入（
），其子资源请求由 iframe 自身上下文发起，SW 仅能拦截主页面发起的请求，无法控制 iframe 内部的 fetch（除非该 iframe 与你的站点同源，这几乎不可能）； - 不支持 SW 的浏览器或禁用状态：如部分旧版 Safari、隐私模式下的某些浏览器会禁用 SW；
- HTTPS 要求：Service Worker 只能在 HTTPS（或 localhost）下注册，HTTP 站点无法使用；
-
缓存干扰：若广告资源已被 HTTP 缓存（如 via
Cache-Control），可能绕过 SW；建议在拦截逻辑前调用event.request.cache === 'default'判断，但不可依赖。
更现实的替代方案
若目标是减少广告加载，优先考虑以下更稳定的方式：
- 在 HTML 中移除或延迟加载广告脚本（如用
loading="lazy"、data-src+ 手动注入）； - 使用
Content-Security-PolicyHTTP 头阻止特定域名的 script/image/fetch 加载（服务端配置，比 SW 更早生效）； - 浏览器扩展（如 uBlock Origin）才是专为跨站广告拦截设计的机制，不受同源限制；
- 若你是广告平台方，可通过自定义加载逻辑+白名单控制资源来源，而非依赖拦截。
Service Worker 的拦截能力有限，适合可控环境下的轻量级过滤，不适合对抗复杂广告生态。真正可靠的广告屏蔽，仍需结合服务端策略与客户端扩展协同完成。
