iframe 中 position: fixed 的参照物是 iframe 自身的 contentDocument 视口，而非主窗口或父页面 body；其行为符合规范，源于浏览器沙箱隔离与独立渲染图层设计。
iframe 里的 position: fixed 不是“失效”，而是完全按规范在工作——它固定在 iframe 自己的视口上，和主窗口无关。这不是 bug，是浏览器沙箱强制隔离的结果。
fixed 在 iframe 中的参照物到底是哪个？
不是主窗口，也不是父页面 body，而是 iframe 元素自身的 contentDocument 视口。只要打开开发者工具，在 iframe 内执行 document.querySelector('.my-fixed-el').getBoundingClientRect()，你会发现 top 和 left 始终相对于 iframe 边框计算，哪怕主页面滚动了几十屏。
这和跨域无关，同域 iframe 也一样；和 sandbox 属性也无直接关系——即使没开 sandbox，行为也不变。根本原因是每个 iframe 都拥有独立的文档、独立的视口、独立的滚动容器。
为什么不能直接用 CSS 把它“钉”到主窗口？
浏览器禁止这么做，出于安全与渲染模型设计：
立即学习“前端免费学习笔记（深入）”；
-
position: fixed的定位容器（containing block）在规范中明确定义为“initial containing block”，对 iframe 来说就是它自己的视口，不是顶层窗口 - 如果允许 iframe 内元素直接锚定主窗口，就等于绕过 iframe 的坐标系隔离，可能被用于 UI 欺骗（比如伪造地址栏、覆盖支付按钮）
- 渲染引擎把 iframe 当作一个独立 compositor 图层处理，它的 fixed 元素被挂载在该图层的根坐标系下，无法跨图层绑定位置
常见“伪修复”方案及其真实代价
有人用 parent.window.addEventListener('scroll', ...) 动态改 top，或靠 postMessage 同步滚动值再用 requestAnimationFrame 更新 position: absolute —— 这些能“看起来像 fixed”，但要注意：
- 滚动事件监听必须加防抖，否则 iOS Safari 下高频触发会卡顿；
requestAnimationFrame要配transform: translateY()才能走合成层，避免重排 - 主窗口缩放、软键盘弹出、地址栏收起都会导致视口尺寸突变，此时仅靠
scrollTop不够，还得监听resize并重新计算视口高度 - 若 iframe 跨域，
parent.window读取scrollTop会抛SecurityError，必须由父页主动postMessage推送状态，且 iframe 需校验event.origin
真正需要 fixed 行为时，更合理的架构选择
与其在 iframe 里硬扛 fixed，不如把需要固定展示的 UI 提到主页面 DOM 中：
- 用
shadow DOM或portal（如支持）做轻量级嵌入，避免 iframe 的视口隔离 - 微前端场景下，让主应用统一管理全局 fixed 区域（如通知栏、操作浮层），子应用只发事件不控制位置
- 广告/分享弹窗类需求，直接由父页提供
showModal()接口，iframe 内只调用，不渲染 DOM
最常被忽略的一点：很多所谓“fixed 失效”的问题，其实根源不在 iframe，而在父页面给 html 或 body 加了 transform: translateZ(0) 或 perspective —— 这会让整个页面创建新 containing block，连主窗口的 fixed 都会退化为相对 body 定位。先检查这个，比折腾 iframe 同步更有效。
