position: fixed 在现代浏览器中稳定，但受祖先样式、移动端合成层及 iframe 影响；iOS Safari/微信中抖动或偏移源于 containing block 被 transform 等属性意外更改，导致 fixed 不再相对视口定位。
position: fixed 在绝大多数现代浏览器中能稳定实现侧边悬浮，但实际表现受祖先元素样式、移动端渲染机制和 iframe 环境干扰——不是写错，是定位基准被悄悄改了。
为什么 fixed 按钮在 iOS Safari 或微信里“滚动时抖动”或“突然偏移”
根本原因是 Safari 和部分 WebView 对 position: fixed 的实现依赖于页面是否触发了合成层（compositing layer），而 transform、perspective、will-change 甚至 overflow: hidden 都可能意外创建新 containing block，让 fixed 元素不再相对于视口，而是相对于那个带 transform 的父容器定位。
常见现象包括：
- 按钮在滚动中轻微跳动或延迟响应
- 右下角按钮贴着 header 下边缘，而不是 viewport 底边
- 展开客服面板后，按钮位置“上移一段距离”
排查方法：打开开发者工具 → Elements → 选中按钮 → Computed 面板看 position 是否真为 fixed，再看 containing block 是不是 body 或 html。如果不是，往上逐级检查 transform、filter、will-change。
立即学习“前端免费学习笔记（深入）”；
移动端适配：right + bottom 不等于“永远右下”
在小屏设备上，right: 24px; bottom: 24px 容易被虚拟键盘顶起、被浏览器地址栏遮挡，或手指误触区域太小。
必须加的适配项：
-
@media (max-width: 768px)下把bottom改为80px，留出操作安全区 - 给按钮加
touch-action: manipulation，禁用双击缩放和长按菜单 - 最小点击区域不小于
48px × 48px，哪怕视觉尺寸是 40px，也用padding或伪元素撑开 - 避免用
left: auto—— 浏览器根本不识别这个值，right才是明确声明方向
iframe 或 shadow DOM 场景下 fixed 失效怎么办
如果客服按钮嵌在 iframe 里，或客服面板用 shadow DOM 渲染（比如某些 Vue/React Portal 封装），position: fixed 会相对于 iframe 的视口或 shadow root 定位，而非顶层页面。
可行解法：
- 按钮本身仍挂载到
document.body，通过 postMessage 与 iframe 内逻辑通信 - 用
getBoundingClientRect()+window.addEventListener('scroll')手动更新 top/left（仅 fallback，性能差） - 检查第三方 SDK（如美洽、快商通）是否默认插入到
body下；若插在某个 wrapper 里，需手动document.body.appendChild(elt)迁移 - Vue 中慎用
v-if控制整个悬浮组件显隐——DOM 销毁重建会导致 transition 动画丢失，改用v-show+ class 切换
z-index 显得“没用”？大概率 stacking context 错了
z-index 只在同一个 stacking context 内生效。如果按钮父容器有 z-index: 10 且设置了 position: relative，那按钮即使设 z-index: 9999，也只在那个父容器的层叠上下文里排第 1，整体仍可能被另一个 z-index: 100 的 modal 压住。
关键动作：
- 确保悬浮容器直接挂载在
document.body下，别塞进<header>或带transform的 layout wrapper - 检查是否有祖先元素设置了
opacity < 1、filter、transform—— 这些都会隐式创建新的 stacking context -
z-index: 999999不是万能解，反而可能压住 devtools 面板或全屏视频控件；1000–2147483647区间内取整数即可
最常被忽略的一点：fixed 元素的定位基准不是“写在哪”，而是“算出来在哪”——它由浏览器 runtime 实时计算 containing block，而这个 block 很可能不是你肉眼看到的父元素。
