background-attachment: fixed 在移动端不可直接使用，因 iOS Safari 和安卓 WebView 主动禁用该属性以保障滚动性能，即使代码正确也会静默降级为 scroll；桌面端需满足 min-height: 100vh、无 transform/overflow: hidden 父容器等条件才可能生效。
background-attachment: fixed 能不能直接用
能，但只适合静态背景图、且明确不支持 iOS 的场景。它不是“不能写”，而是写了大概率在 iPhone 上不动——这不是你代码错，是 WebKit 主动禁用该行为。
常见错误现象：background-attachment: fixed 写对了，min-height: 100vh 也加了，但真机一滑就失效；或者只在首次加载闪一下，之后完全卡死。
- 必须给容器设
min-height: 100vh（不能用height: auto） - 禁止嵌套在
overflow: hidden或position: sticky父级里 - iOS Safari 需额外加
-webkit-background-attachment: fixed，但仍不稳定 - 如果父容器有
transform（哪怕只是translateZ(0)），整个 fixed 就被降级
用 JavaScript 做视差时 scroll 事件怎么监听才不卡
直接写 window.addEventListener('scroll', handler) 是最常见也最危险的写法——iOS 和 Android Chrome 会强制同步执行，滚动立刻变卡，甚至白屏。
正确做法是加 { passive: true }，告诉浏览器这个监听器不会调用 preventDefault()，从而允许异步处理。
立即学习“前端免费学习笔记（深入）”；
- 错误写法：
window.addEventListener('scroll', handleScroll) - 正确写法：
window.addEventListener('scroll', handleScroll, { passive: true }) - 千万别在回调里直接改
element.style.top或margin-top，会触发重排，卡顿明显 - 位移必须用
transform: translateY()，它走 GPU 加速，滚动才顺
requestAnimationFrame 怎么包一层就解决掉帧问题
核心不是“算得准”，而是“别每滚一像素就算一次”。scroll 事件每秒可能触发上百次，但屏幕刷新率通常只有 60fps。直接在里面更新样式，等于让浏览器反复重绘，低端机直接掉帧。
用 requestAnimationFrame 的本质，是把所有视差计算攒到下一帧统一执行，避免高频干扰渲染主线程。
- 先缓存
window.scrollY到变量里，不要在 rAF 回调里再读 - 每个视差元素用
data-speed="0.3"控制系数，越小越“远” - 更新样式前，确保元素已设
will-change: transform或transform: translateZ(0)，否则首帧易撕裂 - 元素需有
position: relative或position: absolute，否则transform可能不生效
为什么 getBoundingClientRect() 比 window.scrollY 更可靠
单纯依赖 window.scrollY 在嵌套滚动、响应式布局或局部容器中容易偏移失真；而 getBoundingClientRect().top 是元素相对于当前视口的真实位置，适配性更强。
尤其当你做“进入视口才启动视差”的懒加载逻辑时，这个值是唯一可信的锚点。
- 报错
Cannot read property 'top' of null？说明document.querySelector拿不到元素——要么 DOM 还没加载完，要么选择器写错了 - 修复方式：把初始化逻辑放在
DOMContentLoaded事件里，或用IntersectionObserver触发后才启动 -
getBoundingClientRect()在overflow: hidden或transform父容器内依然准确，但要确认父级没裁剪子元素渲染区域 - 计算偏移量推荐公式：
(window.innerHeight - el.getBoundingClientRect().top) / window.innerHeight * maxOffset
真正难的不是写几行 JS，而是判断什么时候该用 CSS、什么时候必须上 JS，以及如何让 iOS 不抖、安卓不卡、Chrome 不闪——这些细节不踩一遍坑，很难凭直觉绕过去。
