fixed定位按钮移动端点不中主因是webview对缩放、viewport解析偏差及触摸坐标校准失效，尤其受transform、键盘弹出和安全区影响；应禁用user-scalable、慎用vh/rem、优先px+env(safe-area-inset-bottom)、监听focusin动态调整bottom，并以sticky替代fixed提升可控性。
fixed定位按钮在移动端点不中的真实原因
不是CSS写错了，是fixed元素在部分安卓WebView和iOS Safari中会因缩放、viewport解析偏差或点击区域判定逻辑导致:hover失效或点击偏移。尤其当页面有transform、scale或强制横屏适配时，bottom值可能被重算但触摸点未同步校准。
- 用
touch-action: manipulation强制启用快速点击（避免300ms延迟干扰坐标） - 确保
viewportmeta中不含user-scalable=yes，否则缩放会破坏fixed锚点 - 避免给
body或根容器设transform，它会让fixed元素相对视口错位 - 测试时用真机开启“缩放辅助”功能，很多“点不中”只在开启该功能时复现
bottom值该写px、rem还是vh？
bottom用绝对单位最稳，vh在iOS Safari中存在1px级渲染抖动，rem依赖根字体大小且无法响应键盘弹出——而悬浮按钮最常出现在表单页底部，键盘会顶起页面，fixed本应无视此变化，但某些Android系统会错误重绘bottom。
- 首选
bottom: 24px（或1.5rem，前提是根字号固定为16px） - 禁用
bottom: 5vh：iPhone X+系列安全区会压缩可用vh，导致按钮卡在刘海下方 - 若需适配全面屏，用
env(safe-area-inset-bottom)叠加：bottom: calc(24px + env(safe-area-inset-bottom)) - 别依赖
@media (max-height: 600px)调bottom——高度媒体查询在横屏切换时不可靠
:hover伪类在触摸设备上根本不可信
几乎所有触摸设备（包括带触控笔的Windows笔记本）默认不触发:hover，除非用户“悬停”超过1.5秒且无后续触摸动作——这违背按钮交互直觉。强行用@media (hover: hover)做降级，反而让iOS用户永远看不到悬停态。
- 把悬停效果改成交互反馈：监听
touchstart/mousedown事件，动态加class控制样式 - 用
pointer: coarse媒体查询区分触控设备：@media (pointer: coarse) { .btn::after { content: ""; } }可加点击蒙层 - 禁用
transition: all，只对background-color和transform做过渡，否则低端安卓机掉帧明显 - 别给
fixed按钮加box-shadow: 0 0 0 0 rgba(0,0,0,0)来“强制触发硬件加速”——现代浏览器已不需要
键盘弹出时按钮被顶到屏幕外的修复逻辑
fixed本该无视滚动和键盘，但Android Chrome 80+和部分国产浏览器会把软键盘高度计入视口，导致bottom计算基准偏移。不能靠window.innerHeight监听，因为该值在键盘收起后仍有100ms延迟恢复。
- 监听
focusin事件，在输入框获得焦点时给body加keyboard-active类，用CSS临时提升bottom：body.keyboard-active .fab { bottom: calc(24px + 200px); } - 200px是保守值，实际应取
document.documentElement.clientHeight与window.innerHeight差值，但需防NaN - 不用
resize事件——它在键盘收起后可能触发多次，造成闪烁 - 若按钮需始终贴底，考虑放弃
fixed，改用position: sticky配合bottom: 0于页面最底层容器，虽牺牲部分兼容性但更可控
真正难的不是写对那几行CSS，而是判断当前环境是否真的支持fixed语义——有些WebView连env(safe-area-inset-bottom)都返回0，得靠getComputedStyle读取伪元素内容做fallback探测。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
