iframe会阻塞主页面onload事件，因浏览器强制等待其所有资源（含图片、CSS、JS）加载执行完毕；修复需动态创建iframe并延迟插入，或使用loading="lazy"属性。
iframe 会阻塞主页面 onload 事件
浏览器必须等 iframe 内所有资源（含图片、CSS、JS）全部加载并执行完，才触发主页面的 window.onload。如果嵌套的是一个带大图的网页，哪怕只是其中一张 img 加载慢或失败，整个父页面右上角转圈就会一直不消失，document.readyState 卡在 interactive 状态。
这不是“可能延迟”，而是强制等待——尤其当嵌套页本身又用了懒加载或第三方图床时，不可控因素成倍增加。
- 修复方式：不用 HTML 中直接写
src，改用 JS 动态创建并插入，确保在DOMContentLoaded后执行 - 更稳妥做法：加
loading="lazy"属性（Chrome 76+、Firefox 85+、Safari 15.4+ 支持），让浏览器自动判断是否在视口内再加载
大图网页嵌套导致双层滚动 + 响应式失效
iframe 是独立文档上下文，它的 CSS 不参与父页面的 flex 或 grid 布局流。即使你给父容器设了 aspect-ratio: 4/3，里面的大图网页仍可能：
- 自带固定宽高或 viewport meta，无视父容器尺寸
- 内部出现横向滚动条（比如图片超宽），而父页又开了纵向滚动，用户要滚两层
- 移动端缩放错乱，因为
iframe无法响应父页的rem或媒体查询变化
常见现象：PC 上看着正常，手机上图片被截断、文字小得看不清、底部留白异常大。
立即学习“前端免费学习笔记（深入）”；
内存与渲染开销翻倍，尤其在低端设备上
每个 iframe 都会创建独立的渲染树、JavaScript 执行上下文和 CSSOM。嵌套一个含多张大图的网页，等于额外启动一套完整页面生命周期：
- Chrome DevTools Memory 面板可明显看到堆内存增长 30%~50%
- 低端 Android 设备上，首次绘制（FP）和首次内容绘制（FCP）延迟常超过 2s
- 若嵌套页还用了 WebP/AVIF 图片解码或 Canvas 渲染，GPU 内存压力会进一步升高
这不是“有点慢”，是直接触发系统级卡顿——滑动掉帧、输入延迟、甚至被 Android 系统判定为“无响应”而杀进程。
title 和 sandbox 缺失会让问题更隐蔽
没设 title 属性时，屏幕阅读器完全不知道这个 iframe 里是什么；不加 sandbox，里面的大图网页若含恶意脚本（比如通过图片 URL 注入 JS），就能调用 top.location.href 劫持整个父页。
- 最小安全配置至少是
sandbox="allow-scripts" - 如果嵌套页需要读取 localStorage 或提交表单，必须显式加
allow-same-origin，且只能配合postMessage通信 -
sandbox=""（空值）最严格，但会导致图片加载失败——因为现代图片加载逻辑普遍依赖 JS
真正难调试的不是报错，而是无声的失败：图片不显示、滚动卡死、SEO 完全丢失、无障碍检测工具直接跳过该区域——这些都不会抛出 console.error，但线上用户天天遇到。
