导航栏飘不起来？深扒 position: sticky 的兼容性真相

做后台管理系统或是内容长页时，大家都想让顶部导航或侧边栏像被胶水粘住一样，随页面滚动停在视口内。CSS 属性 position: sticky 看似简单，几行代码就能搞定，但在实际交付中，经常遇到“明明写了却不动”的尴尬情况。这往往不是因为写法错了，而是掉进了兼容性与环境设置的隐形陷阱里。

理解它的核心机制是排查问题的第一步。sticky 定位本质上是 relative 和 fixed 的结合体。当元素滚动到触发阈值前，它 behave 像 relative；一旦越过阈值，它就变成 fixed。这个“变身”过程依赖于一个完整的包含块（Containing Block），而这里正是大多数 Bug 的藏身之处。

最常见的翻车现场，出在父容器的 overflow 属性上。

很多开发者习惯了给容器添加 overflow: hidden 或 auto 来处理布局裁剪，却没意识到这会直接切断 sticky 元素的滚动参照系。当一个设置了 sticky 的元素，其任一祖先节点存在非 visible 的 overflow 值时，粘性效果就会失效。比如在卡片式布局中，你想让卡片内的标题粘性吸附，但外层卡片容器为了圆角效果加了遮罩滚动，结果就是标题跟着卡片一起滚走了。遇到这种情况，必须检查从该元素到文档根路径上的所有父级，确保没有 overflow 限制，必要时调整 DOM 层级结构。

另一个容易被忽视的现代 CSS 冲突，来自 transform 和 backdrop-filter 属性。

在现代 UI 设计中，为了实现模糊背景或 3D 变换，常会对父元素应用 transform。根据规范，这会让父元素成为新的定位上下文，导致内部的 sticky 无法正确计算相对于视口的距离。同样，某些旧版本的 iOS Safari 在渲染 backdrop-filter 时也偶尔会忽略 sticky。这属于浏览器内核实现的差异，通常表现为样式偶尔生效、偶尔失效，调试起来非常“玄学”。遇到此类问题，若业务强依赖粘性体验，建议移除相关样式或尝试将 sticky 元素提升到更高层级的父容器中独立渲染。

关于浏览器兼容性，现在的局面其实已经很好了。主流桌面与移动端浏览器对标准 sticky 的支持率已相当高，但真正的风险在于特定的 Webview 环境。例如部分安卓低版本 WebView，或是微信内置浏览器的旧内核，可能依然存在支持缺口。对于追求极致兼容的项目，不要盲目信任 caniuse 表格，而要在目标设备上实测。

当确定需要覆盖不支持 sticky 的环境时，纯 CSS 方案就行不通了，这时候得准备 JS 降级策略。

简单的思路是利用 IntersectionObserver 监听元素进入视口的状态，动态切换类名。虽然这种方式比原生 sticky 多了一层 JS 开销，且滚动时可能不如硬件加速流畅，但它能确保功能在不同环境下始终可用。更重要的是，利用 @supports 进行特性检测是一个好习惯，它能让浏览器自动判断是否执行回退逻辑，避免在不支持的环境下加载不必要的脚本，保持首屏性能。

此外，还要留意 z-index 堆叠上下文 的影响。有时候 sticky 失效并非因为定位属性，而是因为兄弟元素的层级关系导致它被遮挡。如果视觉上没挡住但实际上点不到，检查一下是否形成了新的堆叠上下文，这往往需要配合 isolation: isolate 来调整。

技术上没有绝对的万能药。sticky 定位极大地简化了开发流程，但也引入了隐性的约束条件。新项目可以大胆使用，配合 PostCSS 插件处理前缀；老项目重构则需评估收益成本。真正成熟的兼容性方案，不是死磕某一个属性的支持率，而是根据产品需求，准备好随时可用的降级预案。毕竟，用户体验的稳定性，永远比技术的时髦度更重要。