overflow:hidden 会使 sticky 退化为 static，因其创建了新的滚动上下文边界但自身不可滚动，导致 sticky 失去锚定条件；需用 devtools 逐级检查 overflow 值并用 clip-path 替代或外层包裹 relative 容器来修复。
因为 overflow: hidden（以及 auto、scroll）会创建新的包含块和滚动上下文边界，而 position: sticky 必须锚定在一个“可滚动的块级容器”内才能触发；一旦该容器自身不滚动，浏览器就直接把它当“死区”，把 sticky 元素降级为 position: static——不是卡住，是压根没启动。
为什么 overflow:hidden 会让 sticky 彻底退化为 static
sticky 的定位逻辑不依赖视口，而是依赖“最近的、内容可溢出且实际在滚动（或具备滚动能力）的块级祖先”。overflow: hidden 虽然禁止了滚动条，但它仍会强制创建一个新的块格式化上下文（BFC）和滚动容器边界。只要这个祖先存在，sticky 就被锁死在这个容器内部；如果它高度固定、内容未撑开、或被 height: 100vh 截断，那它就“不可滚动”，sticky 就失去触发条件。
常见现象：top: 0 声明存在，DevTools 的 Styles 面板也显示它，但 Computed 面板里 position 直接是 static；滚动时元素完全随文档流移动，毫无吸附感。
- 这不是 bug，是 CSS 规范行为：浏览器认为“这个容器不滚，sticky 就没意义”
- 失效层级常不在直接父级，而在爷爷级甚至更高层——比如
.ant-modal外层 wrapper、.card根节点、Tab 切换容器 - CSS-in-JS 或 UI 框架常在运行时悄悄注入
overflow: hidden（防圆角穿出、裁动画），你根本看不到源码里写了它
怎么快速定位是哪一层 overflow 在作怪
别猜，用 DevTools 实锤：
- 选中 sticky 元素 → 打开「Computed」面板 → 看
position是否始终为static - 逐级点击左侧 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：视觉裁剪效果一致，但不创建新包含块、不干扰滚动上下文，sticky 行为 100% 保留 - 若必须保留
overflow: auto（如弹窗内局部滚动表格），就在该容器外再套一层<div style="position: relative">，把 sticky 元素挂进去 <li>慎用 <code>position: fixed + JS模拟：iOS Safari 滚动抖动、视口缩放、节流处理不到位都会导致跳帧或错位，仅作兜底 -
top、bottom、left或right必须显式设置且不能是auto——只写position: sticky等于没写 - 父容器不能是
display: inline-flex或display: inline-grid：它们不产生块格式化上下文（BFC），sticky 锚定无据可依 - 父容器高度 ≤ sticky 元素自身高度时，浏览器算不出“粘住”的边界；可尝试加
min-height: 1px或确保其有真实滚动空间
其他容易被忽略的硬性前提
即使 overflow 没问题，sticky 仍可能哑火：
最常被忽略的是：失效往往不在你写的那层 DOM，而在框架注入的 wrapper 上；检查路径必须从 sticky 元素一路向上捅到 ，少一层都可能漏掉真凶。
