position: sticky 在父容器不生效的主因是祖先元素存在 overflow: hidden、transform 等创建新层叠上下文的属性；必须配合 top/bottom 使用；ios safari 下需避免 height: 100vh 并考虑兼容 fallback。
position: sticky 为什么在父容器里不生效
常见错误现象是给 header 加了 position: sticky 和 top: 0，但滚动时完全不动。根本原因不是 CSS 写错了，而是父元素有 overflow: hidden、transform、will-change 或 contain 这类属性——它们会创建新的层叠上下文或格式化上下文，直接禁用 sticky 行为。
使用场景：适合页面主体流式布局，需要导航随内容自然进入视口再固定。
- 检查所有祖先元素，特别是直接父容器，删掉或临时注释掉
overflow、transform类样式 -
sticky必须配合top（或bottom）才起作用，只写position: sticky没效果 - 兼容性上，IE 完全不支持，iOS Safari 12.2+ 才稳定支持，如需兼容老版本 iOS，得降级方案
fixed 布局后页面内容突然上移遮挡导航
这是最常被忽略的副作用：当 position: fixed 把导航从文档流中抽走，后续内容会立刻“顶上来”，导致首屏文字被盖住。这不是 bug，是预期行为。
使用场景：适合需要绝对控制定位、跨路由/SPA 全局复用、或必须脱离文档流的复杂交互（比如带阴影/缩放的悬浮导航）。
- 必须手动给
body或紧接在导航后的容器加padding-top或margin-top，值等于导航高度 - 如果导航高度动态变化（比如响应式折叠、多行标题），用
padding-top比margin-top更稳妥，避免 margin 合并问题 - 注意
fixed元素默认以 viewport 为参考系，若父容器有transform，部分旧版 Chrome 会错误地以该容器为参考，需加transform: translateZ(0)修复
sticky 和 fixed 在滚动性能上的真实差异
很多人以为 sticky 性能更好，其实两者在现代浏览器中都触发合成层，性能差距微乎其微。真正影响性能的是「是否频繁重排」和「是否强制重绘」。
-
sticky在粘住/释放瞬间会触发 layout，如果导航内有频繁变动的宽度（比如搜索框自动伸缩），可能引起卡顿 -
fixed一旦固定，就不再参与文档流计算，但若监听scroll做 class 切换（如缩小 logo），仍可能触发重排 - 更轻量的做法是用
IntersectionObserver替代 scroll 监听判断是否到达顶部，避免主线程阻塞
移动端 iOS Safari 下 sticky 失效的隐藏条件
即使满足所有规范，iOS Safari 仍可能让 sticky 不工作——常见于页面设置了 height: 100vh 或 min-height: 100vh 的容器，且内容不足一屏时。Safari 会错误判定“无滚动空间”，从而跳过 sticky 计算。
- 临时解决：给 body 加
min-height: 100.1vh，制造微小溢出 - 根治方法：避免对
html或body设height: 100vh，改用flex布局 +flex: 1控制主区域高度 - 不要依赖
position: sticky实现关键导航功能，尤其金融、表单类页面，建议 fallback 到fixed+ JS 监听
实际项目里，sticky 看似简单，但它的行为高度依赖祖先节点的渲染上下文；而 fixed 虽可控，却要求你精确管理留白和响应式高度。选哪个，取决于你愿不愿意为那 5% 的边界 case 多写三行 JS 逻辑。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
