fixed元素动画必须用transform替代top/left，否则必触发重排导致卡顿；父级transform/opacity会破坏fixed合成层，需提至body或移除干扰样式。
fixed元素动画别碰top/left，否则重排照常发生
直接给 position: fixed 元素写 top 或 left 动画，浏览器照样触发 layout → paint → composite 全流程，卡顿无法避免。哪怕它已经脱离文档流，top 仍属于布局属性，会强制重排。
常见错误现象：element.style.top = y + 'px' 放在 scroll 回调里，帧率立刻掉到 20fps 以下；用 transition: top 0.3s 也会在首帧卡一下。
- 正确做法：只用
transform: translateY()或translateX()移动 fixed 元素 - 如果已有其他 transform（比如旋转），合并写成
transform: rotate(15deg) translateY(20px)，不要拆成两个transform声明 - 初始状态也建议用
transform而非top/right定位，保持属性一致性
fixed被父级transform/opacity拦住，合成层根本建不起来
position: fixed 理论上会自动提升为合成层，但一旦它的任意一个父容器设置了 transform（非 none）、opacity（小于 1）、filter 或 will-change，就会创建新的堆叠上下文，把 fixed 元素“框死”在该上下文中——它就不再是相对于视口定位，也无法独立合成。
典型场景：整个页面套了个 div#app { transform: translateZ(0); } 做性能优化，结果右下角的 fixed 按钮滚动时疯狂掉帧。
立即学习“前端免费学习笔记（深入）”；
- 检查方式：Chrome DevTools → Rendering → 勾选 “Layer borders”，绿色边框才表示真正独立图层
- 修复办法：要么移除父级干扰属性，要么把 fixed 元素提到
直接子级（如用document.body.appendChild(fixedEl)） - 注意：Vue/React 组件内动态挂载时，也要确保挂载点没受上级 transform 影响
sticky和fixed来回切，图层反复销毁重建更伤性能
监听 scroll 动态改 style.position 在 fixed 和 sticky 之间切换，看着是“智能吸顶”，实则让浏览器反复创建/销毁合成层——这比单纯重绘代价更高，尤其在中低端 Android 设备上明显卡顿。
使用场景：导航栏从 relative → sticky → fixed 的三段式切换，或回到顶部按钮的显隐逻辑。
- 替代方案：统一用
position: sticky+top: 0，配合z-index和父容器overflow: visible（注意 Safari 旧版对overflow: hidden的兼容问题） - 若必须用 fixed，就全程 fixed，靠
transform: translateY()控制显隐（例如transform: translateY(100%)隐藏） - 避免在 scroll 事件里频繁 setAttribute 或 style.position，改用
classList.toggle()+ CSS 类控制
移动端安全区域+fixed，bottom写死等于埋雷
在 iPhone X 及更新机型上，bottom: 20px 会让 fixed 按钮被底部小黑条遮住。这不是渲染问题，但用户点不到，等同于功能失效。
适配方案不是加 JS 判断机型，而是纯 CSS 解决：
- 写成
bottom: max(20px, env(safe-area-inset-bottom)); - 加
@supports (bottom: env(safe-area-inset-bottom))包裹，防止不支持的浏览器解析失败 - 若需 fallback，可叠加
constant(safe-area-inset-bottom)（iOS 11.2 以下） - 注意：env() 不影响合成层，但若同时用了
transform动画，确保两者不冲突（比如不要在同一个 transition 中混用）
fixed 元素的性能陷阱不在“是否固定”，而在“是否真被 GPU 单独处理”。很多问题表面是动画卡，根子是图层没建起来，或者建了又被父级拖垮。检查 Layer borders 是最直接的验证方式，比猜更可靠。
