sticky定位在祖先元素设置overflow:hidden/auto/scroll时失效，因浏览器将其降级为static——因这些属性创建新bfc和滚动上下文边界，使sticky失去可锚定的可滚动容器。
sticky 定位在父元素（或任意祖先）设置 overflow: hidden、overflow: auto 或 overflow: scroll 时失效，不是 bug，是规范行为：浏览器直接将该 sticky 元素降级为 position: static，连触发逻辑都不走——你看到的“不吸顶”，其实是它根本没启动。
为什么 overflow 会让 computed position 变成 static
sticky 必须锚定在一个「可滚动的块级容器」上才能工作。而 overflow: hidden（含 auto/scroll）会强制创建新的包含块（BFC）和滚动上下文边界。只要这个祖先自身不可滚动（比如高度固定、内容未撑开、被 height: 100vh 截断），浏览器就判定“这里没滚动空间”，直接跳过 sticky 行为，计算值恒为 static。
常见现象包括：top: 0 写得再全，Computed 面板里 position 就是 static；滚动时元素完全随文档流移动，毫无吸附感。
- 失效层级常不在直接父级，而在爷爷级甚至更高——比如
.ant-modal外层 wrapper、.card根节点、Tab 切换容器 - CSS-in-JS 库可能在运行时悄悄注入
overflow: hidden（如防圆角溢出），源码里根本看不到 -
overflow: clip同样会截断，尽管它不显示滚动条
如何用 DevTools 快速定位哪一层 overflow 在拦路
别靠猜，靠实锤：
- 选中 sticky 元素 → 打开「Computed」面板 → 看
position是否始终为static - 在 Elements 面板左侧 DOM 树中，从该元素开始，逐级点击
parentElement直到 - 每点一层，紧盯
overflow-x和overflow-y的 computed 值，特别留意值为hidden、auto或scroll的节点 - 临时给可疑节点加
overflow: visible !important，如果 sticky 立刻恢复，问题就坐实了
不删 overflow: hidden 怎么保住 sticky 行为
业务上常需要 overflow: hidden 来裁剪圆角、防弹窗穿出或配合动画，硬删会破 UI。绕过比硬改更稳妥：
- 用
clip-path: inset(0)替代overflow: hidden：视觉效果完全一致，但不创建新 BFC，sticky 链完整保留（Chrome 93+、Firefox 97+、Safari 15.4+ 支持） - 避免写成
clip-path: inset(0px)（带单位），部分旧版 Safari 解析不稳定 - 把 sticky 元素提到带
overflow的容器外层：比如在 Modal 外加一个position: relativewrapper，再把 sticky 元素挂进去 - 若 DOM 完全锁死，可用
position: fixed+getBoundingClientRect()监听 scroll 模拟，但要注意 iOS Safari 滚动抖动和节流处理
overflow: auto/scroll 为什么同样危险
overflow: auto 和 overflow: scroll 不是“安全选项”，它们同样会创建新的滚动上下文边界，导致 sticky 锚定错位：
- 如果该容器内容没真正溢出（比如高度刚好、子项被
height: 100%压扁），浏览器可能判定“不可滚动”，sticky 就不会启动 - 即使它能滚动，sticky 也会被锁死在这个局部容器内——表现为只在该区域粘一小段，超出后立刻掉回文档流
- 验证方式：用鼠标滚轮直接对该容器滚动，如果不响应，说明它根本没形成有效滚动上下文
- 在 DevTools 的 Layout 面板里检查该容器的 “Actual height” 是否真大于设定高度
最易被忽略的一点是：iOS Safari 对 sticky 更苛刻，尤其 15.4 之前版本，必须写 position: -webkit-sticky 在前、position: sticky 在后；顺序反了或属性名写错（如 -webkit-position: sticky），整行会被跳过。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
