fixed元素随滚动移动是因为祖先元素设置了perspective、transform、filter、opacity
fixed元素随滚动移动？先查perspective和transform
它不是bug，是CSS规范明确规定的退化行为：只要某个祖先元素设置了perspective、transform、filter或opacity（小于1），就会创建新的包含块（containing block），导致position: fixed不再锚定视口，而是降级为相对该祖先定位。
常见现象包括：导航栏跟着内容下滚、返回按钮在滚动中“掉下去”、底部工具栏错位到页面中部。这不是浏览器兼容性问题，所有现代浏览器（Chrome/Firefox/Safari/Edge）都严格遵循该规则。
- 用开发者工具逐级展开DOM，选中fixed元素，在Styles面板中点击“Computed”，往上翻看每个父级的
transform、perspective、filter是否非none或默认值 - 临时给可疑父容器加
transform: none !important或filter: none !important，刷新观察fixed是否恢复——这是最快验证方式 - 特别注意
body或html上看似无害的transform: translateZ(0)，它常被用来触发硬件加速，却会全局破坏所有fixed定位
为什么will-change也会让fixed失效
will-change: transform本身不直接改变布局，但它会提前为元素创建独立图层，间接影响其层叠上下文边界。一旦父级因will-change形成新包含块，fixed元素就自动“认这个父级当爹”，不再认视口。
这种失效更隐蔽，因为开发者工具里看不到显式transform或perspective声明，只在Computed中能看到will-change值生效，且“Containing Block”一栏已指向该父容器而非viewport。
- 检查fixed元素的父级、祖父级是否设置了
will-change: transform、will-change: opacity等 - 不要对整个
body设will-change；如需优化动画性能，改用contain: layout paint，副作用更可控 - 若必须保留父级
will-change，可将fixed元素移出该结构，直接挂载到document.body下（用JS动态appendChild）
iOS Safari中fixed抖动，不一定是perspective的问题
在iOS Safari里，即使DOM树干净、没任何transform/perspective，fixed元素仍可能在滚动、软键盘弹出、地址栏收起时短暂错位或闪烁。这不是定位失效，而是渲染层临时降级：Safari为节省内存，会在某些交互中把fixed元素当作position: absolute处理。
此时getBoundingClientRect()返回的top值会突变，但DOM上position仍是fixed。单纯检查perspective毫无意义。
- 真机测试必不可少——模拟器无法复现该行为
- 避免在
input聚焦时依赖fixed布局（如悬浮提交按钮），改用position: sticky或监听focusin/resize事件做位置重置 - 加
backface-visibility: hidden和transform: translateZ(0)可缓解部分抖动（强制走合成层），但不能根治
修复后还要防width: 100%覆盖滚动条
即使fixed回归视口定位，width: 100%仍会撑满整个视口宽度，无视垂直滚动条占用的空间。结果就是右侧15–17px被遮挡，用户点不到滚动条，甚至误触fixed区域。
这不是定位问题，是尺寸计算偏差。Windows系统下滚动条始终可见，而fixed元素不参与文档流，不会自动避让。
- 不用JS测滚动条宽度，直接写
right: 15px+left: 0，再配合width: calc(100vw - 15px)更稳妥 - 更通用方案：
left: 0; right: 0;代替width: 100%，它会自动扣除滚动条宽度（前提是父级没overflow:hidden） - 若需全宽但又不想遮滚动条，用
width: 100vw并确保body无横向溢出（避免双滚动条）
perspective只是表象，真正要盯住的是“谁创建了包含块”。DOM层级、层叠上下文、移动端渲染策略，三者叠加才构成fixed失效的完整链条。漏掉任意一环，修复都只是暂时的。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
