iframe height抖动源于缩放前尺寸超父容器：170%×650px≈1105px远超可视区，触发overflow:hidden重算导致跳动；应同步降至165%（165%×0.6=99%），优先匹配视觉尺寸与布局约束。
iframe height抖动是因为缩放前尺寸超出了父容器
当iframe用transform: scale(0.6)缩放，同时设width: 170%和height: 170%时，浏览器仍按缩放前的原始尺寸参与布局计算。170% × 父容器高度（比如 650px）≈ 1105px，远超可视区域，触发overflow: hidden裁剪边界重算或滚动锚点偏移，造成视觉跳动。
这不是渲染 bug，而是 CSS 规范行为：transform 不改变文档流，但溢出检测、重排判定全基于缩放前的盒模型尺寸。
- 必须同步调整
width和height，否则缩放后比例失衡，内容拉伸或留白 - 推荐从
165%开始测试：165% × 0.6 = 99%，刚好贴近父容器可用空间（扣除padding-top: 60px后约 590px） - 若仍有轻微跳动，可试
162%或160%——优先选能被 0.6 整除的值，如166.666%（但百分比需为合法 CSS 值，建议四舍五入到小数点后一位）
onload里读scrollHeight不准是常态，不是代码写错了
iframe.onload只表示资源加载完成，不代表 CSS 渲染、字体加载、图片解码、JS 动态内容插入已完成。此时读document.body.scrollHeight大概率偏小，尤其在含 Web Font 或 Vue/React 的页面中。
常见现象是 iframe 高度突然截断，刷新后偶尔正常，但不可靠。
- 优先读
document.documentElement.scrollHeight，它比body.scrollHeight更稳定（兼容 margin 折叠、怪异模式） - 必须加
setTimeout(() => { /* 读高度 */ }, 0)，把读取推到下一轮事件循环，给浏览器留出重排时间 - 如果子页用了
font-display: swap，还得等document.fonts.ready（现代浏览器），否则文字回流会引发二次高度变化 - 务必先设
iframe.style.height = 'auto'再读，避免旧高度干扰计算
跨域 iframe 必须用 postMessage，且 origin 校验不能省略
安卓 WebView 和 iOS WKWebView 对跨域访问极其严格。iframe.contentDocument在跨域时返回null，任何尝试读取都会静默失败或抛SecurityError。唯一可行路径是子页主动发消息，但有硬性前提：
- 子页必须在
window.onload之后发送，而非DOMContentLoaded——否则scrollHeight可能为 0 - 父页接收时，
event.origin必须严格比对协议、域名、端口，不能用'*'；http://和https://不互通 - 子页示例：
window.parent.postMessage({ type: 'iframeHeight', height: document.body.scrollHeight }, 'https://yourdomain.com') - 父页校验写法：
if (event.origin !== 'https://widget.example.com') return
移动端要额外防字体和图片延迟导致的高度错位
移动端 WebView（尤其是 iOS Safari）对渲染时机更敏感。即使加了setTimeout，遇到 Web Font 加载慢或懒加载图片未解码，仍可能拿到错误高度。
关键动作不是“多等几次”，而是分层容错：
- 初始 onload 后用
setTimeout(..., 0)读一次documentElement.scrollHeight - 监听
document.fonts.ready（如有 Web Font） - 对所有
<img>绑定onload，并在全部加载完后再同步一次高度 - 子页
body必须重置：margin: 0; padding: 0;，否则 iOS Safari 默认margin: 8px会多出空白
实际修复中，最常被忽略的是「缩放前尺寸」与「缩放后视觉尺寸」的数值映射关系。很多人调transform参数或改padding，却没意识到问题根源在170%这个数字本身——它不是样式问题，是几何溢出问题。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
