fixed元素失效主因是祖先元素创建新包含块：transform/filter/opacity<1/will-change会使其相对祖先而非视口定位；z-index失效因跨层叠上下文；iOS Safari存在渲染降级问题；宽度应优先用100vw或left/right:0确保贴边。
fixed 元素脱离文档流后，父容器的 transform 会让它失效
这是最常被忽略的坑：只要某个祖先元素设置了 transform、filter、opacity（小于 1）、will-change 等属性，就会创建新的层叠上下文和包含块，导致 position: fixed 不再相对于视口定位，而是相对于这个祖先元素定位。
常见现象：fixed 元素跟着滚动、位置偏移、甚至消失不见。
- 检查 DOM 树中所有父级，用浏览器开发者工具看 computed styles，重点找
transform: translateX(0)这类“看似无害”的声明 - 临时移除可疑父元素的
transform或加transform: none !important验证是否是它导致的 - 真需要父容器动效又得用
fixed？改用position: sticky（支持滚动锚点）或 JS 监听scroll+position: absolute模拟（慎用，性能敏感）
fixed 元素遮挡内容时，z-index 不生效的典型原因
z-index 对 fixed 元素有效，但前提是它和目标元素处于同一层叠上下文。如果目标内容在另一个有 z-index 的祖先里，而该祖先层级更低，那再大的 z-index 也压不住。
常见错误：header { position: fixed; z-index: 9999; }，但页面主体有个 main { position: relative; z-index: 10000; } —— 实际上 main 的层叠上下文覆盖了整个内容区，header 反而被盖住。
立即学习“前端免费学习笔记（深入）”；
- 用开发者工具的 Layers 面板或 Elements → Styles → Computed 查看「Stacking Context」层级
- 避免在非必要容器上设
z-index；真正需要分层的地方，统一用一个根级容器控制层级范围 -
fixed元素建议直接挂到<body>下，减少嵌套带来的上下文干扰
移动端 fixed 元素在 iOS Safari 中“粘滞”或抖动
iOS Safari 对 position: fixed 的实现有历史遗留问题：键盘弹出、地址栏收起/展开、页面缩放时，fixed 元素会错位、闪烁甚至卡住不动。
这不是 bug，是渲染机制限制：Safari 为节省资源，会在某些交互中临时将 fixed 元素降级为 absolute 定位。
- 避免在输入框聚焦时依赖
fixed布局（比如“悬浮提交按钮”）；改用position: sticky或 JS 动态切换定位方式 - 给
fixed元素加backface-visibility: hidden和transform: translateZ(0)可缓解部分抖动（触发硬件加速） - 测试必须真机跑 iOS Safari，模拟器无法复现真实表现
fixed 元素宽度撑满视口却漏掉滚动条宽度
当页面内容高度超过视口、出现垂直滚动条时，width: 100% 的 fixed 元素默认按“含滚动条宽度”的视口计算，导致右侧被滚动条遮住或留白。
本质是 CSS 视口宽度定义模糊：100vw 包含滚动条，100% 在 fixed 下行为不一致。
- 用
width: 100vw替代width: 100%，更可靠 - 如果需完全贴边不留缝，加
right: 0+left: 0，比仅靠 width 更稳 - 极端情况（如禁用滚动条），可读取
document.documentElement.clientWidth动态设 width，但通常没必要
fixed 的真正难点从来不在写法，而在它和页面其他机制的隐式耦合——transform、z-index 层级、移动端渲染策略、滚动条存在与否，任何一个都可能让“固定”变成“飘忽”。动手前先查祖先样式和运行环境，比反复调 top 值有用得多。
