一个后台管理页的列表容器固定宽度 960px，左侧是筛选栏，右侧是数据表格。当筛选结果从 8 条变成 80 条时，垂直滚动条出现，容器可用的内联尺寸减少约一个滚动条宽度，表格列被重新分配宽度，筛选栏也向右挤了一点。用户看到的是整块内容横向抖动一下。把系统滚动条设置改成 macOS 默认的 overlay 风格后，这个抖动消失了，但换到 Windows 或 Linux 上又出现。同一份 CSS 在不同平台表现不一致，原因不在布局代码，而在滚动条占不占空间。
滚动条占位与 gutter 的位置
浏览器把滚动条分成两类。经典滚动条（classic scrollbar）始终占据布局空间：它被放在一个叫 scrollbar gutter 的区域里，这个区域位于元素的内边框边缘（inner border edge）和外内边距边缘（outer padding edge）之间。滚动条出现时，gutter 的宽度等于滚动条宽度，内容区因此变窄。overlay 滚动条则画在内容之上，不进入 gutter，通常半透明，只在滚动时短暂可见。
MDN 明确说明，浏览器自行决定使用经典还是 overlay 滚动条，作者无法用 CSS 直接切换。macOS 的“始终显示滚动条”系统设置会切到经典滚动条，默认设置则是 overlay；Windows 和多数 Linux 桌面环境默认使用经典滚动条。这解释了一个常见困惑：开发者在 macOS 上调试时看不到跳动，交付后收到 Windows 用户的反馈。
scrollbar-gutter 属性控制的是 gutter 的渲染，而不是滚动条本身。滚动条是否出现仍由 overflow 决定。该属性只作用于滚动盒子（scrolling boxes），不继承，初始值为 auto。
为什么内容增长会触发横向跳动
默认值 auto 的行为是：使用经典滚动条时，若 overflow 为 scroll，或 overflow 为 auto 且盒子确实溢出，就创建 gutter；不溢出时不创建。于是“内容变长”这件事同时改变了两件事——纵向出现滚动条，横向可用宽度减少。
对固定宽度布局来说，这种耦合会放大影响。假设容器 width: 960px、box-sizing: border-box，内部用 flex 分成 240px 的侧栏和自适应主区。滚动条出现后，内容盒宽度从 960px 降到 960px 减去滚动条宽度，主区变窄，表格的列宽按比例重算，文本换行位置改变，行高随之变化。如果侧栏里有 position: sticky 的元素，它的水平位置也会移动。
这里的偏移不是动画，也不是 JS 改样式造成的，而是布局在两次计算之间使用了不同的可用宽度。它属于累积布局偏移（CLS）的来源之一，但和图片未设尺寸、字体替换引起的偏移机制不同：后两者改变的是元素自身尺寸，滚动条改变的是包含块的可用空间。
stable 与 both-edges 的实际语义
scrollbar-gutter: stable 的语义是：使用经典滚动条时，只要 overflow 为 auto、scroll 或 hidden，无论盒子当前是否溢出，gutter 都保留。滚动条只在真正需要时才绘制，但它的空间已经提前占住，因此内容增长不会引起横向位移。
MDN 特别指出，当使用 overlay 滚动条时，stable 不会产生 gutter。也就是说该属性在 macOS 默认设置下等于没写。这不是 bug，而是规范定义：overlay 滚动条本来就不占空间，没有需要预留的东西。
both-edges 是修饰值，必须与 stable 组合使用。它的作用是：如果盒子某一侧（inline start 或 inline end）会保留 gutter，那么另一侧也保留等宽空间。这解决两个具体问题。
一是居中对称。一个 max-width: 720px; margin: 0 auto 的正文容器，滚动条只在右侧占位时，视觉上文字块会相对视口偏左；stable both-edges 在两侧各留一份，文字块重新居中。
二是相邻元素对齐。MDN 的示例给出两个并排的 div：左侧 overflow: hidden 不滚动，右侧可滚动。两者都写 scrollbar-gutter: stable，左侧即使没有可滚动内容也保留 gutter，于是两个盒子的内容宽度一致，边界对齐。
需要注意传播规则：与 overflow 不同，浏览器不会把 scrollbar-gutter 从 body 传播到视口。若想为整个视口预留空间，应把属性设在根元素（html）上，而不是依赖 body。
一次内容增长中的状态变化
下面用贯穿场景走一遍流程：固定宽度列表页，初始 8 条记录，用户点击“加载更多”后变为 80 条。
flowchart TD
A[初始渲染 8 条记录] --> B{内容是否溢出容器}
B -->|否| C[auto 不创建 gutter]
B -->|否| D[stable 保留 gutter 不绘制滚动条]
C --> E[用户点击加载更多]
D --> E
E --> F[内容高度超过容器]
F --> G[auto 创建 gutter 并绘制滚动条]
F --> H[stable 绘制滚动条 gutter 已存在]
G --> I[可用宽度减少 内容横向重排]
H --> J[可用宽度不变 无横向位移]
关键转折在 F 之后。auto 路径下，gutter 的创建和滚动条的绘制同时发生，可用宽度在同一帧内变化，布局必须重算。stable 路径下，gutter 在初始渲染时就已存在，F 只改变滚动条是否绘制，不改变宽度，因此不触发横向重排。
用 overlay 滚动条时，流程在 B 处就走向另一条分支：无论 auto 还是 stable，都不创建 gutter，滚动条绘制在内容之上，可用宽度始终不变。这既解释了 macOS 上“看不到问题”，也说明该属性对 overlay 用户是空操作。
与 padding 方案的对比
在 scrollbar-gutter 出现前，常见做法是给容器加固定 padding-right，或对根元素用 overflow-y: scroll 强制始终显示滚动条。
| 方案 | 预留行为 | 不溢出时的表现 | 主要代价 |
|---|---|---|---|
scrollbar-gutter: stable | 仅经典滚动条下保留 gutter | 保留空间但不绘制滚动条 | overlay 环境下无效；需设在正确的滚动盒子上 |
固定 padding-right | 始终占用指定宽度 | 永久占用，可能与真实滚动条宽度不符 | 宽度写死，滚动条宽度随平台和缩放变化；overlay 下多出空白 |
overflow-y: scroll | 强制创建 gutter 并绘制滚动条 | 始终显示滚动条轨道 | 视觉上始终有滚动条，即使内容很短 |
不做处理（auto） | 溢出时才创建 | 无额外空间 | 内容增长时横向位移 |
固定 padding-right 的失效条件很明确：滚动条宽度不是常量。它随操作系统、浏览器、显示缩放和用户设置变化，写死 15px 或 17px 都可能偏大或偏小，偏小仍会位移，偏大则留下无法解释的空白。overflow-y: scroll 能保证宽度稳定，但代价是短内容页面也一直显示滚动条轨道，在移动端尤其突兀。
scrollbar-gutter: stable 让浏览器按当前环境的真实滚动条宽度预留，不需要作者猜测数值，这是它相对 padding 方案的主要收益。代价是它只处理经典滚动条，且需要作者理解作用对象。
诊断、失败模式与边界
判断页面是否受此问题影响，可以在经典滚动条环境下观察三个信号。第一，在容器内容从不足一屏变为超过一屏的瞬间，用开发者工具的 Layout 面板记录布局偏移，看是否出现非零的 CLS 贡献。第二，切换系统滚动条设置为“始终显示”，对比同一页面是否出现横向位移；若只有经典模式复现，基本可定位到 gutter。第三，检查 scrollbar-gutter 是否写在了 body 上——由于不传播，这样写不会生效，应移到 html 或实际的滚动容器。
常见失败模式包括：
- 把
scrollbar-gutter写在非滚动盒子上。该属性只对滚动盒子生效，父元素写了不会影响子滚动容器。 - 期望它在 macOS 默认设置下生效。overlay 滚动条不占空间，属性无效果。
- 与
overflow: hidden混用时误判。stable在hidden下也会保留 gutter，这可能正是想要的（对齐相邻盒子），也可能带来意外空白。 - 只写
both-edges而漏掉stable。语法上both-edges是修饰值，单独使用不构成有效组合。
浏览器支持方面，MDN 将该属性标记为 Baseline 2024，自 2024 年 12 月起在最新设备和浏览器版本中可用，旧版本可能不支持。资料 3 记录的是更早的状态：当时该功能仅在 Chromium 88+ 且需通过实验标志启用。这说明支持范围随时间变化，落地前应查目标浏览器版本，而不是依赖旧文章的描述。
不适用或收益有限的情况也需要明确。若页面本身使用 overlay 滚动条，或滚动区域宽度自适应、内容重排不敏感，预留 gutter 带来的收益很小。若滚动容器宽度由 fit-content 或 max-content 决定，gutter 会参与尺寸计算，可能改变容器自身宽度，需要单独验证。
落地建议
对固定宽度布局的滚动容器，优先在滚动盒子上写 scrollbar-gutter: stable；需要内容块相对视口居中，或需要让相邻的可滚动与不可滚动盒子边界对齐时，用 stable both-edges。为整个视口预留空间时，把属性设在 html 上。
不要用它替代对 overlay 环境的处理。如果产品需要在所有平台都避免横向位移，仍需接受 overlay 下“本来就不位移、但滚动条覆盖内容”这一事实，并在设计上为覆盖式滚动条留出视觉余量。
上线前至少在两套环境验证：一套经典滚动条（Windows 或 macOS 设为始终显示），一套 overlay 滚动条。前者验证预留是否生效，后者验证是否出现多余空白或对齐异常。把“系统滚动条设置”写进测试清单，比在代码里猜测滚动条宽度更可靠。