结论是：position: sticky 失效主因是缺乏可滚动的最近祖先容器或被 transform/filter/overflow:hidden 等属性隐式禁用；必须显式设置 top/bottom 且确保该容器有高度、溢出内容及滚动能力。
直接说结论：用 position: sticky 实现响应式粘性导航，关键不在“加不加样式”，而在于“它有没有可滚动的父容器”和“是否被其他 CSS 规则悄悄禁用”。多数失败案例，都是因为元素被包在了没有高度约束或没有滚动行为的容器里。
为什么 position: sticky 加了却没反应？
不是浏览器不支持（2026 年主流浏览器已全量支持），而是 sticky 的生效有硬性前提：
-
top或bottom必须显式设置（比如top: 0），且只能指定一个方向；left/right在滚动方向为垂直时无效 - 粘性元素的**最近滚动祖先容器**必须有明确的高度 + 可滚动内容（即
overflow-y: auto或scroll，且内容高度 > 容器高度） - 如果粘性元素是其父容器内唯一子元素，且父容器高度刚好等于它自身高度，sticky 会失效——它没“空间”可粘
- 父容器若设置了
transform、filter、will-change或perspective，会创建新的层叠上下文，直接中断 sticky 行为
移动端底部导航栏用 bottom: 0 失效的真相
iOS Safari 直到 15.4 才稳定支持 bottom 方向的 sticky，旧版本会静默降级为 static。更隐蔽的问题是：
-
body默认不撑满视口，height: 100vh必须同时加在html和body上，否则子容器无法继承足够高度 - 底部导航不能直接放在
body下指望它 sticky 到底——它需要一个“滚动上下文”，而整个页面的滚动通常发生在body，但body自身不是 sticky 的合法容器（规范限制） - 正确结构应是：
<main class="scroll-container">…</main>+<nav class="bottom-nav">…</nav>，其中.scroll-container设height: calc(100vh - 60px)+overflow-y: auto，.bottom-nav的父级（如body）设height: 100vh
哪些 CSS 属性会偷偷让 sticky 失效？
这些写法看着无害，实则直接切断 sticky 逻辑：
立即学习“前端免费学习笔记（深入）”；
-
overflow: hidden或clip-path在粘性元素或其任意祖先上 —— 粘性容器被裁剪后，浏览器判定“无滚动空间” -
-webkit-overflow-scrolling: touch（iOS 旧版遗留）—— 已废弃，但若存在，会强制 sticky 退化 -
float、clear或display: table在粘性元素自身上 —— 破坏其参与块格式化上下文的方式 - 父容器用了
contain: layout或contain: paint—— 限制了渲染边界，sticky 无法跨出该范围计算位置
真正容易被忽略的是：sticky 的“粘性区域”永远只在其最近的、具备滚动能力的祖先容器内生效。哪怕页面滚到底，只要那个容器本身没滚动，sticky 元素就一步不会动——它不认 window 或 document，只认自己的父容器。
