JavaScript通过操作transform和opacity等CSS属性触发GPU硬件加速，避免重排重绘；滚动优化需用passive事件、缓存尺寸、IntersectionObserver检测可见性；动画交由CSS执行，JS仅负责触发与状态管理。
JavaScript 本身不直接“开启”硬件加速，而是通过操作 DOM 和样式，触发浏览器将特定渲染任务交给 GPU 处理。关键在于让 JS 的行为配合浏览器的合成机制——用对属性、避开启重排、减少主线程负担。
优先用 transform 和 opacity 触发 GPU 合成
浏览器只对少数 CSS 属性变更做硬件加速，其中最稳定高效的是 transform（尤其是 translate3d、translateY）和 opacity。JS 修改这些属性时，元素会被提升到独立图层，动画由合成器线程处理，不触发布局（Layout）或绘制（Paint）。
- 滚动容器内元素位移：用
element.style.transform = `translateY(${offset}px)`，而非top或marginTop - 淡入淡出效果：改
opacity，不要用visibility或显隐切换 display - 避免滥用
will-change: transform：仅在动画即将开始前临时添加，动画结束及时移除；全局加或长期保留会创建过多图层，反而拖慢性能
JS 控制滚动时守住性能底线
自定义滚动（如隐藏原生滚动条 + 手动控制 content 位移）必须谨慎。核心原则是：不让 scroll 事件回调成为性能瓶颈。
- 监听 wheel/mousewheel 时，用
{ passive: true }，禁止调用preventDefault()，确保滚动不被 JS 阻塞 - 位移计算用
transform: translate3d(0, ${y}px, 0)，不是top或scrollTop - 边界判断提前缓存容器高度与内容总高，不在每次滚动中重复读取
scrollHeight或offsetHeight - 滚动过程中禁用同步布局读取（如
getBoundingClientRect()），所有依赖尺寸的逻辑移到resize或初始化时缓存
动画交给 CSS，JS 只负责触发
复杂交互动画（如滚动进入视口后淡入上滑）不该在 scroll 回调里用 JS 逐帧写样式，而应采用“JS 判定 + CSS 执行”模式。
立即学习“Java免费学习笔记（深入）”；
- 用
IntersectionObserver替代 scroll 监听来检测元素是否可见，零主线程开销 - 可见时给元素添加类名（如
is-entered），该类名对应预设的@keyframes动画 - CSS 动画定义中只包含
transform和opacity，不写width、height、margin等触发重排的属性 - 动画时间函数推荐
ease-out或cubic-bezier，避免linear在长动画中显得机械
长列表与滚动锚点场景下的轻量干预
当必须用 JS 响应滚动（如吸顶导航、进度条、锚点高亮），要隔离计算、延迟更新、复用结果。
- 吸顶逻辑中，把导航栏
offsetTop、容器scrollTop提前缓存，滚动中只比大小，不重新查位置 - 进度条宽度计算用
requestAnimationFrame包裹，确保更新与刷新率同步，且同一帧内多次触发只执行最后一次 - 锚点滚动用
scrollIntoView({ behavior: 'smooth' })，而不是手动计算并 setInterval 动画 scrollTop —— 浏览器原生实现已启用硬件加速 - 虚拟滚动列表中，JS 只维护可视区域起始索引和偏移量，渲染交给模板，位移全部走
transform
