position: sticky 不能可靠实现底部固定导航，尤其在移动端；因iOS Safari不支持bottom、Android低版本忽略、微信WebView退化为relative，且依赖滚动祖先和高度约束，在地址栏收放或软键盘弹出时锚点失效。
position: sticky 不能可靠实现底部固定导航，尤其在移动端。它不是“fixed 的轻量替代”，而是行为受限的局部粘滞机制——iOS Safari 对 bottom 值的支持几乎为零，Android 低版本直接忽略，微信 WebView 中多数退化为 relative。
为什么 sticky bottom 在移动端基本不可用
sticky 的触发依赖父容器滚动和明确的高度约束，而移动端页面高度本身动态变化（地址栏收放、软键盘弹出），导致粘滞锚点失效。更关键的是：sticky 只会在其**最近的滚动祖先容器内**生效，一旦父容器高度不足（比如空页或短列表），元素根本不会“吸到底部”。
常见错误现象包括：
- 导航栏在 iOS Safari 中完全不吸附，始终按 normal 流布局渲染
- 安卓 Chrome 下偶尔生效，但切换路由后立即脱离位置
- 微信 WebView 中点击输入框后，导航栏突然上浮或消失
sticky bottom 的参数写法本身就有兼容陷阱
即使强行写 position: sticky; bottom: 0;，也必须满足三个条件才能启动粘滞逻辑：父容器设 overflow-y: auto/scroll、父容器有显式 height 或 max-height、且内容高度超过该限制。这些在单页应用中极难稳定维持。
立即学习“前端免费学习笔记（深入）”；
对比 fixed 的简单直接，sticky 的配置成本高、可预测性差：
-
top和bottom不能共存，选一个就放弃另一个方向的控制 - 在 flex 容器中使用
sticky时，Safari 会因层叠上下文问题导致 z-index 失效 - 无法响应
env(safe-area-inset-bottom)，刘海屏下必然被手势条遮挡
什么时候可以考虑 sticky？仅限特定场景
如果你的底部区域不是导航栏，而是某个**局部模块的尾部操作条**（比如评论区底部的“发送”按钮），且该模块自身是 scrollable 容器、高度可控、不跨路由复用，那 sticky 才有讨论价值。
即便如此，仍需加兜底：
- 用
@supports (position: sticky) { ... }包裹样式，避免不支持设备解析失败 - 给父容器加
min-height: 200px（具体值按模块内容预估），防止粘滞条件不满足 - 别依赖
vh单位设父容器高度，iOS 下100vh不随键盘变化，会导致粘滞错位
真正需要“始终贴在屏幕最底”的导航栏，position: fixed 是唯一现实选择——它的坑是可预期、可收敛的，而 sticky 的坑是随机且难以调试的。
