sticky元素不生效的三大主因：一是父容器或祖先设置了非visible的overflow（如hidden、scroll），切断滚动参考；二是父容器高度为0或未定义，导致无滚动上下文；三是sticky元素自身应用了transform/filter等触发新层叠上下文的属性。
sticky 元素不生效，先看父容器是否设置了 overflow
sticky 行为依赖于最近的「有堆叠上下文且非 visible 溢出」的祖先容器。如果父容器（或任意上层祖先）设置了 overflow: hidden、scroll 或 auto，sticky 就会失效——浏览器直接把它当成了普通定位元素处理。
常见踩坑点：
- 父容器用了
overflow: hidden做裁剪，却忘了 sticky 需要“滚动参考” - UI 框架组件（如 antd 的
Card、Modal）内部自带overflow，导致子元素 sticky 失效 - 用
overflow: clip也一样会切断 sticky 行为（Chrome 114+ 支持，但依然不触发 sticky）
解决办法：逐层检查父级元素的 computed overflow，临时改回 visible 测试；若必须保留溢出控制，可考虑把 sticky 元素提到更高层级（比如挂到 body 下），或用 position: fixed + JS 监听滚动模拟。
父容器高度为 0 或未定义，sticky 无滚动锚点
sticky 元素需要在一个「可滚动的块级容器」中才有意义。如果父容器没有明确高度，且内容不足以撑开它（即高度为 0 或 auto 且无约束），那么整个滚动上下文就不存在，sticky 自然不会触发。
立即学习“前端免费学习笔记（深入）”；
典型场景：
- Flex 容器中子项用了
flex: 1，但父容器没设height或min-height - Grid 布局里，行轨道未定义高度，导致 sticky 区域实际不可滚动
- 使用
height: 100vh但父级是display: contents或被重置了 box model
验证方式：打开 DevTools，选中父容器，看 Elements 面板右侧的 Layout 标签页里「Computed Height」是否大于 0；若为 0px，sticky 必定不响应。临时加 height: 500px 或 min-height: 100vh 可快速验证。
sticky 元素本身被 transform 或 filter 干扰
一旦元素应用了 transform、filter、will-change 或 perspective，就会创建新的层叠上下文和格式化上下文，这会中断 sticky 与滚动容器之间的关联链。
尤其容易忽略的是：
-
transform: translateZ(0)这类“强制硬件加速”写法，看似无害，实则让 sticky 失效 - CSS-in-JS 库（如 styled-components）自动注入的
will-change: transform - 动画库（如 framer-motion）默认启用的
transform优化
排查建议：在 DevTools 中临时取消所有 transform 和 filter 声明，观察 sticky 是否恢复；若必须用动画，可改用 top/left 配合 position: relative 过渡，或用 JS 手动监听 scroll 更新 top 值。
浏览器兼容性与根滚动容器限制
sticky 在 Safari 旧版本（≤14.1）、部分 Android WebView 中支持不完整；更隐蔽的问题是：根滚动容器（即 html 或 body）上设置 overflow-x: hidden 有时也会干扰 sticky，尤其当页面存在横向滚动需求时。
还有两个硬性限制：
- sticky 不会在
table直接子元素（如td、th）上生效，需包裹一层div - 如果 sticky 元素的
top值超出了其“粘性区域”的可用空间（比如父容器高 200px，设了top: 300px），它会一直保持初始位置不动
真正卡住的时候，往往不是语法错，而是这些隐式约束叠加的结果——多一层滚动容器、少一个 transform、父容器多一行 min-height，可能就是生效与否的分界线。
