多个position: sticky元素“叠着吸顶”是因为它们各自相对于最近滚动祖先独立计算top值，且原始位置受前序已吸顶元素影响；正确做法是统一设top: 0、显式z-index递减、避免嵌套与层叠上下文干扰，并为后续内容预留margin-top。
多个position: sticky元素为什么“叠着吸顶”而不是同时固定？
因为position: sticky不是全局固定，而是相对于**最近的滚动祖先容器**独立计算top值。每个元素的top是从它在文档流中的原始位置开始算的——而这个原始位置，可能已经被前面已吸顶的元素“推高”了。
比如：.section-header设top: 0，.group-header设top: 48px，实际效果是：当滚动到.group-header原始位置距父容器顶部48px时，它才触发吸顶；此时.section-header已在顶部占位，.group-header就会卡在它下方，形成视觉上的“第二层”。
- 这不是bug，是sticky的预期行为
- 关键不是
top绝对值多大，而是各元素之间的垂直间距关系是否与DOM顺序一致 - 若父容器高度塌陷或含
overflow: hidden，整个链路会直接失效
top值怎么设才不会错位、跳变或遮挡？
硬写top: 0、top: 52px、top: 104px看似合理，但一旦某级标题高度因字体缩放、行高变化或响应式断点而改变，就会错位。真正稳定的做法是：
- 所有sticky元素统一设
top: 0，靠它们在DOM中的自然顺序和自身高度“接力”堆叠 - 确保每级sticky元素（如
.section-header、.group-header）都是独立的块级元素，不嵌套在同一个sticky父容器里 - 给每个sticky元素显式设置
z-index，且数值严格递减（如z-index: 10、z-index: 9、z-index: 8），防止后出现的覆盖前一个 - 避免父容器触发新层叠上下文（禁用
transform、opacity、filter等属性）
移动端或小程序里sticky突然失效，常见原因有哪些？
不是兼容性问题，而是环境约束被悄悄破坏：
- 外层包裹了
position: relative的div或小程序view→ sticky会相对于这个相对定位父级计算，而非视口 - 加了
transform: translateZ(0)强制硬件加速 → iOS Safari 15.4–16.3中直接禁用sticky - 父容器用了
display: flex或display: grid→ 某些WebKit版本下flex/grid容器会干扰sticky行为 - 滚动容器不是
body而是某个div，且该div没设height或min-height→ 容器塌陷，sticky无滚动空间
吸顶后内容钻进标题底下，或出现空白/遮挡怎么办？
position: sticky不脱离文档流，吸顶后仍占原始位置空间。后续内容若不做避让，就会重叠或留白。
- 纯CSS方案：给紧跟在sticky元素之后的内容块加
margin-top，值等于该sticky元素的自然高度（含padding、border） - JS辅助方案（需动态适配）：监听
scroll，用getBoundingClientRect().top 判断是否已吸顶，再切换内容区的<code>padding-top - 切忌用
height或margin动态改sticky元素自身尺寸 —— 这会破坏其布局锚点，导致吸顶跳变
overflow: hidden、无意外层叠上下文）、z-index是否按视觉层级严格递减、以及是否用静态高度或JS动态补偿来处理内容避让。任何一环松动，都会让“自动堆叠”变成“随机叠压”。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
