做前端这些年，iframe 自适应高度这个问题我至少被问过十几回：嵌入一个报表、一个编辑器、一段第三方页面，内容稍微一动，高度就不够，底部直接出现滚动条。网上最常见的答案是"用 scrollHeight 给 iframe 赋值"，但真放到生产环境你会发现，load 事件只触发一次、跨域根本读不到子页面 DOM、SPA 页面内容还在不断变化，远没有想象中那么简单。这篇文章我打算把同域、跨域、动态内容、嵌套页面这些场景一次性讲透，给出一个真正能落地到项目的"终极方案"——它不是某个魔法 API，而是一套按场景组合的监控与通信策略。适合刚接触 iframe 的初学者，也适合被动态 iframe 反复折腾的老手拿来对照排查。
1. 为什么 iframe 自适应高度这么棘手：先看懂卡点在哪里
1.1 iframe 不是普通的"子元素"
很多人第一次写 iframe 时都会下意识拿它当普通 div 处理，觉得子元素多高，父容器就会被撑多高。真实情况完全不是这样。
iframe 的本质，是在页面里嵌入了一个独立浏览上下文。子页面有自己完整的 document、body、CSS 渲染链路，它的高度变化不会像普通 DOM 节点那样主动"撑大"父页面里的 iframe 占位盒。iframe 元素本身的高度，只取决于你在 HTML 属性或 CSS 里写死的值——比如默认的 150px。一旦内部文档的实际高度超过这个值，浏览器就会在 iframe 内部渲染出滚动条。
所以这个问题的核心矛盾很简单：iframe 的高度是外部静态决定的，而子页面的高度是内部动态生长的。我们做自适应，本质上就是在这两个高度之间建立一条持续同步的通道。
1.2 三个决定方案难度的维度
我在实际项目里判断一个 iframe 自适应需求难不难，一般只看三个维度：
| 维度 | 简单场景 | 困难场景 |
|---|---|---|
| 域名关系 | 同域（父页面和子页面同源） | 跨域（第三方页面、不同子域名） |
| 内容变化 | 静态内容，加载一次即可 | SPA 路由切换、折叠面板、懒加载图片 |
| 页面控制权 | 子页面是自己的，可以改代码 | 子页面是别人的，完全动不了 |
这三个维度组合起来，基本覆盖了所有 iframe 场景。同域且静态，那确实几行代码搞定；跨域且动态，就得同时解决"通信手段"和"监听时机"两个问题。后文我会按这个难度递进展开，你会发现最终方案其实是有规律可循的。
1.3 自适应方案的核心三件事
不管场景多复杂，要解决 iframe 自适应高度，永远只需要回答三个问题：
- 怎么量：拿到子页面文档的真实高度（
scrollHeight、offsetHeight、body和documentElement取大值）。 - 什么时候量：内容变化、图片加载、窗口缩放、路由切换这些关键时机不能漏。
- 怎么传过去：同域可以直接读
contentDocument，跨域只能靠postMessage通信。
后文所有方案，都是围绕这三个问题展开的。看懂了这一点，你就不会被各种花哨写法绕晕。
2. 同域 iframe：从 load 量高到 ResizeObserver 的完整演进
2.1 最基础的做法：load 后读取 scrollHeight
先看最经典的写法。父页面里：
const iframe = document.getElementById('myFrame'); iframe.addEventListener('load', function () { const doc = iframe.contentDocument; iframe.style.height = doc.documentElement.scrollHeight + 'px'; });原理是contentDocument可以直接访问子页面的 DOM，scrollHeight拿到的是内容完整高度，赋值给 iframe 的 CSS 高度后，内部滚动条就会消失。
但这个写法有两个致命短板：
load事件只在页面首次加载完成时触发一次，之后子页面内容怎么变都不管了；- 如果子页面里有图片没设置宽高，
load触发时图片可能还没加载完，高度自然就是错的。
所以这个版本只能用来"临时顶上"，面试可以讲，生产别直接用。
2.2 用 MutationObserver 追踪 DOM 变化
要让高度跟着内容走，最容易想到的是监听子页面的 DOM 变化。在同域前提下，父页面可以直接对子页面的body做监听：
const iframe = document.getElementById('myFrame'); const doc = iframe.contentDocument; function syncHeight() { requestAnimationFrame(() => { iframe.style.height = Math.max( doc.documentElement.scrollHeight, doc.body.scrollHeight ) + 'px'; }); } const observer = new MutationObserver(syncHeight); iframe.addEventListener('load', function () { observer.observe(doc.body, { childList: true, subtree: true, characterData: true, attributes: true }); syncHeight(); });这里有几个实践经验：
- 必须等 load 之后再
observe。iframe 没加载完时contentDocument可能是空壳，直接操作很容易报错。 - 变更发生后先
requestAnimationFrame再读取高度。DOM 刚变的时候渲染还没完成，同步读scrollHeight拿到的经常是旧值，rAF 能等到渲染即将发生前再量，准确率提高很多。 subtree: true开销不小。如果子页面很大，每一次小改动都会触发整个子树检查。实际项目里可以只监听内容区容器，或者用防抖把频率降下来。
2.3 ResizeObserver 才是同域的优选答案
MutationObserver 的问题是它监听的是"有没有变化"，而真正关心的是"高度变没变"。例如子页面里某个隐藏元素频繁增删节点，高度根本没变，MutationObserver 还是会一直触发。这就有浪费。
换成 ResizeObserver 就舒服多了，它只在目标元素尺寸真正改变时回调：
const iframe = document.getElementById('myFrame'); iframe.addEventListener('load', function () { const doc = iframe.contentDocument; const syncHeight = () => { iframe.style.height = Math.max( doc.documentElement.scrollHeight, doc.body.scrollHeight ) + 'px'; }; const resizeObserver = new ResizeObserver(syncHeight); resizeObserver.observe(doc.body); syncHeight(); });ResizeObserver监听的是元素盒模型尺寸变化，比 MutationObserver 更贴近"高度变了"这个语义，性能也更好。现代浏览器早就标配了，不用太担心兼容性，老 IE 不在考虑范围的话可以直接用。
注意：这里监听
doc.body是常规做法。如果内容被绝对定位或者是表格布局，body的高度可能不能反映真实内容，稳妥一点就同时读documentElement.scrollHeight和body.scrollHeight取最大值。
2.4 同域场景下的子页面主动通知
同域还有一个思路：与其父页面偷偷看子页面，不如让子页面自己算好高度，再通知父页面。
子页面里：
function postHeight() { const height = Math.max( document.documentElement.scrollHeight, document.body.scrollHeight ); // 同域下也可以用 postMessage，甚至直接调父页面函数 window.parent.postMessage({ type: 'fit-height', height }, '*'); } window.addEventListener('load', postHeight); const observer = new ResizeObserver(postHeight); observer.observe(document.body);这种"子页面主导"的模式有个隐含优势：高度数据在产生数据的地方计算，永远是最准确的。比如子页面内部还嵌套了其他 iframe，父页面直接量可能只量到中间容器的壳，而子页面自己知道完整内容高度。后面跨域方案的核心思路也会延续这一点。
3. 跨域 iframe：postMessage 通信方案的实战细节
3.1 同源策略的限制与消息通道的选型
一旦父子页面跨域，问题立刻变复杂：父页面执行iframe.contentDocument会直接抛SecurityError，因为浏览器不允许跨源读取子页面 DOM。contentWindow.document同样拿不到。
跨域之间唯一稳妥的交互通道，就是window.postMessage。它是浏览器原生提供的跨窗口消息机制，明确允许跨源传递数据。我们只需要约定一套消息协议：子页面量好高度，通过postMessage发给父页面；父页面收到后，根据消息里的标识找到对应 iframe，更新高度。
3.2 子页面：计算高度并主动上报
如果子页面代码控制在你手里，最佳实践是在子页面里封装一个"高度上报器"，把量高、触发时机、上报全部包进去。
(function () { function getHeight() { return Math.max( document.documentElement.scrollHeight, document.body.scrollHeight, document.documentElement.offsetHeight ); } function postHeight() { parent.postMessage({ type: 'fit-iframe', height: getHeight() }, '*'); } // 初次加载：等 DOM 和资源都就绪后再发一次 window.addEventListener('load', postHeight); // 图片、字体等异步资源可能晚于 load 加载完 document.fonts && document.fonts.ready.then(postHeight); // 内容高度随 ResizeObserver 实时变化 const observer = new ResizeObserver(postHeight); observer.observe(document.documentElement); // 兜底：窗口尺寸变化也意味着内容可能重排 window.addEventListener('resize', postHeight); })();这里我特意加了三条触发链路：
load事件保证初始高度正确；ResizeObserver接管内容变化；resize事件兜底处理窗口尺寸变化带来的重排。
另外你可能会问，postMessage的第二个参数为什么传'*'？因为子页面在部署到不同域名时不需要改代码，目标源由父页面自己控制更灵活。安全方面靠父页面校验来源就够了，这点放下一节讲。
3.3 父页面：监听 message 并按来源匹配 iframe
父页面的职责是接收消息、校验来源、把高度写到对应 iframe 上。
const frameMap = {}; // 用 id 维护多个 iframe document.querySelectorAll('iframe[data-fit-id]').forEach((frame) => { frameMap[frame.dataset.fitId] = frame; }); window.addEventListener('message', function (event) { const data = event.data; if (!data || data.type !== 'fit-iframe') return; const frame = frameMap[data.id]; if (frame) { frame.style.height = data.height + 'px'; } });对应的子页面上报要带上自己的标识：
parent.postMessage({ type: 'fit-iframe', id: 'report-panel', height: getHeight() }, '*');多 iframe 页面里，data.id是防止高度串场的关键。没有这个字段，两个 iframe 同时发消息，父页面根本不知道该给谁赋值。
安全校验也要跟上。生产环境建议维护一个允许的来源白名单：
const ALLOWED_ORIGINS = ['https://child.example.com']; window.addEventListener('message', function (event) { if (!ALLOWED_ORIGINS.includes(event.origin)) return; // ...后续处理 });注意：很多演示代码里不校验
event.origin，直接把消息当可信数据用。轻则页面高度被恶意篡改，重则引发一些脏数据注入问题。少写一行校验，后面要多追很多 bug。
3.4 初始化阶段的时序坑：消息可能比监听器先到
跨域方案里最隐蔽的坑，是"子页面比父页面先执行完上报逻辑，消息发出去了，父页面还没来得及挂监听"。
这种现象发生在父页面脚本被延迟加载、或 iframe 在 HTML 中顺序靠前的情况下。一次性的postMessage丢了就再也补不回来了，iframe 会一直停留在默认高度。
解决方法是引入"握手"机制：父页面在 iframe 的load事件里主动向子页面发一条"请上报高度"的消息，子页面收到后再回传当前高度。
父页面：
iframe.addEventListener('load', function () { iframe.contentWindow.postMessage({ type: 'fit-iframe-request', id: iframe.dataset.fitId }, '*'); });子页面：
window.addEventListener('message', function (event) { if (event.data && event.data.type === 'fit-iframe-request') { postHeight(); } });这样无论谁先执行，最终父页面总会拿到一次完整高度。在我接手的项目里，这个握手步骤是跨域方案里最值得加的一环，它把"大概率能跑"变成了"稳定能跑"。
4. 隐藏滚动条与双层滚动的正确姿势
4.1 先澄清：滚动条通常不是"藏"没的，而是"不该出现"
很多人一听到 iframe 滚动条就去给父页面写overflow: hidden，结果发现根本没用。原理很简单：iframe 内部的滚动条属于子页面的浏览上下文，父页面 CSS 管不到里面。
正确逻辑是：高度精准对齐内容，滚动条自然就不存在了。这也是为什么我说自适应是隐藏滚动条的根本手段——滚动条是高度失配的"症状"，不是独立问题。
如果子页面代码可控，可以在子页面里再补一句：
html, body { overflow: hidden; }但这句话只是双保险，你仍然得把父页面 iframe 高度算对，否则内容会被截断。你不可能既想让滚动条消失，又想随便给个固定高度，两者是矛盾的。
4.2 第三方页面完全不可控时怎么办
遇到了无法改代码的第三方 iframe，又必须隐藏滚动条，我能想到的只有两条路：
第一种，用容器裁剪。外层 div 固定高度并overflow: hidden，内部 iframe 高度放大到超出容器，滚动条区域被裁掉。视觉上滚动条消失了，但底部内容可能有一部分被截掉，只适合内容相对固定、底部不重要的场景。这个方案我从头就不推荐，因为它牺牲了内容完整性。
第二种，接受固定高度。如果第三方页面本身不改，它的内容高度稳定，你可以通过测量或对方文档知道大概高度，直接定高。但这和"自适应"已经没关系了。
诚实地说，如果第三方页面不支持主动上报也没有同域通道，就真的没有完美方案。市面上搜到的"终极技巧"八成都有代价，要么裁剪内容，要么性能牺牲。
4.3 嵌套 iframe：双层滚动条与多级消息传递
"iframe 嵌套页面"是另一个高频热词。页面 A 嵌了页面 B，B 里又嵌了页面 C。这种情况下，即使每一层都做了自适应，全局仍然可能出现一层一层叠加的滚动条。
关键在于多级消息的路由。C 要上报高度给 B，B 要把"自身高度加上 C 贡献的高度"再上报给 A。比较简单的做法是每一层都向上转发，并带上层标识：
// 页面 B 里，收到 C 的高度后重新量整体高度再上报给 A window.addEventListener('message', function (event) { if (event.data.type === 'fit-iframe') { // C 已经把自己的高度发给 B 了 // B 等一帧，重新量自身整体高度 requestAnimationFrame(function () { postHeightToParent(); }); } });这里有一个容易踩的坑：直接转发 C 给 B 的高度到 A 是不够的，因为 B 页面的头部、内边距、页脚都会影响最终高度。正确做法是"收到子级消息后，重新测量自身整体高度再上报"，而不是简单透传。嵌套层级越多，越要强调重新测量。
4.4 细节打磨：字体、图片、动画带来的高度偏差
最后几个小坑，都是我在真实页面里碰到过的：
- 图片没设宽高：
load事件触发后图片才加载完，高度突然增加，此时需要再上报一次。子页面里可以给每张图片加onload回调，或者简单点，在load后加一个延时兜底。 - webfont 加载：字体文件加载前后，行高和文字宽度都会变化，导致高度漂移。
document.fonts.ready是个很好的补充上报时机。 - 高度过渡动画：给 iframe 加
transition: height 0.2s会让人感觉更顺滑，但如果动画期间内容也在变，高度会一直追赶。我的建议是过渡时间只保留在 0.2s 以内，或者干脆不加，避免"越追越乱"。
5. 动态 iframe（SPA 路由切换等）如何做到实时同步
5.1 动态内容的两个真正来源
"动态 iframe"之所以特殊，是因为内容的高度不是在某个节点一次性确定的。两类来源最典型：
一类是子页面内部状态变化，比如 React 路由切换、手风琴展开、表格数据刷新，子页面自己知道内容变了。另一类是父页面容器宽度变化，父页面变窄，子页面的文字换行变多，高度也跟着变，但子页面自己感知不到这个变化来源。
这两种来源，决定了监控策略必须是"内外结合"。
5.2 轮询方案为什么经常被选，又为什么被嫌弃
最直观的动态方案是轮询：
setInterval(function () { const doc = iframe.contentDocument; if (doc) { iframe.style.height = Math.max( doc.documentElement.scrollHeight, doc.body.scrollHeight ) + 'px'; } }, 500);跨域场景下还可以轮询通过消息请求高度，子页面收到就回传。优点是实现简单、和框架无关；缺点是每一帧都在消耗 CPU，即使内容完全没变也会持续触发，对移动端尤其不友好。轮询间隔也难拿捏：间隔太短性能浪费，间隔太长高度更新会有明显延迟。
我把它定位成"兜底方案"而不是"推荐方案"，适合子页面无法插桩监听逻辑的情况。
5.3 ResizeObserver + postMessage 的组合：事件驱动实时同步
动态 iframe 的最优解，是把"监听"这件事放到最了解内容变化的地方去。两行原则：
- 子页面内容自己变，由子页面里的
ResizeObserver感知； - 父页面宽度变化，由父页面广播给子页面，子页面重新测量再回传。
这个闭环恰好能覆盖 5.1 说的两类动态来源。父页面在窗口 resize 时发送请求：
window.addEventListener('resize', function () { const width = iframe.getBoundingClientRect().width; iframe.contentWindow.postMessage({ type: 'fit-iframe-request', width: width }, '*'); });子页面收到请求后，如果带了width，先让页面按这个宽度重新布局，再量高度回传。这一步特别重要：很多动态高度问题，根源不是子页面内容变多了，而是外部宽度变了导致重排。
之前有次做报表嵌入，用户在父页面拖宽左侧栏，iframe 宽度变了，子页面表格列挤成一团，高度暴增，但实际上一条数据都没变。靠这个"外部宽度请求重算"机制，一帧就修好了。
5.4 三种监控手段的选型对比
把前面几节内容整理成一张表，方便不同项目直接对号入座：
| 方案 | 适用场景 | 事件粒度 | 性能开销 | 实现复杂度 |
|---|---|---|---|---|
| MutationObserver | 子页面 DOM 变化 | 细（每次 DOM 变动） | 高 | 低 |
| ResizeObserver | 子页面尺寸变化 | 中等（尺寸变才触发） | 中 | 低 |
| 轮询 setInterval | 无法插桩的第三方页面 | 固定间隔 | 持续开销 | 最低 |
动态内容越频繁，越应该从"轮询"切到"事件驱动"。这也是我反复强调的方向：高分页面的共同点是尽量不干活，只在真正需要的时候才量一次、传一次。
6. 在 React / Vue 里封装可复用的 FitFrame 组件
6.1 为什么值得封装成组件
业务里一旦出现两个以上 iframe 嵌入点，就值得抽成一个通用组件。否则每个页面都复制一遍"load 监听 + message 监听 + 高度置空 + 清理监听"的样板代码，后期改起来会非常痛苦。组件化之后，通信协议收敛在一个文件里，后续升级也只需要改一处。
6.2 React 组件实现
下面这个FitFrame组件兼容同域和跨域两种场景：先尝试直接读contentDocument，成功就走 self-fit；失败则依赖子页面主动上报的fit-iframe消息。
import { useEffect, useRef } from 'react'; interface Props { src: string; id?: string; title?: string; } function FitFrame({ src, id, title }: Props) { const frameRef = useRef<HTMLIFrameElement>(null); useEffect(() => { const frame = frameRef.current; if (!frame) return; let resizeObserver: ResizeObserver | null = null; const setHeight = (height: number) => { frame.style.height = `${height}px`; }; const handleLoad = () => { try { // 同域：直接读子页面 contentDocument const doc = frame.contentDocument; if (doc && doc.body) { const sync = () => { requestAnimationFrame(() => { setHeight(Math.max( doc.documentElement.scrollHeight, doc.body.scrollHeight )); }); }; resizeObserver = new ResizeObserver(sync); resizeObserver.observe(doc.body); sync(); } } catch (err) { // 跨域：主动向子页面请求一次高度 frame.contentWindow?.postMessage( { type: 'fit-iframe-request', id }, '*' ); } }; const handleMessage = (event: MessageEvent) => { if (event.data && event.data.type === 'fit-iframe') { if (!id || event.data.id === id) { setHeight(event.data.height); } } }; frame.addEventListener('load', handleLoad); window.addEventListener('message', handleMessage); return () => { frame.removeEventListener('load', handleLoad); window.removeEventListener('message', handleMessage); resizeObserver?.disconnect(); }; }, [id]); return <iframe ref={frameRef} src={src} id={id} title={title} />; } export default FitFrame;几个设计要点：
try / catch是判断同域与否的常用手段，捕获到错误就说明跨域，自动切到消息模式；- 清理函数里必须
disconnect()和移除事件监听，否则组件卸载后还会继续收到子页面消息，严重时甚至操作已卸载的 DOM； - 消息处理按
id分流，多组件共存时不会串台。
6.3 Vue 3 里的对应版本
Vue 3 组合式写法更直接：
<script setup lang="ts"> import { ref, onMounted, onBeforeUnmount } from 'vue'; const props = defineProps<{ src: string; id?: string }>(); const frameRef = ref<HTMLIFrameElement | null>(null); function setHeight(height: number) { if (frameRef.value) frameRef.value.style.height = `${height}px`; } function handleLoad() { const frame = frameRef.value; if (!frame) return; try { const doc = frame.contentDocument; if (doc?.body) { const sync = () => setHeight(Math.max( doc.documentElement.scrollHeight, doc.body.scrollHeight )); const ro = new ResizeObserver(sync); ro.observe(doc.body); sync(); } } catch { frame.contentWindow?.postMessage( { type: 'fit-iframe-request', id: props.id }, '*' ); } } function handleMessage(event: MessageEvent) { if (event.data?.type === 'fit-iframe') { if (!props.id || event.data.id === props.id) { setHeight(event.data.height); } } } onMounted(() => { window.addEventListener('message', handleMessage); }); onBeforeUnmount(() => { window.removeEventListener('message', handleMessage); }); </script> <template> <iframe ref="frameRef" :src="src" @load="handleLoad"></iframe> </template>6.4 组件化方案的边界
封装好之后，必须明确一个前提：跨域能否生效，取决于子页面是否实现了fit-iframe消息协议。如果是第三方的页面，又不支持这套协议，那组件就只能退回固定高度模式。
所以在集成文档里，建议把子页面需要嵌的这段"上报脚本"一并提供出去。我们团队的做法是维护一个iframe-fit.js，子页面只需要引入并调用initFit()，父子之间的通信协议就自动建立。
7. 延伸一下：自动化测试与数据采集场景里的 iframe 处理
7.1 Playwright 定位 iframe 内元素的标准姿势
iframe 适配写完之后，另一个高频问题浮出来：自动化脚本怎么拿到 iframe 里面的内容？尤其动态 iframe，开发环境看着好好的，测试脚本一跑就定位不到元素。
Playwright 提供了frame_locator，可以链式进入 iframe 内部选择元素：
from playwright.sync_api import sync_playwright with sync_playwright() as p: browser = p.chromium.launch() page = browser.new_page() page.goto("https://example.com/embed-page") # 方式一：按照定位器进入 iframe frame = page.frame_locator("iframe#content") frame.locator(".report-title").wait_for(state="visible") # 方式二：按 name 直接取 Frame 对象，可以 execute 任意 script frame = page.frame("content") height = frame.evaluate("() => document.documentElement.scrollHeight") print("iframe 实际高度:", height) browser.close()frame_locator和page.frame的区别要清楚：前者只负责在特定 iframe 内做元素定位，拿不到完整的 Frame 上下文；后者拿到 Frame 对象后可以执行 evaluate，适合读取 iframe 内部的高度、文本、属性等数据。
7.2 用 Playwright 回归验证自适应是否真的生效
我可以给整套自适应方案加一个自动化回归测试，思路很简单：加载页面，读取 iframe 内部scrollHeight，再比对 iframe 元素自身的 CSS 高度。两者差距在 1px 以内就算通过。
def test_iframe_adaptive_height(page): page.goto("https://example.com/parent") iframe = page.locator("iframe#content") iframe.wait_for(state="attached") frame = page.frame("content") inner_height = frame.evaluate("() => document.documentElement.scrollHeight") css_height = iframe.evaluate("el => parseFloat(el.style.height)") assert abs(inner_height - css_height) <= 1, f"height mismatch: {inner_height} vs {css_height}"这个测试对动态 iframe 特别有用，因为人工肉眼很难发现那几次"只差几个像素"的高度偏差，自动化可以每次都盯着。
7.3 动态 iframe 在采集场景里的等待策略
顺着这个思路往下走，必然要处理"动态 iframe 内容没渲染完就抓取"的问题。尤其在数据采集项目里，iframe 内容可能是 SPA 懒加载的，直接抓取很容易拿到空值。
一个稳妥的等待策略是：等 iframe 内目标元素可见，再等高度连续两次读取稳定，最后才开始提取数据。
frame = page.frame("content") # 1. 等待 iframe 内核心元素出现 frame.locator(".data-row").first.wait_for(state="visible") # 2. 等待高度稳定，说明资源与渲染基本结束 height = frame.evaluate("() => document.documentElement.scrollHeight") for _ in range(10): page.wait_for_timeout(300) new_height = frame.evaluate("() => document.documentElement.scrollHeight") if abs(new_height - height) <= 2: break height = new_height # 3. 高度稳定后再执行提取 rows = frame.query_selector_all(".data-row")这套策略在 Scrapy Playwright 这类"渲染后采集"的流程里非常实用。先让 Playwright 渲染页面，然后用上述等待逻辑确保 iframe 内部数据就绪，再交回业务层处理。
实践中我也遇到过 iframe 内部懒加载图片导致高度稳定后又跳变的情况，处理方式是只把"高度稳定"当作数据提取的门槛，不完全当作渲染完成的信号，关键数据元素可见性优先。
回到自适应本身，我现在的选择习惯非常简单：自己控制的子页面，一律走 ResizeObserver 上报；同域场景，ResizeObserver 直接监听子页面 body 也足够；无法控制的第三方页面，固定高度或容器裁剪，承认没有完美解。你手头如果有类似的 iframe 嵌入需求，建议先按我第一节的三个维度理清场景，再挑对应章节的代码直接落地——这套组合我用了好几个项目，基本没有再被 iframe 高度问题缠住过。
