滚动条出现时的布局偏移本质是100vw与100%计算基准不一致导致的宽度跳变，需用padding-right: calc(100vw - 100%)在直接父容器上补偿，或现代浏览器用scrollbar-gutter: stable。
直接结论：滚动条出现时的布局偏移，本质是 100vw 与 100% 计算基准不一致导致的宽度跳变，不是 bug，但必须主动补偿。
为什么 100vw 和 100% 在滚动条出现时表现不同
浏览器对这两个单位的计算逻辑完全不同：
-
100vw始终等于视口完整宽度（含滚动条区域），哪怕滚动条还没出现 -
100%是相对于父元素内容区宽度（不含滚动条），所以当滚动条弹出，父元素可用宽度立刻缩小约17px - 差值就是滚动条宽度：
100vw - 100%—— 这个值在无滚动条时为0，有滚动条时为正数 - 如果你用
width: 100vw做全宽容器，又用margin: 0 auto居中内部内容（它按100%算），滚动条一出，左右不对齐就立刻发生
calc(100vw - 100%) 补偿法的实际写法和限制
这是目前最通用、零 JS、兼容 IE10+ 的纯 CSS 解法，但必须写对位置和上下文：
- 不要加在
html或body上，而是加在需要稳定宽度的**直接父容器**上，比如.main-container - 关键样式是：
padding-right: calc(100vw - 100%); box-sizing: border-box; - 必须确保该容器没有
overflow: hidden，否则会把补偿 padding 也裁掉 - 如果容器本身用了
transform或will-change，某些旧版 Safari 可能不触发重算，需加force-redraw类临时刷新 - 注意：Firefox 对
calc()中单位混合支持较弱，避免写成calc(100vw - 100% + 1px)这类带绝对值的表达式
scrollbar-gutter: stable 是什么情况下该用
这是现代浏览器（Chrome 94+、Firefox 97+、Safari 16.4+）原生支持的“滚动条槽”机制，比 calc 更干净，但有明确适用边界：
- 只对设置了
overflow-y: auto或scroll的容器生效，对overflow: visible无效 - 必须作用于**滚动容器本身**，比如
.list-wrapper { overflow-y: auto; scrollbar-gutter: stable; } - 不能替代
calc用于全屏宽度布局（如header或footer），因为scrollbar-gutter不影响非滚动容器的宽度计算 - 在 iOS Safari 16.4+ 上支持良好，但低于此版本会完全忽略，需用 JS 检测并 fallback 到
calc方案 - 如果同时用了
overflow: overlay（已废弃），scrollbar-gutter会被禁用
移动端真机上最容易被忽略的细节
模拟器看不出，但 iPhone / Android 真机会暴露三个硬伤：
- iOS Safari 中，
document.documentElement.clientWidth在键盘收起瞬间有30~50ms延迟，直接读可能拿到旧值；动态补宽时建议加setTimeout(() => { updatePadding(); }, 60) - 某些 Android WebView（尤其厂商定制版）对
calc(100vw - 100%)解析不稳定，可先用 JS 计算一次差值缓存为 CSS 变量：document.documentElement.style.setProperty('--scrollbar-width', (window.innerWidth - document.documentElement.clientWidth) + 'px'); - Vant / NutUI 等 UI 库的
popup或drawer组件内部用了position: fixed+transform，会干扰外层滚动容器的scrollbar-gutter生效，此时只能退回到padding-right手动补偿
真正难的不是选哪个方案，而是判断「谁才是那个该负责宽度稳定的容器」——它往往不是最外层的 html，而是某个中间的 flex 子项或 grid 区域。一旦定位错层级，所有补偿都会失效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
