fixed底部“飘”是因transform等创建新定位上下文，使fixed脱离视口；iOS键盘会重置视口高度；需区分锚定视口底还是内容底，并针对性处理兼容性问题。
fixed定位的底部固定为什么经常“飘”在半空
因为 position: fixed 是相对于视口定位，但默认不考虑页面滚动或元素自身盒模型边界——尤其是当父容器有 transform、perspective 或 filter 时，会创建新的定位上下文，导致 fixed 元素被“困”在该容器内，不再贴底。
常见错误现象：bottom: 0 写了，但元素离底部还差一截；滚动后位置错乱；在 Safari 或 iOS WebView 中完全失效。
- 检查祖先元素是否意外加了
transform: translateZ(0)或will-change: transform，这些都会触发新层叠上下文，破坏fixed的视口参照 - 移动端务必测试
viewport设置，width=device-width, initial-scale=1缺失会导致视口计算异常 - 避免把
fixed元素放在overflow: hidden的父容器里，尤其在 modal 或 drawer 组件中
bottom: 0 不生效？先确认盒模型有没有撑开高度
即使定位正确，如果页面内容高度不足一屏，fixed 元素会“贴着视口底”，而非“贴着页面内容底”——这常被误认为“没固定住”。真实需求往往是“内容少时到底部，内容多时随滚动隐藏”，即“视觉上始终停在页面最下方”。
- 纯
fixed只能锚定视口，无法响应内容高度变化；若要贴内容底，得用position: absolute+ 父容器position: relative+ 高度撑满（如min-height: 100vh） -
bottom: 0在fixed下有效，但在absolute下依赖父容器是否有定位上下文和足够高度 - 不要依赖
body { height: 100% }，它通常无效；改用html, body { min-height: 100% }更可靠
兼容 iOS Safari 的 fixed 底部必须绕开 input 聚焦抖动
iOS Safari 在软键盘弹出时会重置视口高度，导致 fixed 元素被顶起甚至消失。这不是 bug，是浏览器为保证输入框可见做的主动调整，但表现极不一致。
立即学习“前端免费学习笔记（深入）”；
- 监听
focusin和blur事件，在input或textarea获焦时临时切为position: absolute，并手动计算bottom值（基于window.innerHeight） - 避免在
fixed元素内部放表单控件；把按钮/操作区和输入区物理分离 - 不推荐用
viewport-fit=cover强行拉伸——它只对刘海屏有影响，且加剧键盘冲突
要不要用 flex 实现“伪 fixed”底部？看场景再决定
用 display: flex; flex-direction: column + margin-top: auto 或 margin-top: auto 把底部区域推到容器末尾，本质是利用弹性布局分配剩余空间，不是真正固定。但它规避了所有 fixed 的兼容性问题。
- 适合单页应用主框架（如 header-main-footer），且 footer 不需要跨路由/滚动保持可见
- 性能更好：无定位重排，不触发合成层，不影响滚动流畅度
- 注意
main区域必须设flex: 1或flex-grow: 1，否则 footer 会被内容挤下去 - 不能响应视口缩放变化（比如用户放大字体），而
fixed可以
真正难的不是写哪行 CSS，而是分清你要固定的是“视口底部”还是“内容底部”，以及用户会不会在 iOS 上点进输入框——这两个判断漏掉一个，后面所有样式都白调。
