iframe 无法真正实现与父页面滚动同步，本质是浏览器安全隔离所致；同源时可通过 scroll 监听 + postmessage + scrollto 模拟，需防抖；跨域时仅能依赖子页面主动配合；替代方案是 fetch 加载 html 到 div 中。
iframe 内容随父页面滚动同步滚动，本质是做不到的
浏览器出于安全和架构隔离设计，iframe 与父页面默认处于独立的渲染上下文和滚动容器中。父页面的 window.scrollY 变化不会自动触发子页面滚动，也没有原生 API 能让父页面“接管”子页面的滚动行为。所谓“同步滚动”，只能靠手动监听 + 主动控制实现，且受限于跨域策略。
同源 iframe 下可用 scroll event + postMessage 模拟同步
前提是子页面与父页面同源（协议、域名、端口完全一致），否则 contentWindow 不可访问，postMessage 也收不到响应。
- 父页面监听自身滚动：
window.addEventListener('scroll', () => { ... })，读取window.scrollY - 通过
iframe.contentWindow.postMessage({ type: 'syncScroll', y: window.scrollY }, '*')向子页面发指令 - 子页面监听
message事件，收到后执行window.scrollTo(0, data.y) - 注意加防抖：高频 scroll 会大量触发，建议用
requestAnimationFrame或简单节流（如 16ms 间隔）
跨域 iframe 完全无法直接控制滚动位置
如果子页面来自不同源，父页面对 iframe.contentWindow 的任何读写操作（包括 scrollTo、document.body.scrollTop）都会抛出 DOMException: Blocked a frame from accessing a cross-origin frame 错误。
- 唯一可行路径是子页面主动配合：它自己监听
message，并暴露一个受信的滚动接口（比如只响应特定 origin 和固定格式消息） - 父页面仍可发
postMessage，但子页面是否执行、如何执行，完全由它自己决定 —— 这不是“父控子”，而是“子愿配合” - 没有子页面代码修改权限时，此方案不可行
替代思路：避免 iframe，改用 CSS 容器 + fetch 渲染
若目标只是“视觉上像 iframe 一样嵌入内容，又想统一滚动”，更可控的方式是放弃 iframe，改用普通 <div> 容器 + <code>fetch 加载 HTML 片段（同源前提下）。
- 用
fetch('/path/to/content.html').then(r => r.text()).then(html => container.innerHTML = html) - 加载的内容成为父文档 DOM 的一部分，天然共享滚动上下文
- 需自行处理脚本执行（
<script></script>标签默认不运行）、样式隔离（可能污染全局）等问题 - 适合内容可控、无需强沙箱隔离的场景；不适合嵌入第三方页面或需要 JS 沙箱的场合
