iOS中fixed“飘”或“消失”并非CSS错误，而是其锚点从视口退化为父级padding box——当父级含transform、perspective、filter（除opacity外）或overflow-scrolling: touch时，fixed即退化为absolute；body/html设height: 100%或overflow: hidden亦会关闭fixed优化；uni-app中塞入scroll-view更使其认滚动容器为锚点；优先用position: sticky替代，需满足父容器设height/min-height: 100vh且无干扰属性，元素自身设sticky+bottom: 0+z-index。
为什么iOS里fixed会“飘”或“消失”
不是你CSS写错了，而是iOS Safari的fixed定位锚点会悄悄换人：它本该相对于视口，但一旦父级有transform、perspective、filter（除opacity外）或overflow-scrolling: touch，fixed就退化成absolute，锚定到那个父级的padding box上——而这个父级很可能正在滚动或缩放。
典型表现：手指一滑，顶部导航跟着动；松手后才“弹回”；或者底部按钮直接卡在键盘底下，完全看不见。
- 检查DevTools的Layers面板，如果fixed元素没出现在“Composited Layers”里，说明它根本没被硬件加速，大概率已退化
-
body或html上设了height: 100%或overflow: hidden，也会触发iOS关闭fixed优化 - uniapp里把
position: fixed元素塞进scroll-view或可滚动div内，它就自动认滚动容器当爹，不再认视口
优先用position: sticky替代
position: sticky不脱离文档流，天然响应滚动和软键盘推起，是目前最轻量、副作用最少的解法，但必须满足三个硬条件：
- 父容器（比如
.chat-container）必须设min-height: 100vh或height: 100vh，不能只靠flex: 1或overflow: auto偷懒 - 父容器不能有
transform、overflow: hidden或will-change，否则sticky直接失效 - 元素本身设
position: sticky; bottom: 0;，并加z-index: 1000防被遮挡
兼容性没问题：iOS 15.4+、Chrome 90+全支持；旧版本可fallback到absolute+JS动态计算。
立即学习“前端免费学习笔记（深入）”；
监听focusin动态切absolute的细节
别用resize事件——iOS基本不触发；也别在focusin回调里立刻读高度，键盘还没展开，getBoundingClientRect().bottom还是旧值。
- 必须加
setTimeout(() => { /* 读坐标 */ }, 0)，让浏览器完成layout更新 - 计算公式是：
window.innerHeight - inputRect.bottom，不是inputRect.top，也不是写死200px - 多个输入框共用同一底部区域时，用
document.activeElement判断当前焦点，避免重复切换或漏恢复 -
blur后立刻清除内联bottom并恢复position: fixed，否则滚动时输入框会消失
安卓WebView和微信内置浏览器的兜底方案
安卓不支持env(keyboard-inset-bottom)，微信WebView对scrollTo(0, 0)有节流，直接调用常无效。
- 最稳fallback是给最外层容器（如
#app）加padding-bottom: 60px（按输入框实际高度设），并确保box-sizing: border-box - 若需动态避让，监听
focusin后执行setTimeout(() => window.scrollTo(0, 0), 100)，比requestAnimationFrame更兼容老机型 - 结构上强绑定的场景（如“发送”按钮紧贴输入框右侧），直接把按钮和
input放进同一个display: flex容器，用margin-left: auto对齐——完全绕过定位问题
真正难的不是写几行CSS，而是判断什么时候该放弃fixed思维，把按钮嵌进表单容器里——这种方案不依赖任何事件监听，无兼容性风险，但只适用于语义上就是输入操作一部分的场景。
