sticky 定位失效最常见的原因主要有两类：一是祖先元素设置了 overflow:hidden/auto/scroll，从而截断了滚动上下文；二是父级容器使用了 height:100vh、display:contents 等属性，导致缺少有效的定位上下文。排查这类问题时，建议优先通过 Computed 面板检查实际的溢出值，再根据情况改用 clip-path 或 min-height 来修复 sticky 不生效的问题。
大多数情况下，sticky 失效并不是因为类名写错，而是某一层祖先元素在不易察觉的地方截断了滚动上下文，浏览器因此会把它按 position: static 来处理。如果你在 DevTools 的 computed 面板里看到 position 最终显示为 static，这通常就是 sticky 定位失效的明确信号。
父容器设置了 overflow: hidden 或 auto
这是 sticky 失效中最常见、也最容易被忽略的原因之一。只要任意一层祖先元素（即使层级较深）设置了 overflow: hidden、overflow: auto 或 overflow: scroll，并且它并不是 sticky 元素所依赖的最近定位上下文（例如没有设置 position: relative 等），那么 sticky 效果就很可能被直接破坏。
- 常见问题位置包括：
.ant-modal外层、Card容器、Tab 面板、Swiper wrapper，以及 CSS-in-JS 动态注入的内联样式 - 排查方法：使用 DevTools 的 Computed 面板逐层检查父节点，重点查看
overflow-x和overflow-y的最终计算值，不要只参考 Styles 面板中的声明 - 临时验证方式：给可疑父级添加
!overflow-visible或手动写入overflow: visible !important，如果 sticky 恢复生效，就基本可以确定问题来源 - 如果不能移除
overflow: hidden，可以尝试用clip-path: inset(0)替代，因为它可以实现裁剪效果，同时不会创建新的 BFC
表格中给 thead 加 sticky top-0 没反应
thead 本质上是语义容器，而不是实际的渲染目标节点，因此浏览器通常不会把它作为 sticky 的有效作用对象。真正可以实现粘性定位的，通常是每一个 th 表头单元格。
- 需要给每个
th单独设置sticky top-0 z-50，因为在复杂层叠场景中，z-10往往不够用 - 包裹表格的外层容器（例如
div.table-container）必须设置max-h-96 overflow-y-auto并具备明确高度，不能只依赖h-full或min-h-96 - 建议加上
table-fixed并统一列宽，例如使用w-32或min-w-[120px]，否则thead与tbody的列宽不一致时容易产生视觉错位 - 原生表格结构本身对 sticky 有限制：浏览器规范明确不支持对
display: table、table-row、table-cell直接应用 sticky，如有需要，应考虑使用 flex/grid 重构，或重置相关 display 属性
父容器用了 height: 100vh 或 display: contents
height: 100vh 往往会把容器高度固定死，进而导致滚动上下文被限制，sticky 只能在这个容器内部生效。一旦内容超出容器边界，sticky 元素就会失去预期效果，看起来像是重新回到了普通文档流中。
- 可以把
height: 100vh改为min-height: 100vh，既能保证首屏高度，又允许内容继续向下扩展 - 同时要确认该容器没有使用
display: contents，也没有因为浮动而脱离文档流，否则 sticky 将缺少可依附的包含块 - 如果是 Flex/Grid 布局，未设置明确高度约束（例如漏写
min-h-screen），或者使用了align-items: center，也可能导致top: 0的参考基线出现偏移 - Safari 对这类布局更敏感，实际开发中更推荐使用
min-h-[400px]而不是h-[400px]，以避免地址栏伸缩带来的高度计算异常
动态插入后 sticky 不生效
在 React、Vue 等前端框架中，如果 sticky 元素是在 useEffect 或 mounted 阶段动态插入 DOM，可能会因为布局计算早于样式真正生效而导致初次渲染失败。换句话说，浏览器在首次布局时没有正确识别 sticky 的边界条件。
- 临时处理办法：元素插入后调用
el.getBoundingClientRect()强制浏览器重排，或者通过requestAnimationFrame延迟添加sticky类 - 不要仅依赖
window.getComputedStyle(el).position来判断 sticky 是否生效，因为它可能返回sticky，但实际滚动行为依然已被祖先元素截断 - 更稳定的方案是：提前把 sticky 元素写入模板结构中，再通过
v-show或hidden控制显示与隐藏，而不是使用v-if或appendChild进行动态挂载
真正难排查的往往不是“sticky 怎么写”，而是“究竟是谁在上层悄悄拦住了它”。尤其需要注意那些并非直接写在业务代码中，而是来自框架组件、第三方容器或 CSS-in-JS 注入的 overflow 与 transform。相比 Styles 面板，DevTools 的 Computed 面板更值得参考，因为它展示的是浏览器最终实际执行后的真实结果，也是定位 sticky 失效原因时最可靠的依据之一。
