ios中fixed失效是因锚定初始visualviewport，键盘弹出后视口变化导致定位错乱；应改用sticky、env(keyboard-inset-bottom)或absolute动态适配。
iOS 唤起键盘后 position: fixed 失效，不是你 CSS 写错了，而是浏览器把 fixed 锚定在初始 visualViewport 上，键盘一弹，视口高度被压缩或上推，但元素不重算位置——直接修 fixed 是死路，得换锚点或绕开它。
为什么 iOS 里 fixed 会退化成 absolute
只要任意祖先元素（哪怕隔了三层）设置了以下任一属性，position: fixed 就会失去相对于视口的定位能力：
-
transform值不为none（包括translateZ(0)、scale(1)） -
filter值不为none（哪怕只是blur(0)或写法里多一个空格） -
will-change设在父级而非目标元素自身
这时它会退化为相对于该祖先定位，滚动或键盘弹出时就跟页面一起动。DevTools 的 Layers 面板里如果看不到该元素出现在 “Composited Layers”，基本就是被拖进某个包含块里了。
用 position: sticky 替代 fixed（推荐首选）
如果你的按钮/导航栏本就紧贴内容流底部（如聊天输入框旁的「发送」、评论区的「提交」），sticky 是最自然、副作用最少的解法：
- 设
position: sticky; bottom: 0;，父容器需有明确高度（如min-height: 100vh）且允许内部滚动 - 它不脱离文档流，不会被键盘“悬空”顶起，也不受
transform等属性引发的层叠上下文干扰 - iOS 15.4+、Android Chrome 90+ 均支持；旧版可渐进增强为
absolute + bottom: 0 - 别在父容器上加
overflow: hidden或transform，否则sticky会失效
用 env(keyboard-inset-bottom) 做 iOS 原生避让（仅限 iOS 16.4+）
这是目前最干净的纯 CSS 方案，但必须满足三个硬条件：
-
<meta name="viewport" content="width=device-width, initial-scale=1.0, viewport-fit=cover">必须存在 - 样式必须包裹在
@supports (bottom: env(keyboard-inset-bottom))里，否则旧版 Safari 会忽略整条规则甚至解析失败 - 写法只能是
bottom: env(keyboard-inset-bottom, 0px);—— 别和svh混用，比如calc(0px + 100svh)是错的，语义冲突 - 安卓完全不支持该变量，不能只靠它；需 fallback 到
sticky或 JS 方案
用 position: absolute + focusin/blur 动态适配（兼容性最广）
这是兜底能力最强的方案，覆盖所有 iOS 版本和老安卓 WebView：
- 根容器（如
#app或body）设position: relative和min-height: 100vh（不能只写height: 100%，否则键盘弹出时塌陷） - 底部区域加
width: 100%，否则横屏或缩放后偏移 - 监听
focusin（不是focus），并在回调里加setTimeout(() => { }, 0)，确保 DOM 重排完成后再读取getBoundingClientRect().bottom - 计算方式：用
window.innerHeight - inputRect.bottom得到当前 bottom 偏移，而非写死数值 -
blur后立刻恢复position: fixed和原始bottom: 0，并调用el.style.removeProperty('top')和el.style.removeProperty('bottom')清除残留 inline 样式
最容易被忽略的是：所有计算前先确认 document.activeElement === inputEl，防止异步焦点转移导致状态错位；若页面用了 transform、overflow: hidden 或 fixed 父容器，getBoundingClientRect() 和 scrollIntoView() 都可能失效，且无报错提示。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
