Go 错误聚合实战指南：深入 go.uber.org/multierr 的 Combine、Append 与 defer 安全合并
2026/9/24 23:58:57
跟 iframe 打过交道的人应该都有体会：这个标签说简单也简单，一个 src 就能往页面里塞进另一个文档；说复杂也复杂，嵌套通信、安全限制、跨域问题、移动端兼容，每一项都能把人折腾得够呛。最近我在做项目时，把 iframe 相关的几个高频场景——页面嵌套、PDF 预览、隐藏滚动条、动态 iframe 抓取——几乎全部踩了一遍，所以想用这篇文章把 iframe 的用法从基础到实战做一次全面梳理，顺便把网络热搜里几个问得最多的问题一并讲清楚。
无论你是刚开始写前端的新手，还是经常写爬虫的工程师，只要涉及“在页面里嵌入另一份内容”，这份梳理都值得从头看一遍。全文不搞花架子，所有代码都给可直接复制的版本，并解释背后的原理。你在阅读时可以把这篇文章当作一份 iframe 排查手册，遇到问题直接索引到对应章节。
这套内容是我在真实项目中一点点攒出来的。比如 iframe 嵌套页面时父子如何通信、PDF 在 iframe 里手机端怎么从下载改成预览、iframe 隐藏滚动条有哪些不生效的坑、以及用 Scrapy 加 Playwright 抓带 iframe 的动态页面该怎么处理，这些都不是翻文档就能立刻解决的细节，我会在后面的章节里逐一拆开讲。
1. iframe 到底是什么，这篇文章准备聊哪些场景
1.1 iframe 的定位：把另一个文档装进当前页面
iframe 全称是 inline frame，中文常叫“内联框架”。它的核心作用是在当前 HTML 页面中创建一块独立区域，并在这个区域里加载另一个完整的 HTML 文档。简单理解，就是一个页面里再开了一个“窗中窗”，窗内外的两个文档各自拥有独立的 DOM、CSS 和 JavaScript 执行环境。
正因为它具备文档级隔离，很多场景会优先选择 iframe：比如在页面里嵌入第三方地图；接入网银支付控件；引入广告位内容；展示在线的 PDF 文档；甚至不少后台系统中的业务模块也直接用 iframe 拼装。隔离带来安全，也带来了通信成本，后续章节讲的主要内容，就是如何在“隔离”的前提下把嵌套页面用得更顺手。
1.2 为什么到了今天 iframe 还没被淘汰
先聊聊一个经常被质疑的问题：现在前端框架这么成熟，为什么 iframe 还没被淘汰？
核心原因是“隔离”这个特性太值钱了。假设你要在后台系统里嵌入一个其他团队开发的报表页面，对方的技术栈可能跟你完全不一样，强行用前端组件去合并，成本极高；但用一个 iframe 把整个页面包进来，双方互不干扰，整体开发时间能以“小时”计。支付、地图、第三方登录这些场景同理，你无法掌控对方页面的内部实现，但你又必须把对方的服务完整地呈现给用户，iframe 是最稳的“寄生式”集成方式。
另一个原因是，iframe 的通信机制这些年已经足够成熟。早期 iframe 确实很难做父子交互，但现在有postMessage，同源还可以直接操作 DOM，跨源也能安全地传数据。虽然很多前端课程把它讲得很“古老”，但在真实项目里，它依然是我解决“页面套页面”需求的第一优先级方案。
1.3 替代方案不少，该坚持用 iframe 还是换别的
面对同样的需求，市面上也有其他方案：object标签、embed标签、Ajax 拉取片段后用前端框架渲染、甚至 Web Components。这些方案各有优势，但替换 iframe 时往往有一个代价：你失去了“文档级隔离”。
举个例子，Ajax 拉取一段 HTML 再插入页面，内容会直接参与父页面的样式和脚本执行，互相污染的风险很高。object和embed对插件的依赖太重，现代浏览器里很多 MIME 类型都不认了。Web Components 虽然能做样式隔离，但要求集成双方都遵循同一套开发规范，用于跨团队、跨技术栈的第三方嵌入时并不现实。
所以我的选型经验是：如果内嵌内容是自己人维护的、需要深度互动，优先考虑组件化；如果内容来自外部团队、外部站点，或者内容本身是一个完整文档（比如 PDF），iframe 仍然是最省心、最稳妥的选择。
2. iframe 基础用法：属性清单与安全边界
2.1 最常用的几个属性：src、srcdoc、name、width、height
iframe 的基础属性看似不多，但每一个都有讲究。先看一个最典型的写法：
<iframe src="https://example.com/map" name="mapFrame" width="100%" height="400" loading="lazy" allowfullscreen> </iframe>src是 iframe 加载的目标地址，可以是一个普通 URL，也可以写成about:blank来做纯动态容器。name属性经常被忽略，但它有两个实际用途：一是作为window.open和表单提交的target值，二是给自动化测试或爬虫一个稳定的定位标识（Playwright 里page.frame(name='mapFrame')就直接拿这个名字）。width和height控制 iframe 本身的尺寸，可以用像素值，也可以用百分比。
srcdoc是另一个值得掌握的属性，它允许直接在标签里内嵌一段 HTML 字符串作为子文档内容，优先级高于src。这个属性在做“免请求预览”时很好用，比如你要把一段用户编辑后的 HTML 实时渲染成预览效果：
<iframe srcdoc="<html><body><p>这里是预览内容</p></body></html>"></iframe>loading="lazy"是近几年才普及的属性，类似于图片懒加载。如果页面里嵌入了多个 iframe，或者 iframe 在首屏之外，让它延迟到滚动接近时再加载，能明显降低首屏加载压力。唯一要注意的是，对需要首屏就展示的支付、地图类 iframe 不要加这个属性，否则用户有可能体验到一个短暂的白屏过程。
2.2 sandbox：限制 iframe 权限的开关
sandbox 是我个人最看重的一个属性。它的作用是把 iframe 内部的脚本、弹窗、表单提交、导航等能力全部关掉，然后按需放开。哪怕你嵌入的内容来自不可完全信任的第三方，只要合理使用 sandbox，也能把风险压得很低。
常见的权限值如下：
allow-forms：允许内部提交表单allow-modals：允许调用 alert、confirm 等弹窗allow-popups：允许打开新窗口allow-scripts：允许执行脚本allow-same-origin：允许保持同源身份allow-top-navigation：允许 iframe 内部导航父页面allow-presentation：允许使用演示模式
一个典型的安全配置是：
<iframe src="https://third-party.com/widget" sandbox="allow-scripts allow-forms"></iframe>这条配置允许第三方脚本运行，允许表单提交，但不允许它弹窗，更不允许它把父页面导航走。加 sandbox 比不加 sandbox 要安全得多，所以对不熟悉的第三方内容，我建议一律加上这个属性。这里有一个细节要特别提醒：如果同时设置了allow-scripts和allow-same-origin，iframe 内部的脚本可以通过删除自己的 sandbox 属性来解除限制，等于白设了。所以在不需要同源能力的时候，尽量不要把这两个值同时加上。
2.3 静态 iframe 与动态创建 iframe 的写法差异
大多数情况下直接在 HTML 里写静态标签就够了，但如果你要按用户操作动态加载一个模块，或者做组件封装，就需要用 JavaScript 动态创建 iframe。
const frame = document.createElement('iframe'); frame.src = '/path/to/page'; frame.width = '100%'; frame.height = '400'; frame.setAttribute('sandbox', 'allow-scripts'); frame.onload = () => { console.log('iframe 加载完成'); }; document.getElementById('container').appendChild(frame);动态创建时有一个很容易踩的坑：如果你先创建元素、设置 src、再 appendChild，iframe 的加载时机是“被插入 DOM 之后才正式发起”。所以监听onload事件一般不会错过。但如果你先 appendChild，再设置 src，加载可能在设置 src 的瞬间就开始了，此时再挂载 onload 事件可能已经晚了一步。稳妥做法是“先监听、后赋值”，或者在插入前完成事件绑定，这也是我在组件里封装 loadFrame 时一直坚持的顺序。
3. 实操场景一：嵌套页面与跨域通信
3.1 同源情况下父子页面直接交互
如果 iframe 的地址与父页面同源，也就是协议、域名、端口一致，那父页面可以直接访问 iframe 内部的 document。这是最省事的嵌套页面场景，常用于后台管理系统中。
父页面操作子页面：
const frame = document.getElementById('myFrame'); frame.onload = () => { const innerDoc = frame.contentDocument; if (innerDoc) { innerDoc.getElementById('title').textContent = '父页面改了子页面的标题'; } };子页面操作父页面：
window.parent.document.getElementById('parentBtn').style.display = 'none';注意，即使同源，也要等 iframe 加载完成再操作，否则contentDocument可能处于加载中状态，取不到节点。如果 iframe 加载失败，或者目标页面没有正常返回，contentDocument可能为 null，所以我在实际代码里都会加一层空判断。
3.2 跨域通信：postMessage 的正确姿势
跨域之后，contentDocument会被浏览器安全策略拦截，直接访问会抛出SecurityError。这时唯一的正规通信渠道是postMessage。
父页面给子 iframe 发消息：
const frame = document.getElementById('myFrame'); frame.contentWindow.postMessage( { type: 'UPDATE', data: 'hello from parent' }, 'https://child.example.com' );子页面接收消息：
window.addEventListener('message', (event) => { if (event.origin !== 'https://parent.example.com') return; console.log(event.data); });子页面给父页面发消息：
window.parent.postMessage({ type: 'READY' }, 'https://parent.example.com');父页面接收消息：也要校验event.origin。
在我写过的代码里，被问得最多的一个问题是：为什么收不到消息？原因十有八九是targetOrigin写错了。postMessage的第二个参数要求写接收方的“源”，而接收方监听message事件后拿到的event.origin是发送方的“源”，这两者对不上就没法正确判断。另一个容易出错的地方是，许多人把event.source也忘了校验，虽然event.origin校验已能过滤大多数恶意消息，但严格场景下还是建议对event.source做一次身份确认。
3.3 动态 iframe 的加载时机与事件监听
动态 iframe 在嵌入第三方报表或支付模块时很常见，尤其是“点击某个按钮才加载对应模块”的场景。这里的核心是做好加载时机的控制，避免用户点击后出现长时间白屏，也避免重复创建导致资源浪费。
我一般会封装一个 Promise 形式的加载器：
function loadFrame(url, container) { return new Promise((resolve, reject) => { const frame = document.createElement('iframe'); frame.src = url; frame.width = '100%'; frame.height = '600'; frame.addEventListener('load', () => resolve(frame)); frame.addEventListener('error', () => reject(new Error('iframe load failed'))); container.appendChild(frame); }); } loadFrame('https://example.com/report', document.getElementById('reportBox')) .then((frame) => console.log('加载完成', frame.src)) .catch((err) => console.error(err));这里还有一个实战建议：如果页面需要多次切换不同 iframe，不要每次 append 一个新的，最好固定一个容器，切换时把旧 iframe 移除并置空容器。否则旧 iframe 把网络请求和内存一直占着，页面会越用越卡。我遇到过有些后台系统操作几十次后浏览器直接崩溃，事后排查就是因为页面里积累了十几个隐藏的 iframe，把内存吃满了。
4. 实操场景二：iframe 隐藏滚动条的完整方案
4.1 先搞明白滚动条是从哪一层出现的
隐藏滚动条这个需求在网上热度一直很高，但很多人折腾半天没效果，原因是没搞懂 iframe 的滚动条到底长在哪一层。
iframe 本身是一个元素，它的滚动条分为两种：一种是由 iframe 元素自带的滚动能力产生的，由旧的scrolling属性控制；另一种是 iframe 内部子文档通过overflow产生的，这是现代浏览器里最常见的情况。换句话说，当你看到一个 iframe 里内容超出可视区出现滚动条时，滚动条大概率属于子文档，而不是 iframe 元素本身。明白了这一点，就能理解为什么在父页面给 iframe 加overflow: hidden常常没用，因为你改的是外层元素，根本管不到子文档内部。
4.2 常规隐藏方法：scrolling 属性与 CSS overflow
先看传统做法：
<iframe src="inner.html" scrolling="no" style="overflow: hidden;"></iframe>scrolling="no"在老的浏览器里可以让 iframe 不显示滚动条，但在现代浏览器尤其是 Chrome 中，这个属性基本上不再直接作用于子文档。所以如果你只写了这一行，然后发现滚动条还在，不要意外。
更常见的是靠 CSS 修饰。但这里要分两种身份来看：
- 如果你能控制 iframe 内部页面，直接给内部页面的 html 和 body 设
overflow: hidden，这是最干净的方案。 - 如果你掌控不了内部页面，仅通过父页面 CSS 是无法真正隐藏内部滚动条的，因为这是跨文档的样式隔离。
实际操作中，我通常给 iframe 加一层固定尺寸的 wrapper，配合scrolling="no"与overflow: hidden来做双保险，至少能覆盖大部分桌面浏览器，之后再做兼容测试。
<div style="width: 100%; height: 500px; overflow: hidden; border: 0;"> <iframe src="inner.html" scrolling="no" style="width: 100%; height: 100%; border: 0;"></iframe> </div>如果内部页面同源，还有一种终极方案：在 onload 事件里直接改子文档样式。
frame.onload = function () { const doc = frame.contentDocument; if (doc) { doc.documentElement.style.overflow = 'hidden'; doc.body.style.overflow = 'hidden'; } };这个方法能精确地关闭子文档的滚动条，效果最直观。
4.3 非同源页面如何藏掉滚动条
如果 iframe 指向的是跨域页面，你又没法让对方修改内部样式，那前面那套“同源改样式”的方案就失效了。这时通常只有几个可行方向：
第一，跟内嵌内容提供方约定合作，让它在自己的页面样式里加html, body { overflow: hidden; }。这种“合作式嵌入”在第三方报表、数据大屏里很常见，双方约定好容器尺寸和样式规则，问题自然解决。
第二，如果内嵌的是自己团队开发但部署在不同域名的页面，可以考虑在 iframe 后面加一个查询参数，例如?embed=1&hideScroll=1，内部页面检测到参数后自动隐藏滚动条。这种方式比直接改 CSS 更优雅，因为内部页面可以同时兼容“独立访问”和“被嵌入访问”两种状态。
第三，如果以上都不行，那就只能接受内部滚动条的存在。要注意，强行在父页面用遮罩盖住滚动条区域的做法我试过，效果很差：滚动条虽然看不见了，但用户无法滚动到底部，内容还是被截断，属于“视觉效果欺骗”，不建议采用。
5. 实操场景三：PDF 在 iframe 中预览与手机端兼容
5.1 浏览器内置 PDF 预览的行为差异
用 iframe 展示 PDF 是最常见的方案，因为桌面浏览器的内置 PDF 查看器足够好用。你只需要写一行：
<iframe src="report.pdf" width="100%" height="800"></iframe>桌面端 Chrome、Edge、Firefox 基本都能直接展示，支持翻页、缩放、下载。但这种便利在移动端就完全不一样了。Android 上的 Chrome 多数情况下可以预览，但不少国产浏览器和微信内置浏览器会直接唤起下载或打开外部 App。iOS Safari 的问题更明显，在某些系统版本下，iframe 内嵌 PDF 不会像桌面端那样出现内置阅读器，而是很容易触发下载行为。
5.2 手机端“下载不预览”的根因与后端的配合
遇到手机端 PDF 下载而不是预览，先别急着在前端折腾，第一件事是看响应头。
PDF 显示成预览还是下载，很大程度由Content-Disposition决定。如果服务器返回的是：
Content-Disposition: attachment; filename="report.pdf"那浏览器会把它当作附件，走下载流程，iframe 压根不会出现预览界面。想让 iframe 预览，后端需要返回：
Content-Type: application/pdf Content-Disposition: inline; filename="report.pdf"Spring 后端示例：
response.setContentType("application/pdf"); response.setHeader("Content-Disposition", "inline; filename=\"report.pdf\"");Nginx 静态服务示例：
location ~* \.pdf$ { add_header Content-Disposition "inline; filename=report.pdf"; default_type application/pdf; }改完响应头再测一遍，Android Chrome 和部分 iOS 场景会恢复正常。需要说明的是，iOS 的兼容问题没有“一条命令”能解决，因为这是浏览器内核层面的行为差异。如果你要求所有手机端用户都有稳定的预览体验，请接着看 5.3 的前端渲染方案。
5.3 跨端统一预览的两种常用方案：PDF.js 与 pdfobject
如果后端响应头改完之后，移动端依然有不少设备无法预览，那就只能在前端做统一渲染。两个常用方案：PDF.js 和 PDFObject。
PDF.js 是 Mozilla 开源的项目，核心思路是把 PDF 解析后画到 canvas 上，等于绕过浏览器内置 PDF 插件的差异。最基本的使用代码如下：
<script src="https://cdnjs.cloudflare.com/ajax/libs/pdf.js/3.11.174/pdf.min.js"></script> <canvas id="pdfCanvas"></canvas> <script> const pdfjsLib = window['pdfjs-dist/build/pdf']; pdfjsLib.GlobalWorkerOptions.workerSrc = 'https://cdnjs.cloudflare.com/ajax/libs/pdf.js/3.11.174/pdf.worker.min.js'; const url = '/path/to/file.pdf'; pdfjsLib.getDocument(url).promise .then(pdf => pdf.getPage(1)) .then(page => { const canvas = document.getElementById('pdfCanvas'); const ctx = canvas.getContext('2d'); const viewport = page.getViewport({ scale: 1.5 }); canvas.width = viewport.width; canvas.height = viewport.height; return page.render({ canvasContext: ctx, viewport }).promise; }); </script>这段代码只渲染第一页，要做完整预览还需要自己补翻页、缩放、进度条等 UI，工程量并不小。
如果你不想做太重的开发，PDFObject 是更轻量的替代。它内部根据浏览器能力自动选择 iframe 或 embed 进行嵌入：
<script src="https://cdnjs.cloudflare.com/ajax/libs/pdfobject/2.3.5/pdfobject.min.js"></script> <div id="pdfContainer"></div> <script> PDFObject.embed('/path/to/file.pdf', '#pdfContainer'); </script>PDFObject 对不支持 PDF 预览的设备会给出一个“点击打开”的降级提示，至少不会出现白屏。我的建议是：内部后台系统用 PDFObject 最省事；对外正式产品、对移动端体验要求高的话，用 PDF.js 做定制渲染更可靠。
5.4 Blob URL 方式加载 PDF 及常见坑
有时候我们不想把 PDF 的真实地址暴露在 iframe 的 src 里，或者需要带 token 访问接口，这时候可以把文件流先取回来，再转成本地 Blob URL 喂给 iframe。
const resp = await fetch('/api/pdf', { headers: { Authorization: 'Bearer token' } }); const blob = await resp.blob(); const url = URL.createObjectURL(blob); document.getElementById('pdfFrame').src = url;这个方案能解决“接口必须带鉴权头”的问题，也让用户无法直接复制出完整 PDF 地址。但这里有几个坑我必须提醒：
第一，Blob URL 的生命周期由页面管理，页面刷新后就失效，所以不要在刷新后依然尝试读取。第二，用完一定要调用URL.revokeObjectURL(url)释放内存，否则每次预览都会累积内存，尤其在长列表页里频繁预览 PDF，页面很快就会卡顿。第三，Safari 对 Blob URL 加载 PDF 的支持并不稳定，部分 iOS 版本里 iframe 的 src 变成 blob: 链接后依然会触发下载，这种情况下只能退回到 PDF.js 渲染或直接提示用户打开。
6. 实操场景四：动态 iframe 与爬虫自动化处理
6.1 为什么 requests 拿不到 iframe 里的内容
开发爬虫时遇到 iframe 是常有的事。页面长得挺完整，用 requests 一抓，发现里面只有一个<iframe>标签，真正的表格、列表、图表数据全在另一个 URL 里。原因是 iframe 代表的是独立文档，浏览器解析到<iframe>时会再发起一次额外的文档请求，普通 requests 只是一个单纯的 HTTP 请求，不会像浏览器那样继续解析并加载内部子文档。
如果 iframe 的 src 是静态地址，你可以从父页面 HTML 里提取 src，再用 requests 单独请求。但问题往往出在动态 iframe 上：src 是 JavaScript 运行后生成的，或者里面带有时效性的 token 参数，你从静态 HTML 里根本拿不到正确地址。这时候就需要 Playwright、Selenium 这类能驱动真实浏览器的工具来渲染页面，等 iframe 完全加载后再取内容。
6.2 Playwright 操作 iframe 的四种方式
Playwright 官方对 iframe 的支持做得比较完善，常见的操作方式有几种。
第一种是使用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') text = page.frame_locator('#content-frame').locator('.row').inner_text() print(text) browser.close()第二种是直接获取 frame 对象：
frame = page.frame(name='content') # 按 name 属性取 frame = page.frame(url='https://example.com/inner') # 按 url 精确取如果页面里嵌套了多层 iframe，建议先遍历所有 frame 再按条件筛选：
for f in page.frames: if 'content' in f.url: text = f.locator('body').inner_text() break第三种是等待 iframe 出现。很多 iframe 是点击按钮或者异步加载后才出现的，直接page.frame会拿不到。可以用expect_frame来捕获：
with page.expect_frame() as frame_info: page.click('button#openFrame') frame = frame_info.value第四种是直接在 iframe 里执行 JavaScript 逻辑，比如滚动到底部触发懒加载：
frame.evaluate("window.scrollTo(0, document.body.scrollHeight)")6.3 Scrapy 集成 Playwright 抓取 iframe 内容的完整代码
Scrapy 本身不渲染页面，但可以通过 scrapy-playwright 中间件把 Playwright 能力接进来。这样既能保留 Scrapy 的调度、去重、管道存储等优势，又能处理动态渲染和 iframe 加载。
安装依赖：
pip install scrapy scrapy-playwright playwright install chromium在 settings.py 里开启 Playwright 下载处理器：
DOWNLOAD_HANDLERS = { "http": "scrapy_playwright.handler.ScrapyPlaywrightDownloadHandler", "https": "scrapy_playwright.handler.ScrapyPlaywrightDownloadHandler", } TWISTED_REACTOR = "twisted.internet.asyncioreactor.AsyncioSelectorReactor"在 spider 里通过 PageMethod 等待 iframe 出现，然后在 parse 方法中拿到 Playwright 的 page 对象去读 frame：
import scrapy from scrapy_playwright.page import PageMethod class IframeSpider(scrapy.Spider): name = 'iframe_spider' def start_requests(self): yield scrapy.Request( url='https://example.com/page', meta={ 'playwright': True, 'playwright_page_methods': [ PageMethod('wait_for_selector', 'iframe#content'), PageMethod('wait_for_timeout', 1000), ], }, ) async def parse(self, response): page = response.meta['playwright_page'] frame = None for f in page.frames: if 'content' in f.url: frame = f break if frame: text = await frame.locator('body').inner_text() yield {'text': text} await page.close()这里要特别注意等待问题。wait_for_selector('iframe#content')只能保证 iframe 标签出现在 DOM 里，并不代表 iframe 内部文档已经加载完成。如果内部内容还是异步请求的，最好再加一个内部元素的等待，例如：
await frame.locator('.data-table').wait_for(state='visible')或者在 PageMethod 里用wait_for_selector('iframe#content .data-table')这类“跨 frame”选择器来等待，能大幅减少取内容时拿到的还是空页面的情况。
7. 常见问题速查与避坑总结
7.1 高频问题排查表
| 现象 | 可能原因 | 解决方案 |
|---|---|---|
| iframe 内容空白 | 被 X-Frame-Options 或 CSP frame-src 拦截 | 查看响应头，联系内嵌方加白名单，或改用服务端代理 |
| iframe 高度显示不全 | 未设置高度或内部内容自适应 | 同源可读取 scrollHeight 动态设置，跨域可用 message 通信同步高度 |
| 隐藏滚动条无效 | 只改了外层 CSS，未处理子文档 overflow | 同源用 JS 改内部样式，跨域由内嵌页面配合 |
| PDF 在手机端点开是下载 | Content-Disposition 为 attachment | 改成 inline，或前端用 PDF.js/PDFObject 渲染 |
| postMessage 收不到消息 | targetOrigin 或 event.origin 校验不通过 | 检查源地址、监听时机和事件参数 |
| 爬虫抓不到 iframe 内容 | requests 不加载子文档 | 用 Playwright/Selenium 渲染，再读取 frame |
| 页面被 iframe 内部跳转走了 | 未设置 sandbox 限制导航 | 加 sandbox 属性，禁止 top-navigation |
这张表是我平时排查问题的起点。遇到 iframe 相关症状，先对照表格缩小范围，再深入查具体原因。
7.2 我在实战中反复踩过的几个细节坑
第一，不要迷信scrolling="no"。这个属性在老浏览器里有用，但在现代浏览器里，尤其当浏览器以独立文档方式渲染 iframe 内容时，控制权实际在子文档 CSS 手里。隐藏滚动条的正确姿势是“同源改内部样式”或“跨域合作约束”，其他方法只能在边缘场景里碰碰运气。
第二，postMessage的targetOrigin一定不要图省事写成*。我在一个分享项目里就见过某团队把目标源写成了*，结果页面被一个第三方广告 iframe 钻了空子，利用消息接口篡改了部分展示数据。虽然没造成严重损失，但排查起来非常被动。接收方一定要校验event.origin，发送方一定要写明确的目标源。
第三，动态创建 iframe 后一定要管理生命周期。很多系统在弹窗里嵌报表，关闭弹窗只隐藏弹窗、不销毁 iframe，时间一久页面里堆了十几个隐藏 iframe，每个都在维持网络连接和内存资源，页面越来越卡。我的习惯是关闭弹窗时主动移除 iframe 节点，再调用一次iframe.src = 'about:blank'断开连接，最后把变量置空。
第四，处理 Scrapy 加 Playwright 的 iframe 抓取时，等待策略比 selector 更关键。iframe 标签出现不代表内部内容可用，一定要在读取前确认子文档已加载，否则会出现很诡异的“时好时坏”现象。我建议在正式抓取前先手工打开页面观察加载链路：父页面请求了哪些接口，iframe 的 src 何时被写入，iframe 内部又请求了哪些接口，把这套链路梳理清楚，代码写起来才有底。
第五，PDF 预览不要试图用一个方案通吃所有端。桌面端 iframe 就够了，Android 端优先检查响应头，iOS 或复杂需求直接用 PDF.js。追求“完美跨端”只会让你陷入无底洞，不如按平台拆分处理逻辑，稳扎稳打。
最后再分享一个我常用的调试思路：遇到 iframe 相关的问题，先在控制台敲一遍document.querySelectorAll('iframe')，再逐个查看frame.contentWindow和对外层响应体的网络请求，很快就能定位问题是出在加载链路、安全策略还是样式控制上。iframe 虽老，但用它其实就是三件事：隔离好双方环境、约定好通信规则、控制好加载与销毁时机，把这三件事做好，大多数 iframe 坑都能绕过去。