position: sticky 失效主因是祖先元素 overflow: hidden/auto/scroll 静默截断滚动上下文，导致浏览器将其降级为 static；需用 DevTools 逐级检查 computed overflow 值，优先以 clip-path: inset(0) 替代 overflow:hidden 修复。
position: sticky 元素本身可以设 overflow: hidden，但问题通常出在它的祖先元素上——只要任意上级容器设置了 overflow: hidden、overflow: auto 或 overflow: scroll，且该容器自身不可滚动，sticky 就会静默退化为 position: static。
这不是浏览器 bug，是 CSS 规范行为：sticky 必须锚定在一个「可滚动的块级包含块」里才能触发；而 overflow: hidden 等值会强制创建新包含块和滚动上下文边界，同时又不提供滚动能力，导致浏览器判定“这里没滚动，sticky 没意义”，直接跳过粘性逻辑。
怎么确认是不是 overflow 搞的鬼
别靠猜，用 DevTools 实锤：
- 选中你的
sticky元素，在「Computed」面板里看position的最终值 —— 如果是static，说明已被降级 - 在左侧 DOM 树中，从该元素开始逐级点击
parentElement，直到body，每点一层都盯紧overflow-x和overflow-y的 computed 值 - 重点标记出值为
hidden、auto或scroll的节点，尤其是那些height固定但内容明显没撑开的容器（比如height: 400px但子项总高才200px） - 临时给可疑父级加
overflow: visible !important，如果sticky立刻恢复，就锁定了问题层
为什么 overflow: auto/scroll 也一样危险
overflow: auto 和 scroll 同样会创建新滚动上下文，但 sticky 行为会被锚定在这个局部容器内，而不是整个视口。结果常是：
立即学习“前端免费学习笔记（深入）”；
- 元素只在那个容器内部“粘”，一旦滚动超出容器边界，立刻掉回文档流
- 容器本身没真正滚动（比如内容刚好填满、或被
height: 100%压扁），浏览器可能判定“不可滚动”，sticky 就不会触发 - 用鼠标滚轮直接对该容器滚动，如果不响应，说明它根本没形成有效滚动上下文
- 在 DevTools 的 Layout 面板里检查该容器的 “Actual height” 是否真大于设定高度
不删 overflow: hidden 怎么救活 sticky
业务上常需要 overflow: hidden 来裁剪圆角图片、防止弹窗穿出、或配合动画效果，硬删会破 UI。绕过比硬改更稳妥：
- 优先用
clip-path: inset(0)替代overflow: hidden：视觉裁剪效果一致，但不创建新 BFC、不干扰滚动上下文，sticky行为 100% 保留（Chrome 93+、Firefox 97+、Safari 15.4+ 支持） - 把
sticky元素提一层：在带overflow的容器外，套一个position: relative的 wrapper，再把sticky元素挂进去 - 极端情况（DOM 完全锁死、比如第三方组件无法改结构），可用
position: fixed+getBoundingClientRect()监听 scroll 模拟，但要注意 iOS Safari 的滚动抖动和节流处理
最易被忽略的是：失效层级往往不在直接父级，而在爷爷级甚至更高；transform、filter、will-change 这类属性也会切断粘性，但它们不体现在 overflow 上，得一并排查。
