fixed元素被遮挡本质是祖先元素创建了层叠上下文，导致其z-index仅在局部生效；需排查并移除opacity、transform、filter等触发属性，或提升父容器层级。
fixed 元素被遮挡，本质是层叠上下文搞的鬼
固定定位的底部悬浮条（比如 footer）明明写了 position: fixed; bottom: 0;，却看不见或被盖住，90% 的情况不是它没渲染，而是被其他元素的层叠上下文压在了下面。CSS 中，position: relative、position: absolute、position: fixed、transform、filter、will-change 等属性一旦出现在某个父容器上，就可能创建新的层叠上下文——而这个上下文里的子元素，z-index 是跟父级比的，不是跟全局比的。
给悬浮条加 z-index 不够，必须确认它不在低层级上下文中
只写 footer { position: fixed; bottom: 0; z-index: 1000; } 很可能无效。关键要看它的父级或同级块有没有悄悄创建更高层级的上下文：
- 检查所有包裹
footer的祖先容器（尤其是body直接子元素），是否带position: relative或transform—— 比如常见的全屏.section、.feature类名元素，常被误加position: relative仅为了内部absolute定位，结果意外创建了新层叠上下文 - 如果确实需要保留那个
position: relative（比如用于伪元素或动画），那就不能只靠footer自己设z-index，得让它的父容器也参与层级竞争：给footer的直接父级（通常是body）显式设一个z-index，并确保它是定位元素（position: relative或static都行，但需配合z-index才能形成根层叠上下文） - 更稳妥的做法是移除冗余的
position: relative：如果某个.section只是为了撑高或背景图，完全不需要定位，就直接删掉那一行 —— 这比硬调z-index更干净、更少副作用
移动端和 Safari 特别容易翻车的两个点
iOS Safari 对 fixed 元素的层叠行为更敏感，尤其在键盘弹出、地址栏收放时，容易触发视口缩放或重绘异常，导致悬浮条错位或被压：
- 不要在
footer内放<input>或<textarea></textarea>—— 键盘唤起后，Safari 可能强行把 fixed 元素“钉”在错误位置，且无法通过 CSS 修复 - 避免给
body加transform或will-change，哪怕只是will-change: transform，也会在 iOS 上创建独立层叠上下文，让footer的z-index失效 - 若必须兼容旧版 Safari（≤ iOS 12），可临时加
body { -webkit-overflow-scrolling: touch; }，但注意这会启用原生滚动，可能影响自定义滚动逻辑
为什么用 position: sticky 不适合底部悬浮条
position: sticky 的 bottom 行为支持极差：Chrome 和 Firefox 基本不支持 sticky 在底部生效（只认 top），Safari 虽然部分支持 bottom，但要求父容器高度严格受限，且极易被 overflow 或 transform 干扰。所以底部悬浮条必须用 fixed，别试图用 sticky 替代——这不是兼容性问题，是规范层面的限制。
立即学习“前端免费学习笔记（深入）”；
