视差滚动需用滚动监听+transform而非background-attachment:fixed；推荐getboundingclientrect()计算偏移、requestanimationframe节流、will-change:transform提示合成，并避免与position:sticky共存。
视差滚动不是靠 background-attachment: fixed 就能搞定的
这个 CSS 属性在移动端基本失效，iOS Safari 会忽略它，安卓部分 WebView 也会降级处理。真正在现代页面中稳定实现视差效果，得靠滚动监听 + transform: translateY() 动态偏移，或者用 IntersectionObserver 配合 requestAnimationFrame 控制帧率。
- 别把
background-attachment: fixed当主力方案，它只适合简单背景图、且明确不支持移动端的场景 - 用
transform而不是top或margin-top做位移——前者走 GPU 加速，滚动更顺；后者触发布局重排，卡顿明显 - 监听
scroll事件必须节流，建议用requestAnimationFrame包一层，否则快速滚动时容易丢帧
用 getBoundingClientRect() 算视差偏移量最可控
比起单纯依赖 window.scrollY，用元素自身相对于视口的位置来算偏移，能更好适配不同屏幕高度、嵌套滚动容器，也方便做「进入视口才启动」的懒加载逻辑。
- 对每个要视差的元素，取
el.getBoundingClientRect().top，再结合window.innerHeight算出当前可视比例（比如(window.innerHeight - top) / window.innerHeight） - 把这个比例乘上你设定的最大偏移量（如
100px），就是当前该元素的translateY值 - 注意：如果父容器有
overflow: hidden或transform，getBoundingClientRect()的结果仍准确，但需确认父级没截断子元素的渲染区域
用 will-change: transform 提前告诉浏览器要动
视差元素如果数量多或层级深，不加提示的话，浏览器可能来不及准备合成层，导致首帧闪烁或滚动掉帧。
- 在 CSS 中给视差元素加
will-change: transform，但不要滥用——只加在真正需要视差的元素上 - 避免写成
will-change: all，这会让浏览器过度优化，反而增加内存开销 - 如果元素是动态插入的（比如 Ajax 加载后追加），记得 JS 插入后立即设置
style.willChange = 'transform'
移动端 iOS 上 position: sticky 和视差容易打架
如果你在视差区域里混用了 position: sticky 标题或导航条，iOS Safari 可能出现定位错乱、粘性失效、甚至整个视差层抖动。这不是 bug，是 WebKit 对复合层叠加的限制。
- 尽量避免在同一个滚动容器内同时使用
position: sticky和 JS 视差逻辑 - 如果必须共存，把 sticky 元素抽到滚动容器外（比如用
fixed+ 手动计算位置），或改用IntersectionObserver模拟 sticky 行为 - 测试时务必在真机 Safari 上验证，模拟器和 Chrome DevTools 的移动端预览无法复现全部问题
视差滚动真正的难点不在“怎么动”，而在“什么时候不动”——滚动惯性、快速回弹、键盘弹出、横竖屏切换，都会让视差偏移量突然跳变。这些边界情况，比写出第一版动效更花时间调试。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
