sticky未触发时占位,fixed一设即脱离文档流;sticky依赖可滚动祖先且仅单向定位,fixed绑定视口、支持多向偏移;移动端sticky更稳定,fixed易卡顿错位。
这是最直接影响布局的差异。给一个 .header 加 position: sticky; top: 0,它在滚动前和普通块级元素一样撑高父容器、影响兄弟元素位置;而加 position: fixed; top: 0 后,原始位置立刻“塌陷”,下面的内容直接上移——你甚至可能看到页面突然跳动。
常见错误现象:.nav 加了 sticky,但滚动后内容“跳了一下”——大概率不是 sticky 失效,而是父容器高度塌陷(比如没清浮动、没设 min-height),或者兄弟元素用了 margin-top 被重排。fixed 则不存在这种“过渡态”,它从声明那一刻起就脱离文档流。
sticky 的行为严格依赖最近的可滚动祖先:如果 .sidebar 放在一个 div 里,而该 div 有 overflow-y: auto; height: 400px,那 sticky 就只在这个 div 内部吸附;一旦滚出这个区域,它自动退回 relative 行为。fixed 不管嵌套多深,哪怕在 iframe 里,都死死钉在视口坐标上。
这意味着:
tbody 滚动时它自然进出吸附状态,无需 JS 监听offsetTop、监听 scroll、判断是否进入视区,维护成本高overflow: hidden 特别敏感——只要 sticky 元素的任意一个祖先写了它,sticky 就直接失效sticky 必须且只能写 top、bottom、left、right 中的一个,比如 top: 10px 或 left: 20px;同时写 top 和 left,整个声明会被浏览器忽略。fixed 则无此限制,top: 10px; left: 20px; 是完全合法的。
所以:
在 iOS Safari 和部分安卓 WebView 中,fixed 元素常出现滚动卡顿、输入框聚焦时错位、地址栏收起后定位偏移等问题——因为其强绑定视口的机制与原生滚动优化存在冲突。sticky 因为始终依附于局部滚动容器,在这些场景下更稳定。
但要注意:
body 上直接滚动生效(iOS 上 body 滚动常被降级处理)div,且需有 height 或 max-height + overflow-y: auto,不能只靠 overflow: scroll
transform: translateZ(0) 强制硬件加速的容器里会失效真正容易被忽略的是:sticky 的“粘性”不是 CSS 自己算出来的,它完全依赖滚动容器的尺寸和溢出行为。很多问题其实出在父容器没撑开、中间祖先加了 overflow: hidden、或者误以为它能像 fixed 那样跨容器定位——这些地方一错,sticky 就静默失效,连报错都没有。