Web 平台 API / iframe 的尺寸 · 让内容决定高度 待审核 4 页

iframe 的尺寸 · 让内容决定高度

<div> 的高度由内容决定，<iframe> 不是。它是一个替换元素，默认尺寸 300 × 150，内嵌文档再长也只会出现一条内部滚动条。这个设计有它的理由：跨源 iframe 的内容尺寸本身就是信息，外层页面若能读到它，就能推断出用户在另一个站点上的登录状态或内容长短。

评论组件、嵌入式代码演示、第三方表单都需要 iframe 跟着内容长高。2016 年 whatwg/html#555 与 2017 年 CSSWG #1771 先后提出这件事，在规范落地之前，通行的做法是内嵌文档用 ResizeObserver 量自己的高度，再用 postMessage 告诉外层去改 height。Chrome 154（2026-09）实现了 CSS Sizing 4 的 frame-sizing：外层声明愿意按内容定尺寸，内嵌文档用 <meta name="responsive-embedded-sizing"> 声明愿意公开尺寸，两边都同意才生效。

每页都在真实的 iframe 上实测，内嵌文档由 lab 现场拼成 srcdoc。正文里的读数出自 Chrome 154；其中 <meta> 的写法、iframe 的懒加载提前量两处与规范文本或图片的行为不同，分别在 frame-sizing 与懒加载两页写明。

按内容定尺寸

frame-sizing 与 <meta name="responsive-embedded-sizing"> 的双向约定，尺寸何时计算，以及内容变化后如何用 requestResize() 更新。

frame-sizing · meta

frame-sizing：双方同意才按内容定高

外层用 frame-sizing 声明愿意按内容定尺寸，内嵌文档用一条 <meta> 声明愿意公开尺寸，缺一不可。实测这条 <meta> 必须带 allow-origins，且须出现在 <body> 之前。

requestResize · locked ICB

requestResize() 与锁定的 ICB

加载后的内容变化要由内嵌文档调用 requestResize() 才会反映到 iframe 上。尺寸取滚动区域，下限是首次布局时锁定的视口高度；100vh 内容按锁定值计算，循环由此切断，代价是内部滚动条。

加载与旧方案

iframe 的 loading="lazy" 与占位，以及 postMessage 方案的写法、它为什么会陷入循环，和两套方案的衔接。

loading="lazy" · 2500px

iframe 的懒加载与占位

iframe 与图片共用 loading，提前量却不同：iframe 纵横都是 2500px，图片是 1250 与 625。srcdoc 与 blob: 的 iframe 无视 lazy。按内容定高的跳变多发生在视口之外。

postMessage · ResizeObserver

postMessage 旧方案与渐进增强

旧方案由内嵌文档用 ResizeObserver 量高度、postMessage 通知外层改 height，实时且跨浏览器，遇到 100vh 却会循环增长。推荐以 frame-sizing 为主、旧方案为回退。