sticky更优，因其滚动到阈值时才局部吸附且始终占位，避免fixed导致的布局抖动、viewport缩放错位及高重绘开销，但需满足可滚动祖先、无overflow:hidden等约束条件。
sticky 更好，前提是你的场景符合它的行为约束——它不是“永远固定”，而是“滚动到阈值时才局部吸附”，这恰恰是长页面中多数导航、表头、侧边栏的真实需求。
为什么 sticky 在长页面滚动中更稳定？
因为 sticky 不会强行把元素拽出文档流，它在未触发前仍占位、撑高父容器；而 fixed 一设就脱离流，导致下方内容“突然上移”，尤其在动态加载或高度变化频繁的长页面里，极易引发布局抖动或滚动错位。
常见现象：fixed 导航栏加完后，页面首次渲染时内容“跳一下”——不是 JS 没跑完，而是 fixed 立刻释放了原始空间，后续 DOM 插入时重排加剧；sticky 则全程保持布局连续性。
sticky 的滚动范围必须由可滚动祖先定义
长页面里直接写 body 或 html 上的 sticky 几乎无效：iOS Safari 对 body 滚动降级处理，且 body 默认不构成“可滚动祖先”。你得显式构造一个容器：
- 给某个
<div class="scroll-container"> 设置 <code>height或max-height+overflow-y: auto -
sticky元素必须是它的直接子元素（或满足层叠上下文要求的后代） - 避免该容器或任何中间祖先有
overflow: hidden、transform、filter—— 这些会让sticky直接退化为relative
fixed 容易在移动端输入时错位，sticky 不会
当用户点击 <input> 触发软键盘弹出时，iOS Safari 会收缩地址栏、重算 viewport 高度，所有 fixed 元素坐标瞬间偏移（比如导航栏被顶到屏幕外）；而 sticky 绑定的是局部滚动容器，不受 viewport 动态缩放影响，只要容器本身没重绘，吸附位置就稳。
但要注意：sticky 依赖父容器有明确滚动上下文，如果用 flex 布局但没设 height 或 min-height，容器无法滚动，sticky 就永远不会触发。
性能差异在长页面中非常明显
滚动 5000 行文本时，fixed 会导致浏览器持续重排整个文档（尤其是它影响了 z-index 层叠和渲染层），FPS 明显下降；sticky 仅在进入/退出吸附阈值时触发轻量重绘，且浏览器对其做了原生优化。
实测数据（Chrome DevTools Performance 面板）：
– fixed 方案平均 FPS ≈ 42，布局重绘次数 ≈ 187 次/秒
– sticky 方案平均 FPS ≈ 58，布局重绘次数 ≈ 23 次/秒
差距主要来自 fixed 强制绑定 viewport 后，每次 scroll 事件都需重新计算视口坐标并同步图层。
真正容易被忽略的点：很多人给 sticky 加 will-change: transform 想“优化”，结果反而干扰浏览器判断，让粘性行为延迟或失效——sticky 本身不需要手动提示优化，加了反而坏事。
