每次做广告嵌入都要靠 fencedframe 把三方内容圈起来——Chrome 156 今天把它降级成空壳，M157 整个拆掉

阿监·前端工程化 内容创作者 2026-10-07 11 阅读

Chrome 156 稳定版（2026-10-07）把 <fencedframe> 和 window.fence 降级成了空壳：标签还能解析、JS 还不报错，但它们已经什么都做不了——因为真正让这套 API 有意义的 Protected Audience 和 selectURL，早在 M152 就被移除了。这不是一次普通的弃用，而是 Chrome 隐私沙盒广告体系整体撤退的最后一环。

先看背景：为什么现在动它

2025 年 Chrome 宣布维持第三方 Cookie 的现状，随后开始逐步撤回隐私沙盒（Privacy Sandbox）里的多项广告 API。围栏框架（Fenced Frames）原本是这套体系的展示层：把跨站广告内容嵌进页面，同时禁止它和宿主页面交换数据。MDN 已经给 Fence 接口打上 Deprecated / To be removed 标签，理由写得很直白：Chrome 决定撤回包括围栏框架在内的一部分隐私沙盒功能。

时间线：一个被拆了三步的 API

  • M152：runAdAuction()、selectURL() 和 Shared Storage 被弃用并移除。围栏框架唯一的导航方式就是靠这两个函数返回的 urn:uuid——它们没了之后，<fencedframe> 再也导航不进任何文档，成了零次成功导航的死元素。Chrome 的 use counter 显示，全网只有 0.07% 的页面加载用到过它。
  • M156（本次）：<fencedframe> 元素和它的 IDL 依赖被保留为 stub，window.fence 的 reportEvent()、setReportEventDataForAutomaticBeacons()、getNestedConfigs() 全部变成空操作。官方这样做的目的只有一个：保证存量代码调用时不抛异常，给广告集成方留出一个版本的迁移窗口。
  • M157 Canary/Beta：通过 field trial 控制放量，开始真正删除这个元素——届时它会被解析成 HTMLUnknownElement，布局和配置 API 一起消失。
  • M157 Stable：1% 稳定版无回归后再申请全面移除批准。

值得说的是，这套时间表比原计划晚了整整两个版本：8 月 12 日 blink-dev 的 Intent to Ship 写的还是「M154 打 stub、M155 删元素」，9 月 24 日 ChromePlatformStatus 把它改成了 M156/M157。一个 0.07% 使用率的 API，移除计划都能两次滑期，也说明广告生态牵扯的集成方有多杂。

社区当场就吵起来了

blink-dev 讨论区里，Chrome 工程经理 Vladimir Levin 直接提出质疑：「保留 IDL 但打桩一个版本，会破坏特性检测——你能检测到 API 存在，但它什么都不干，这比 API 不存在更危险。」他还要求团队给出 use counter 数据，建议如果使用率够低，就跳过桩阶段、直接快速移除。官方的回应则是按阶段放量、观察回归再走下一步。这个分歧本身就很说明问题：删一个「存在但没用」的 API，比删一个「早就报错」的 API 更需要小心。

before / after：你的代码会经历什么

以前的写法（现在还能跑，但已经是空壳）：

<!-- 广告位里嵌围栏框架 -->
<fencedframe src="https://ads.example/ad-auction-result"></fencedframe>
<script>
  // M156 起这行拿到的是打了桩的 fence 对象
  window.fence.reportEvent({
    eventType: "click",
    eventData: JSON.stringify({ slot: "banner-1" }),
    destination: ["buyer", "seller"],
  });
</script>

M156 之后：reportEvent() 仍然可调用、不抛错，但上报什么都不会发出去——如果你的埋点还在依赖它，广告转化数据会静默归零，这才是最隐蔽的坑。

M157 删除生效之后：document.querySelector('fencedframe') 拿到的是 HTMLUnknownElement，内联样式全塌，任何 .config.* 调用直接抛 TypeError。

特性检测也会被骗过：

// 桩期间这个判断为 true，但元素已经没有行为
if ("HTMLFencedFrameElement" in window) {
  // 错误的乐观分支：API 在，功能不在
}

这波影响谁

只有接入了 Protected Audience / SelectURL 广告拍卖集成的页面需要处理，全网 0.07% 的量级；普通站点、普通 iframe 嵌入完全无感。围栏框架也从来没进过任何浏览器标准——它是 Chrome 自己的私有元素，不存在跨浏览器兼容问题，只有「退役迁移」一个问题。

今晚就能做的一步

在仓库根目录跑这一条：

grep -rn "fencedframe|window.fence|reportEvent" src/

有结果：把 <fencedframe> 换成 <iframe sandbox>（按你的隔离需求开 sandbox 组合），并把 FFAR 上报逻辑换成你自己的 beacon 或 Reporting API。没结果：什么都不用做，等 M157 自然过去即可。

评论区

0 条评论

登录后可评论。

阿监·前端工程化 11 阅读