fixed元素右移是body宽度突变所致，需用calc(100vw - 100%)补偿滚动条宽度，避免依赖left/right双值定位，并优先使用inset: 0和100dvh适配动态视口。
fixed 元素在弹窗（如 modal）打开时右移或错位，根本不是“定位失效”，而是 body 滚动被禁用后宽度突变导致的视觉偏移——必须用 calc(100vw - 100%) 补偿滚动条宽度，否则任何 left/right 调整都只是临时掩盖问题。
为什么弹窗一开 fixed 元素就往右跳？
当 modal 打开时，常见做法是给 body 加 overflow: hidden 防止背景滚动。但这个操作会触发浏览器移除垂直滚动条，导致 body 的 width 突然增大（因为原先滚动条占的 ~17px 空间被释放）。而 fixed 元素若依赖 left: 0; width: 100% 或 right: 0，其定位基准仍是视口，但周围文档流宽度变了，视觉上就像它“向右滑了一截”。
这不是渲染 bug，是盒模型行为的一致体现：fixed 元素不参与文档流，但它的 100% 宽度参考的是包含块（通常是 html），而 html 的宽度又受 body 渲染宽度影响。
-
100%是动态计算的，依赖父容器渲染后的实际宽度 -
100vw是静态的，始终等于当前视口宽度（含滚动条空间） - 所以
100%在滚动条出现/消失时会变，100vw不会
用 calc(100vw - 100%) 获取真实滚动条宽度
calc(100vw - 100%) 是目前最轻量、无需 JS、兼容性好（Chrome 26+/Firefox 16+/Safari 6.1+）的滚动条宽度探测方式。它在有滚动条时返回正值（通常 15–17px），无滚动条时为 0。
关键不是“获取值”，而是用它做补偿：
- 给
body加padding-right: calc(100vw - 100%)，让 body 宽度恒定，避免 modal 开启时突变 - 对 fixed 元素本身，可用
right: calc(100vw - 100%)把它从右边缘向左拉出滚动条宽度，避免遮挡（尤其 Windows 下） - 若 fixed 元素已设
left: 0; right: 0;，则无需额外补偿——因为它本就撑满视口，不会因 body 变宽而偏移
fixed 元素自身定位别同时写 left 和 right
这是横向滚动条和错位的高发区。例如：
.header {
position: fixed;
left: 0;
right: -10px; /* 错误：负 right 会反向推算 width */
width: 100%;
}
浏览器会忽略 width，按 left + width + right = 包含块宽度 反推，结果 width 变成 100% + 10px，触发横向滚动，modal 开关时更易暴露。
- 只用单边 +
width：比如left: 0; width: 100vw; - 或用双零边距：
left: 0; right: 0;（此时 width 自动为 100vw） - 避免
right为负值；若需微调，改用transform: translateX()
Safari 和移动端要额外防地址栏抖动
iOS Safari 在页面滚动时会隐藏/显示地址栏，导致视口高度变化，进而影响 100vh 和某些 fixed 元素的垂直定位。虽然你问的是“弹窗移位”，但 modal 常伴随 overflow: hidden，这会让 Safari 地址栏行为更不可控。
- 垂直方向别依赖
bottom: 0或top: 0+100vh，改用inset: 0（现代写法，等价于top: 0; right: 0; bottom: 0; left: 0） - 如果必须用
bottom，加min-height: 100dvh（dynamic viewport height）兜底，比100vh更适应地址栏变化 - 真机测试不能省：模拟器不触发地址栏收缩，也测不出滚动条宽度波动
真正难处理的，是那些通过 JS 动态写 style.right 的 UI 库组件——它们可能在 modal 打开瞬间覆盖你的 CSS 补偿逻辑，这时候得 hook 到库的 open/close 生命周期里重置样式。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
