bottom: 0 导致内容被遮挡，因 fixed 元素脱离文档流且主内容未预留空间；正确做法是给主容器设 padding-bottom = 悬浮条高度 + 安全余量（如 80px），并避免 ios 渲染降级、触摸热区不足及 z-index 冲突等问题。
底部悬浮条用 position: fixed 是唯一稳定方案，但直接写 bottom: 0 就上线，90% 的页面会在 iOS Safari 或窄屏下遮内容、误触、闪退或滚动卡顿。
为什么 bottom: 0 会导致内容被遮挡
fixed 元素脱离文档流，bottom: 0 会让它物理贴底，而页面主内容末尾没有预留空间——用户滑到底部时，最后几行文字/按钮刚好被盖住。这不是“看不见”，是真被压住了。
常见错误做法：body { padding-bottom: 60px } —— 看似简单，但一旦页面缩放、横屏、或键盘弹出（iOS），padding 就失效，可能触发横向滚动条或留白错位。
- 正确思路：不靠 body 补空间，而是让悬浮条自己“让出位置”
- 给主内容容器（如
<main></main>或.content）加padding-bottom，值 = 悬浮条高度 + 安全余量（推荐80px） - 若悬浮条高度动态（比如含文字、多行），用 CSS 自定义属性统一管理：
--floating-bar-height: 64px，再写padding-bottom: calc(var(--floating-bar-height) + 16px)
iOS Safari 中悬浮条“消失”或“跳动”的根因
不是 bug，是渲染机制：当页面有 input 获焦、软键盘弹出、或父容器设了 overflow: hidden / -webkit-overflow-scrolling: touch 时，iOS 会临时降级 fixed 行为，让它表现得像 absolute —— 锚点变成最近的可滚动祖先，而不是视口。
- 必加修复：
body { min-height: 100vh; overflow-x: hidden }，防止高度塌陷导致锚点丢失 - 禁用
transform: translateZ(0)或will-change: transform，它们在 iOS 上会干扰 fixed 定位稳定性，还可能引发输入框失焦 - 避免把悬浮条塞进任何
overflow: auto的模块里——哪怕只是个<section></section>，它都可能成为“最近已定位祖先”
移动端点击失效或热区不准的真实原因
不是 JS 绑错了事件，是 CSS 触摸目标尺寸不达标。WCAG 要求最小可点击区域 ≥ 44×44px，但很多开发者只给图标设 24×24px，外层容器又没撑开。
- 按钮本身必须显式设宽高：
width: 56px; height: 56px（留出 6px 边距，确保热区达标） - 用
display: flex; align-items: center; justify-content: center居中图标，别依赖line-height或padding控制垂直对齐 - 禁用
font-size控制大小——不同字体 baseline 渲染差异大，同一font-size在 iOS 和 Android 上实际高度可能差 3–5px - 加
cursor: pointer和box-shadow（哪怕很浅），否则纯色圆点在深色背景上根本看不见
z-index 堆太高反而引发新问题
设 z-index: 999999 看似保险，实则埋雷：第三方 SDK（如客服插件、广告组件）常也用超大 z-index，结果你的悬浮条盖住它的弹窗，或它的浮层反过来压住你的按钮。
- 查清当前页面的堆叠上下文：用浏览器 DevTools 的 Layers 面板看哪些元素生成了新 stacking context
- 保守策略：
z-index: 1050足够高于主流框架（Bootstrap 默认模态框是 1050，Ant Design 是 1000） - 若页面用了 Shadow DOM 或 Web Component，z-index 不跨边界，此时需在组件内部单独设
真正难的不是定位，是状态同步：用户快速连点两次，JS 可能生成两个实例；关闭后没解绑 mousemove 监听器，内存泄漏就来了；用 display: none 隐藏而非 remove()，下次 show 又得重复绑定事件——这些细节不处理，问题只在灰度期偶发，上线后才集中爆发。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
