滚动条宽度不一致引发布局偏移，根本原因是其占用视口水平空间（Chrome/Edge约17px、Firefox约16px、macOS Safari默认隐藏），导致body可用宽度突变；推荐优先使用html{scrollbar-gutter:stable both-edges}预留空间，不支持时降级为body{padding-right:calc(100vw-100%)}补位。
滚动条宽度不一致直接引发 layout shift
浏览器滚动条不是“透明存在”的——它真实占用视口水平空间。Chrome/Edge 默认约 17px，Firefox 约 16px，macOS Safari 默认隐藏（悬停才显示），这就导致：同一页面在不同环境、甚至同一页面加载前后（比如字体加载完成、动态内容插入后高度变化），body 的可用宽度可能突然收缩或扩张 16–17px。所有依赖 margin: 0 auto 居中的容器、position: fixed 导航栏、sticky 头部都会随之横向偏移，视觉上就是“抽搐一下”。
scrollbar-gutter: stable both-edges 是目前最干净的解法
这个 CSS 属性专为解决滚动条占位抖动而生，作用是**强制预留滚动条空间，无论滚动条是否实际出现**。它不改变滚动行为，只影响布局计算：
- 必须作用于滚动容器本身（通常是
html或body），写在div上无效 -
both-edges表示左右两侧都预留（实际只用右侧，但规范要求双侧对称） - 仅 Chromium 120+（即 Chrome 120 / Edge 120 起）原生支持；Firefox 和 Safari 尚未实现
- 兜底方案必须同步提供：比如
body { padding-right: calc(100vw - 100%); }
示例：
html {
scrollbar-gutter: stable both-edges;
}
<p>/<em> 兜底：兼容 Firefox/Safari/旧 Chromium </em>/
body {
padding-right: calc(100vw - 100%);
}
为什么不用 overflow-y: scroll 强制显示滚动条
这是最直白但副作用明显的办法：
立即学习“前端免费学习笔记（深入）”；
- 滚动条永远可见，破坏现代浏览器默认的“按需显示”体验（尤其 macOS 上用户已习惯悬停才出现）
- 在无内容溢出的页面，会多出一个不可拖动的灰色滑块，UI 显得冗余
- 某些设计系统（如 Ant Design、Mantine）内部依赖
overflow: auto判断是否启用滚动逻辑，硬设scroll可能干扰其行为 - 移动端 WebView（如微信内置浏览器）对
overflow-y: scroll渲染不稳定，偶发卡顿或失效
calc(100vw - 100%) 的兼容性与陷阱
这是目前跨浏览器最实用的 fallback 方案，但它不是万能的：
- Safari 16.4 之前不支持
100vw - 100%动态计算，页面加载时可能取值为0，需 JS 首次检测后写死：document.body.style.paddingRight = '17px' - 不能用在
margin-right上——它不参与 box model width 计算，无法撑开容器，只会把内容往左推 - 若页面有
transform: scale()或 iframe 嵌套，100vw可能被缩放影响，结果失准 - 当
html设了font-size缩放（如 rem 基准），不影响该计算，放心用
真正难处理的，是那些既要用 position: fixed 又要动态开关 body 滚动的场景（比如弹窗、抽屉菜单）——此时抖动往往来自 overflow: hidden 切换瞬间，scrollbar-gutter 和 calc 都得配合 padding-right 补位，缺一不可。
