sticky-top失效主因是祖先元素overflow:hidden/auto/scroll截断滚动上下文，导致sticky退化为static；需用DevTools逐级检查computed overflow值，优先以clip-path:inset(0)替代overflow:hidden修复。
sticky-top 失效是因为父容器 overflow 截断了粘性上下文
直接结论：sticky-top 不是“固定在视口顶部”，它依赖最近的、可滚动的块级祖先作为锚定容器；只要任意祖先（不一定是直接父级）设置了 overflow: hidden、overflow: auto 或 overflow: scroll，浏览器就会把该祖先当作 sticky 的包含块边界——如果这个容器本身不滚动，sticky-top 就会静默退化为 position: static，完全不生效。
哪些 overflow 值会触发失效？不只是 hidden
overflow: hidden 最典型，但 overflow: auto 和 overflow: scroll 同样危险，区别在于它们“看起来能滚动”，实际却常导致 sticky 卡在半路或闪一下就掉回文档流：
-
overflow: hidden：直接切断粘性链，sticky 元素计算值恒为static -
overflow: auto：仅当内容真正溢出并触发滚动条时才可能启用 sticky；若高度刚好、子项被height: 100%压扁，浏览器判定“不可滚动”，sticky 仍不启动 -
overflow: scroll：强制显示滚动条，但若容器无实际滚动行为（如内容未撑高），sticky 依然找不到吸附依据 -
overflow: clip：Chrome 114+ 支持，但和hidden一样会创建新 BFC，同样禁用 sticky
如何快速定位是哪个祖先在作祟？
别猜，用 DevTools 实锤：
- 选中带
sticky-top的元素 → 打开「Computed」面板 → 看position计算值是不是static - 逐级点击左侧 DOM 树中的
parentElement，直到<body>，紧盯每一层的overflow-x和overflow-y计算值 - 临时给可疑节点加
overflow: visible !important，如果sticky-top立刻恢复，问题就坐实了 - 特别注意框架组件外层 wrapper：比如
.ant-modal-root、.card、.tab-pane、Swiper 的.swiper-wrapper，它们常默认带overflow: hidden
不删 overflow 怎么救 sticky-top？
业务上不能随便删 overflow: hidden（比如裁剪圆角图片、防弹窗内容穿出），有更稳妥的绕过方式：
立即学习“前端免费学习笔记（深入）”；
- 用
clip-path: inset(0)替代overflow: hidden：视觉效果一致，但不创建新 BFC，sticky 链完整保留（Chrome 93+、Firefox 97+、Safari 15.4+ 支持） - 把
sticky-top元素提到更高层级：在带overflow的容器外，套一层position: relative的 wrapper，再把导航栏挂进去 - 避免 transform 干扰：哪怕只是
transform: translateZ(0)或 CSS-in-JS 注入的will-change: transform，都会切断粘性上下文，iOS Safari 尤其敏感
