sticky失效主因是祖先元素设置overflow:hidden/auto/scroll截断滚动上下文，或父容器用height:100vh、display:contents等导致无有效定位上下文，需用computed面板查溢出值并改用clip-path或min-height修复。
绝大多数情况下，sticky 失效不是类名写错了，而是某个祖先元素悄悄截断了滚动上下文——浏览器直接把它当 position: static 处理，DevTools 里 computed 的 position 显示为 static 就是铁证。
父容器设置了 overflow: hidden 或 auto
这是最隐蔽也最高频的“静默杀手”。只要任意一层祖先（哪怕离得很远）设置了 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 只在该容器内部生效，一旦内容超出，它就“掉出边界”，退回到普通文档流。
- 把
height: 100vh换成min-height: 100vh，既保底又允许伸展 - 确保该容器不是
display: contents或浮动脱离文档流，否则没有包含块可依附 - 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 元素提前写在模板里，用
v-show或hidden控制显隐，而非v-if或appendChild动态挂载
真正难排查的从来不是“怎么写”，而是“谁在暗处拦住了它”——尤其是那些没写在你代码里、来自框架组件或 CSS-in-JS 注入的 overflow 和 transform。DevTools 的 Computed 面板比 Styles 面板更值得信任，因为它是浏览器最终执行时的真实状态。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
