position: fixed 在 iframe 中并非失效，而是严格按规范固定于 iframe 自身 contentdocument 视口；100vh 无效因其不改变 iframe 内部定位基准，真实解法是子页改 absolute + 父页 postmessage 同步滚动/视口数据 + requestanimationframe 动态重算位置。
position: fixed 在 iframe 子页面中不是“异常”，而是完全按规范工作——它固定在 iframe 自身的 contentDocument 视口上，与父页面滚动、缩放、地址栏收起等状态毫无关系。
为什么 100vh 或 height: 100% 根本不解决问题
给 iframe 的父容器设 height: 100vh 只会让 iframe 框看起来“满屏”，但内部 position: fixed 元素仍只相对于这个框定位。一旦父页面滚动，该元素就卡在 iframe 框内不动，视觉上像消失或错位。Chrome DevTools 中查看 getBoundingClientRect() 会发现 top 始终以 iframe 边框为原点，和 window.innerHeight 无关。
- 这不是 CSS 写错了，是浏览器沙箱强制隔离的结果
- 同源 iframe 和跨域 iframe 行为一致，和
sandbox属性也无直接关系 - 试图靠
transform、overflow或父级zoom“修复”，只会掩盖真实坐标系问题，后续滚动逻辑更难调试
iOS 微信和 Safari 中表现更糟的真实原因
iOS 系统级视口变化（软键盘弹出、地址栏收起、页面缩放）会动态改变 iframe 的 contentDocument 视口尺寸，但 position: fixed 不响应这些变化——它只绑定初始渲染时的 iframe 视口快照。结果就是底部菜单“卡在内容末尾”而非“钉在屏幕底边”。
- Android 微信有时“看起来正常”，是因为其 WebView 对 iframe 视口更新更宽松，但不可依赖
- 不能只监听
scroll，必须同时监听resize并重新计算innerHeight和scrollLeft - 直接在
message回调里改element.style.top会导致跳变；必须用requestAnimationFrame统一更新
postMessage + absolute 是唯一可控路径
放弃“纯 CSS 修复”的幻想。真正能稳定模拟 fixed 行为的，是把子页面元素改为 position: absolute，再由父页面通过 postMessage 主动推送滚动与视口状态，子页面用 requestAnimationFrame 动态重算位置。
- 父页面发送结构必须含
scrollTop、scrollLeft、innerHeight、innerWidth，仅scrollTop不足以支撑底部固定 - 子页面收到消息后，先存进变量，不在
message回调中直接操作 DOM - 跨域时
event.origin校验不是可选项：需兼容 http/https、支持白名单数组、e.data必须JSON.parse()并try-catch - 最关键却最常被忽略的一点：子页面
document.body必须是该元素的 containing block，且不能有position: relative的干扰祖先
真正难的不是写通通信，而是让 position: absolute 元素在 iOS 键盘弹出、Android 导航栏切换、Chrome 地址栏折叠等所有视口突变场景下，依然稳住坐标——这要求每帧都基于最新视口尺寸重算，而不是依赖一次初始化。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
