移动端sticky失效主因是滚动上下文被祖先元素overflow:hidden/transform/filter等静默切断，致其退化为static；需用DevTools逐级检查computed position和overflow值，优先以clip-path:inset(0)替代overflow:hidden修复。
position: sticky 在移动端不是“设了就粘”，而是极易失效——90% 的问题出在滚动上下文被切断，不是 CSS 写错，而是父容器悄悄加了 overflow: hidden、transform 或 filter。
移动端 position: sticky 为什么经常不生效
它依赖一个可滚动的、非 static 定位的最近祖先。移动端常见“隐形杀手”包括：
-
body或main上写了overflow: hidden（比如为了禁用滚动，却顺手剪掉了 sticky 的滚动链） - 父容器用了
transform: translateZ(0)或will-change: transform（iOS Safari 尤其敏感，会隐式创建新层叠上下文，中断 sticky） - React/Vue 框架自动包裹的匿名
div没设高度、没设overflow-y: auto，导致 sticky 找不到有效滚动容器 - 漏写
top值——top: auto是默认值，不会触发粘性；必须显式写top: 0或top: 44px
验证是否真生效：打开开发者工具 → “Computed” 面板 → 查看 position 是否为 sticky，而不是回退成 relative。
移动端表头/导航栏的可靠写法
适用于 <thead>、<code><header></header> 等需吸顶的场景，重点在结构可控：
立即学习“前端免费学习笔记（深入）”；
- 确保该元素的**直接父容器**有明确高度约束和可滚动能力，例如：
max-height: 70vh; overflow-y: auto; -
th或header必须设top: 0+z-index: 10（否则滚动时可能被后续内容遮盖） - 避免给父容器加
clip-path、backdrop-filter，这些在 iOS 16+ 也会切断 sticky - 若用 Flex/Grid 布局，
sticky元素必须是直接子项（不能套一层额外div），且父容器需设height或max-height
示例（移动端表格表头）：
.scrollable-table { max-height: 70vh; overflow-y: auto; }
.table-fixed { table-layout: fixed; width: 100%; }
.table-fixed thead th {
position: -webkit-sticky; position: sticky;
top: 0;
background: #fff;
z-index: 10;
}
移动端侧边栏要不要用 sticky？
绝大多数情况不要。原因很实际：
- 侧边栏通常需要脱离文档流、固定在视口边缘，
position: fixed更直接可靠 -
sticky要求父容器有明确滚动范围，而移动端页面往往整个body可滚动，fixed不依赖此条件 - 用
fixed时必须手动让正文让位：margin-right: 280px（右侧栏）或margin-left: 280px（左侧栏） - 移动端必须加媒体查询降级：
@media (max-width: 768px) { .sidebar { position: static; } }，否则小屏上会遮盖主要内容
真正需要 sticky 侧边栏的场景极少，仅限：主内容区本身是独立滚动容器（如聊天窗口中的联系人列表），且你明确希望它随该容器滚动自然进退。
iOS Safari 的兼容性细节
即使写对了，iOS Safari 仍可能抖动、卡顿或延迟响应：
- iOS 15.4 之前存在滚动抖动，升级系统可缓解；若必须支持旧版本，优先用
IntersectionObserver替代scroll事件监听 - 不要依赖
scroll事件做 sticky 切换——它在 iOS 上触发频率低、延迟高，容易出现“半粘半掉”现象 -
z-index必须显式设置（推荐 ≥ 100），否则某些 iOS 版本下会被<iframe></iframe>或<video></video>盖住 - 打印样式表（
@media print）中，sticky默认退化为relative，而fixed仍强制固定——导出 PDF 时效果不同，这点常被忽略
复杂点不在怎么写 CSS，而在怎么确认滚动上下文真实存在、且未被任何看似无关的属性悄悄切断。
