fixed定位被祖先transform劫持导致calc失效，因transform/perspective/filter会创建新包含块，使fixed降级为相对定位；应将悬浮球插入body直系子节点或改用absolute+js动态计算。
fixed定位被祖先transform劫持导致calc失效
不是calc()写错了，是它算出来的值被父级transform、perspective或filter拦截了——只要从body到悬浮球之间任意一层有这些属性，position: fixed就降级为相对该层定位，calc(100vw - 56px)这种视口计算完全失准。
快速验证：选中悬浮球元素，在控制台运行getComputedStyle(el.parentElement).transform !== 'none'，逐层往上查；Chrome DevTools 的 “Layers” 面板能直接看到它被塞进了哪个合成层。
- 最稳解法：把悬浮球节点用 JS 插入到
document.body直接子级，彻底绕过干扰 DOM - 若必须嵌套，改用
position: absolute+getBoundingClientRect()动态更新left/top，并监听scroll和resize - 禁用所有带
transform: translateZ(0)或filter: drop-shadow()的 wrapper，它们常被误用作“硬件加速”却悄悄创建新包含块
calc(100vw - X)在移动端实际不可靠
calc(100vw - 56px)看似优雅，但在 iOS Safari 和部分安卓 WebView 中，100vw 会包含滚动条宽度（即使滚动条隐藏），导致右侧偏移量多出 12–16px；横屏切换时更糟，vw 值重算但 fixed 元素不重绘，按钮瞬间“跳位”。
真实场景下，right 值应优先响应安全区和系统缩放，而非视口宽度：
- 用
right: clamp(20px, 5vw, 40px)替代calc()，兼顾小屏不遮滚动条、大屏不贴边太紧 - iOS 必加：在悬浮球上设
bottom: calc(24px + env(safe-area-inset-bottom))，同时给body加padding-bottom: env(safe-area-inset-bottom) - 禁用
right: 5%—— 百分比在某些旧版 WebView 中解析为父容器宽度，而 fixed 的父容器本该是视口，逻辑错乱
calc动态值无法响应键盘弹出和缩放变化
表单页底部悬浮球最常踩坑：用户点击输入框唤起软键盘，页面被顶起，但 calc(100vh - 80px) 这类基于 vh 的写法不会自动修正，按钮卡在键盘上方或被遮挡；开启系统“放大字体”辅助功能后，vw/vh 值也不随缩放实时更新。
此时不能依赖纯 CSS 计算，必须交由 JS 控制：
- 监听
focusin事件，检测是否为input或textarea，动态调整悬浮球bottom值 - 用
window.visualViewport?.height替代innerHeight，它能实时反映键盘顶起后的可视区域高度 - 避免
transition: all，只对bottom和opacity做过渡，否则低端机动画掉帧明显
z-index + calc组合在复杂层级中失效
当悬浮球和弹窗都用 calc() 定位，又共用同一套 z-index 值（比如都设 z-index: 999），很容易被其他 fixed 元素（如广告条、导航栏）压住——z-index 不是全局序号，而是层叠上下文内的局部值。
关键点在于层级锚定：
- 悬浮球和弹窗 DOM 节点必须同级挂载在
document.body下，不能一个在#app里、一个在#header里 - 设
z-index: 2147483647（JavaScript 最大安全整数）给悬浮球，弹窗设z-index: 2147483648，绕过浏览器对小整数的渲染 bug - 全局重置规则如
* { z-index: auto }必须禁用，它会破坏 fixed 元素默认的层叠上下文预期
真正难调的是 env(safe-area-inset-*) 在不同 iOS 版本下的返回值差异，以及 transform 祖先对 fixed 的隐式劫持——这两处不拿 iPhone 8 到 16、Android 10–14 真机逐个测，上线后必出问题。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
