网页内容在滚动条出现和消失的瞬间左右跳动，这种体验很让人抓狂——尤其是在弹窗、侧边栏或长列表场景中。表面上是视觉宽度变化的问题，底层逻辑其实是浏览器在“决定是否需要滚动条”那一瞬间，重新计算了可用空间。
好在，CSS 从规范层面提供了一个解决方案：scrollbar-gutter: stable。它不走 JavaScript 补丁路线，直接从布局机制上解决问题。但实际用的时候，坑也不少，并不是一行代码就能万事大吉的。下面把几个关键点拆开讲清楚。
scrollbar-gutter: stable 为什么能防跳动
滚动条出现和消失的瞬间，内容区域之所以会左右晃动，根本原因在于浏览器在可用宽度上做了一个“有无滚动条”的切换。scrollbar-gutter: stable 做的事其实很简单：告诉浏览器，不管当前屏幕是否需要滚动条，都先把这个槽位空间留出来，算进盒模型的 padding-box 里，但不侵占 content 区域。这样一来，内容区的宽度就成了固定值，不再随滚动状态变化。
它不是隐藏滚动条，也不是强制显示滚动条，而是把“占位”这个动作从滚动状态解耦出来，变成布局的固有属性。兼容性方面，Firefox 111+、Chrome 94+、Safari 16.4+ 都能直接用，不需要任何 JS 垫片。
怎么写才真正生效：关键组合与常见失效点
很多人写完 scrollbar-gutter: stable 发现没反应，其实不是属性不对，是少了一个关键辅助——overflow 行为。必须配合 overflow-y: auto 或 overflow-y: scroll 才能激活预留逻辑，单独写 overflow: visible 或 hidden 时，gutter 是激活不了的。
比较推荐的写法是：overflow-y: auto + scrollbar-gutter: stable，这样滚动条按需出现，空间始终预留。尽量避免写成 overflow-y: scroll + scrollbar-gutter: stable的组合，因为前者已经强制占位了，后者就成了冗余配置，在部分旧版 Safari 里还可能冲突。
还有一个细节容易被忽视：如果容器的高度不固定（比如用了 min-height: 100vh），需要确保父级撑开高度，否则 gutter 预留的空间可能会被压缩或直接忽略。
both-edges 什么时候该用，什么时候别乱加
scrollbar-gutter: both-edges 会在左右两侧各留一个滚动槽空间，主要用于双向文本混排（RTL/LTR）或需要严格居中的场景。普通单向页面用它，反而会多出一段完全无必要的空白。
场景判断：表格页、有侧边栏+主内容区对齐的仪表盘页面，both-edges 能保证左右 padding 对称，避免因单侧 gutter 导致的视觉偏移。但如果是纯粹从左到右排版的正文容器，stable 已经足够了，再加 both-edges 只会让内容区变窄约 30px（双侧各15px左右），在窄屏下效果尤其明显。
一个铁律：不要给 body 或 html 直接设 both-edges，除非你确认整个页面确实需要双边预留——这种情况极为少见。
不支持 scrollbar-gutter 的老浏览器怎么兜底
IE 全系当然不支持、部分旧版 Firefox 也需要兜底。这时候最常见的错误做法是直接硬写 padding-right: 17px。问题在于滚动条宽度是浮动的——macOS 系统设置中滚动条隐藏时宽度是0，Windows 下可能是12到20px不等，写死数值就等于换一种方式制造偏差。
靠谱的做法有三种，优先级从高到低排列：
- 用
document.documentElement.clientWidth - document.documentElement.offsetWidth实时测量真实滚动条宽度，动态设置padding-right - 次选方案：强制常驻滚动条 + 视觉隐藏，比如
overflow-y: scroll配合::-webkit-scrollbar { width: 0 }和::-moz-scrollbar { width: 0 } - 如果完全不想为老浏览器折腾，可以用
@supports not (scrollbar-gutter: stable)兜底，回退到overflow-y: scroll，接受轻微的视觉“胖瘦变化”，但至少能避免跳动带来的体验断层
最后提一个容易被忽略的情况：scrollbar-gutter 只负责空间预留，并不干涉滚动行为本身。如果发现加了之后还在跳动，大概率不是属性没生效，而是某个子容器的 overflow 设置覆盖了父级，或是用了 transform/position: fixed 等脱离文档流的元素绕过了 gutter 预留区域。
