安卓4.4–5.1 webview内核缺失position: sticky实现，会静默忽略该声明并始终计算为static；需通过devtools的computed面板确认，结合css.supports('position','sticky')检测，避免@supports误用及祖先transform/filter/min-height等干扰。
安卓老版本 WebView（尤其是 Android 4.4–5.1 内核）压根没实现 position: sticky，不是“不兼容”，而是根本不存在——它会静默忽略该声明，computed position 始终为 static。
怎么确认是内核缺失，不是写法错了
真机或远程调试时打开 DevTools，选中目标元素，在 Computed 面板里直接看 position 的计算值。如果显示 static，但 Styles 面板里明确写了 position: sticky 和 top: 0，且已排除祖先 overflow、transform 等干扰项，基本可断定是内核未支持。
别信 UA 字符串：华为 X5、QQ 浏览器、微信内置浏览器常伪装成 Chrome，但底层仍是旧 WebKit 分支；用特性检测才可靠：
const supportsSticky = CSS.supports('position', 'sticky');
注意：@supports (position: sticky) 在部分旧 WebView 中会导致整段 CSS 被丢弃，不能用来包裹全部样式。
为什么不用 @supports 就直接 fallback 到 JS
旧安卓 WebView 对 @supports 解析不稳定，且 CSS.supports 是唯一被广泛支持的运行时检测方式。一旦检测失败，必须走 JS 模拟路径，但不能简单换成 position: fixed：
-
fixed会脱离文档流，下方内容会上蹿，破坏原有布局 - 旧安卓对
fixed本身也有严重 bug：它会 relative to 最近可滚动祖先，行为等同于absolute - JS 模拟需监听
scroll+resize，并基于window.innerHeight和window.scrollY动态设置top，还要加节流防卡顿
父级 transform/filter 会让 sticky 失效，哪怕只写在爷爷级
安卓 WebView（尤其 Android 6–8）对层叠上下文更敏感。transform: translateZ(0)、filter: blur(1px)、will-change: transform 这些属性，只要出现在 sticky 元素任意祖先上，就会切断滚动锚定链。
现象是：PC 和新版 Chrome 正常，安卓机上元素“掉下去”或完全不动。排查方法：
- 在 DevTools 中逐层点 parentElement，检查每层的 computed
transform和filter - 临时禁用可疑祖先的这些声明，看 sticky 是否恢复
- 避免在任何祖先上使用
transform—— 即使是transform: translateX(0)也不行
height: 100vh 在安卓 WebView 中会阻止 sticky 激活
安卓 WebView 对“滚动上下文”的判定比桌面严格：如果 sticky 元素的最近可滚动祖先设了 height: 100vh，但内容高度刚好撑满或略超，部分内核会认为“无需滚动”，跳过 sticky 激活逻辑。
结果就是页面看起来能滚，但 sticky 元素只闪一下就回归文档流。解决方案很具体：
- 把
height: 100vh改成min-height: 100vh - 确保该容器的父级没有
overflow: hidden，否则min-height也救不了 - 如果是 Flex/Grid 布局，额外检查
align-items——center或baseline会偏移顶部基准线，导致top: 0视觉失效
最麻烦的是：这些限制常常叠加出现。比如一个 height: 100vh 的 flex 容器，又套了带 transform 的 modal wrapper，再加个 overflow: hidden 的卡片外框——sticky 就彻底消失，且不会报错，只能靠逐层 computed 排查。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
