position: fixed 是唯一符合“固定悬浮”定义的方案，因其直接锚定视口且不随滚动偏移；absolute 依赖祖先容器、随滚动移动，无法实现真正悬浮，iOS/安卓 WebView 中更易错位。
用 position: fixed 是唯一可靠方式，其他方案（如 absolute、sticky 或 flex 沉底）都不符合“固定悬浮”定义——它们要么随滚动消失，要么不锚定视口，要么根本不是悬浮。
为什么不能用 position: absolute 做底部悬浮条
它依赖最近的已定位祖先，一旦页面有 transform、overflow: hidden 或动态插入的 wrapper（比如 CMS 自动加的容器），悬浮条就会错位甚至卡在半空；滚动时跟着内容走，完全失去“固定”意义。iOS Safari 和部分安卓 WebView 中表现更不稳定。
position: fixed 必须配齐的三件套 CSS
漏掉任意一项都可能失效或错位：
-
position: fixed—— 起点，不是可选项 -
bottom: 0（或具体值如bottom: 24px）—— 不要用top+ 高度计算，不可靠 -
left: 0; right: 0—— 确保横跨全宽；若只设left不设right，窄屏下可能溢出 - 必须加
z-index: 999（别用 999999），否则会被弹窗、广告 SDK 盖住 - 高度建议用固定值（如
height: 56px），禁用100vh或百分比——Safari 地址栏收放时会跳变
主内容如何避让，又不引发横向滚动
fixed 元素天然脱离文档流，所以主内容不会自动“知道”它存在。常见错误是给 body 加 padding-bottom，结果缩放或窄屏下触发横向滚动条。
立即学习“前端免费学习笔记（深入）”；
正确做法是只约束悬浮条自身，并确保主内容容器预留空间：
- 给主内容最外层容器（如
<main>或<div class="content">）加padding-bottom: 56px（值 = 悬浮条高度） - 避免用
margin-bottom，它不防遮挡；也别用min-height代替padding - 如果悬浮条高度不固定（比如含文字且字号响应式），改用 JS 动态读取并设置
padding-bottom，但首次渲染要 fallback 到安全值（如 64px）
iOS Safari 和移动端真坑在哪
不是写法错，是运行时行为突变：
- 键盘弹出时，
fixed元素可能被顶到视口上方——不要在里面放<input>或<textarea> - 页面高度不足一屏时，按钮可能“粘滞消失”：给
body加min-height: 100vh（不是height: 100vh）可稳定锚点 - 触摸热区必须 ≥ 44×44px：按钮本身设
width: 56px; height: 56px，再用display: flex居中图标，别靠font-size控制大小 - 慎用
transform: translateZ(0)强制硬件加速——可能引发输入框失焦、滚动卡顿
真正难的从来不是定位，而是状态管理：用户快速连点多次生成多个实例、拖拽后没解绑 mousemove 监听器、关闭时用 remove() 而非 display: none 导致下次 show 无法复用——这些细节不处理，上线后就是偶发 bug 的源头。
