iOS微信中fixed被键盘顶起是因WKWebView不支持env(keyboard-inset-bottom)且resize几乎不触发，须用focusin/blur驱动absolute动态适配，并严格满足根容器relative+min-height、width:100%、setTimeout延时读取高度三条件。
iOS微信浏览器里position: fixed被键盘顶起，不是你CSS写错了，而是它把fixed锚定在初始visualViewport底部，而微信 WebView（基于旧版WKWebView）既不支持env(keyboard-inset-bottom)，又几乎不触发resize事件——只改样式必穿帮，必须用focusin/blur驱动状态切换。
为什么微信iOS里fixed错位比Safari还严重
微信内置浏览器在iOS上长期沿用较老的WKWebView内核（2026年仍常见于iOS 15–16.3），导致三个硬伤：
• visualViewport API 不可用或返回错误高度
• resize事件触发率低于20%，且延迟严重
• env(keyboard-inset-bottom) 完全不识别，写了也白写
更麻烦的是：微信会主动冻结document.body.scrollTop，blur后不手动window.scrollTo(0, 0)，元素就永远卡在高位。
用absolute模拟fixed必须满足的三个条件
这不是“换个position值”就能解决的事，关键在容器稳、状态清、时机准：
- 根容器（如
#app）必须设position: relative和min-height: 100vh（不能只写height: 100vh，否则键盘弹出时塌陷） - 底部元素加
width: 100%和box-sizing: border-box，否则横屏缩放后偏移 - 监听
focusin（不是focus）到input或textarea，并在回调里用setTimeout(() => { }, 0)等DOM重排完成后再读window.innerHeight
focusin后如何安全计算bottom偏移
直接读input.getBoundingClientRect().bottom会拿错——focusin触发时键盘还没展开，坐标仍是旧值。正确做法是：
微信公众号推文写作与发布助手。支持深度文章撰写（1500+ 字）、智能配图搜索、API 配置引导、草稿箱上传、一键排版等全流程功能。 每篇文章默认 1500 字以上，配备 1 张相关配图（放在第一段后），包含清晰的分段标题结构。
立即学习“前端免费学习笔记（深入）”；
- 页面加载时存基准高度：
const baseHeight = window.innerHeight -
focusin后用setTimeout(() => { const kbHeight = baseHeight - window.innerHeight; }, 0) - 若
kbHeight > 150，说明键盘大概率已弹出，此时设el.style.position = 'absolute'，并动态算el.style.bottom = kbHeight + 'px' - 多个输入框共用同一底部栏？得用全局变量记录
document.activeElement，避免重复切换或漏恢复
blur后必须立刻清理并重置滚动锚点
微信iOS中blur后不处理，底部栏会彻底失联——它既不回到底部，也不随滚动移动。这步不能省：
- 先清除inline样式：
el.style.removeProperty('top')和el.style.removeProperty('bottom') - 恢复原始定位：
el.style.position = 'fixed'，el.style.bottom = '0' - 强制重置滚动：
setTimeout(() => { window.scrollTo(0, 0) }, 100)（太短iOS会节流，100ms是实测下限） - 务必在执行前确认
document.activeElement === inputEl，防止异步焦点转移导致状态错位
最容易被忽略的其实是祖先容器：如果#app或其父级有transform、overflow: hidden或filter，getBoundingClientRect()返回的坐标就不可靠，而且不报错——真机测试前，先打开DevTools的Layers面板，确认底部元素是否出现在“Composited Layers”里。
