position: absolute 是最可控、兼容性最好的解法，因其锚定在相对定位父容器而非不可靠的视口，配合 min-height: 100vh、width: 100% 和 focusin/blur 动态 bottom 计算可彻底规避键盘错位。
直接用 position: absolute 替代 position: fixed 是目前最可控、兼容性最好的落地解法；flex 本身不修复 fixed 错位，但配合容器约束和动态高度控制，可构建更稳健的“伪固定”布局。
为什么 absolute 能绕过键盘错位
position: fixed 锚定在视口（visual viewport）上，而软键盘弹出时，iOS 和多数安卓 WebView 并不触发真正的视口重绘——window.innerHeight 可能延迟更新或根本不变，visualViewport.height 才是真实可视高度。但 fixed 元素仍按旧值计算位置，结果就是按钮“飘”在键盘上方。position: absolute 则锚定在最近的 position: relative 祖先上，只要该容器高度稳定（比如设为 min-height: 100vh），底部元素就不会被键盘拖走。
关键差异在于：
- fixed 依赖浏览器对「键盘是否改变视口」的判断，而这个判断在各平台极不可靠
- absolute 依赖父容器 layout height，你完全可控
absolute 底部栏必须满足的三个条件
只写 position: absolute; bottom: 0 会穿帮。真正起效需同时满足：
- 根容器必须有
position: relative且明确高度：推荐min-height: 100vh（不能只写height: 100%，否则在滚动或键盘弹出时塌陷） - 底部元素必须加
width: 100%，否则横屏或缩放后可能错位 - 必须监听
focusin/blur，动态重算bottom值，不能依赖初始bottom: 0
focusin 后如何安全计算 bottom 值
不能直接读 input.getBoundingClientRect().bottom，因为 focusin 触发时键盘尚未完全展开，坐标仍是弹出前的旧值；也不能用 offsetTop，它在 relative 容器下不可靠。
立即学习“前端免费学习笔记（深入）”；
正确做法是：
- 在
focusin回调里加setTimeout(() => { ... }, 0)，确保 DOM 重排完成后再取坐标 - 用
window.innerHeight - inputRect.bottom计算 bottom 偏移，而非写死数值 - 多个输入框共用同一底部栏时，需用全局变量记录当前
document.activeElement，避免重复切换或漏恢复 -
blur后立刻恢复position: fixed和bottom: 0，否则滚动时元素会消失或错位
示例核心逻辑：
const footer = document.querySelector('.footer');
const inputs = document.querySelectorAll('input, textarea');
<p>inputs.forEach(input => {
input.addEventListener('focusin', () => {
setTimeout(() => {
const rect = input.getBoundingClientRect();
footer.style.position = 'absolute';
footer.style.bottom = <code>${window.innerHeight - rect.bottom}px</code>;
}, 0);
});</p><p>input.addEventListener('blur', () => {
footer.style.position = 'fixed';
footer.style.bottom = '0';
});
});flex 布局不是 fix，而是替代方案的载体
很多人误以为给 footer 加个 display: flex 就能解决 fixed 错位——其实 flex 只负责内部对齐，不干预定位行为。真正起作用的是它所支撑的「脱离 fixed 的布局模式」：
- 若根容器设为
display: flex; flex-direction: column; min-height: 100vh，底部区域用margin-top: auto实现“视觉底部”，它就不再依赖视口，自然不会被键盘顶起 - 但要注意：
100vh在键盘弹出时仍等于物理屏幕高度，iOS 上可能造成底部留白，需配合env(safe-area-inset-bottom)或visualViewport动态修正 - 这种方案的代价是：底部区域属于文档流，会被长内容撑开；若页面需整体滚动，得额外用
overflow-y: auto控制内容区
最容易被忽略的一点：iOS 键盘收起后，window.innerHeight 不会立刻恢复，可能延迟几百毫秒；此时若依赖单次 resize 或 blur 事件来还原样式，大概率失败。必须用 setTimeout 或 requestAnimationFrame 延迟执行，或连续两帧检查高度是否稳定再行动。
