CSS scrollbar-gutter 怎样避免滚动条出现时布局横向跳动

如果一个弹窗打开后，页面内容突然向左或向右挪了一点，先不要急着用 JavaScript 读取滚动条宽度。很多时候，真正改变的是经典滚动条是否占用布局空间。要让滚动条出现前后保持同一套盒模型，通常把 scrollbar-gutter: stable 放到真正负责滚动的容器上；需要左右保持对称时，再使用 stable both-edges。

这篇只解决一个边界：内容变多或变少时，滚动条从不显示变成显示，怎样避免页面横向跳动。它不讨论滚动条换肤，也不建议用脚本测量每台设备的滚动条宽度。

先看清楚横向跳动来自哪一个盒子

基线可以这样理解：使用经典滚动条时，滚动条位于元素的内边框与外内边距之间，会占用一部分布局宽度；使用覆盖式滚动条时，滚动条叠在内容上方，通常不改变内容的可用宽度。于是，同一个 overflow: auto 容器，在两种滚动条模式下会有不同的视觉结果。

这也是为什么只给 body 加一个背景色，或者只把 overflow-y: scroll 写在页面外层，常常不能解决局部弹窗和长列表的问题：发生变化的可能是弹窗内部、侧栏内部或某个卡片列表，而不是文档根元素。

先用下面三个问题定位范围：

• 横向位移发生在页面主列，还是只发生在滚动列表内部？
• 滚动条出现时，内容宽度是否少了一个经典滚动条槽位？
• 布局是否要求内容始终居中，或者左右两侧必须看起来对称？

用 stable 让滚动容器提前保留单侧槽位

scrollbar-gutter: stable 的重点不是强制画出滚动条，而是让使用经典滚动条的滚动盒子在没有溢出时也保留可用槽位。这样，内容从短列表变成长列表时，内容区和外部布局不必重新争夺这一段宽度。

.result-list {
  /* 让列表自己负责滚动，避免把问题误判成页面根节点问题 */
  overflow: auto;
  /* 经典滚动条出现前后，提前保留单侧滚动条槽位 */
  scrollbar-gutter: stable;
  /* 让内部内容仍按组件自己的内边距布局 */
  padding: 1rem;
}

这里有两个容易漏掉的细节。第一，scrollbar-gutter 应该放在滚动盒子上，而不是随手放在一个没有滚动职责的祖先元素上。第二，stable 处理的是经典滚动条占位；如果当前平台使用覆盖式滚动条，预留槽位可能不会产生可见宽度变化，这是滚动条实现方式决定的结果，不是属性失效。

当列表与旁边的非滚动面板需要严格对齐时，可以让两者共享同样的单侧空间策略：

.panel,
.panel-list {
  /* 两个相邻面板用相同的内侧空间，避免列边界错开 */
  scrollbar-gutter: stable;
}

.panel-list {
  /* 只有列表需要滚动，滚动职责仍留在列表自身 */
  overflow: auto;
}

需要居中时再选择 stable both-edges

单侧预留适合内容从左侧或右侧对齐的列表，但有些页面的主内容要保持视觉居中。例如，一个居中的设置面板旁边有一个滚动列表，如果只有一侧增加槽位，内容看起来会向另一侧偏移。这时可以使用 stable both-edges，让内联起始侧和内联末侧都保留对应空间。

.settings-list {
  /* 列表在内容变长时出现滚动条，但布局两侧保持对称 */
  overflow: auto;
  scrollbar-gutter: stable both-edges;
}

both-edges 不是“把滚动条画两遍”，而是当一侧存在滚动条槽位时，在相反的内联边也保留一个对应槽位。它更适合需要对称留白的组件，不适合所有列表：如果组件本来就贴着一侧边界，额外的另一侧留白反而会扩大与邻接内容的距离。

把属性放在正确的滚动边界上

项目中最常见的误区，是看到页面跳动就把属性加到 body，但真正的滚动元素可能是一个固定高度的对话框内容区。判断滚动边界时，可以沿着以下结构读 CSS：

.dialog {
  /* 弹层本身负责定位，不直接承担内容滚动 */
  position: fixed;
  inset: 10vh auto auto 50%;
  width: min(32rem, 90vw);
}

.dialog__body {
  /* 固定高度约束下，真正产生滚动的是这个内容区 */
  max-height: 70vh;
  overflow: auto;
  /* 预留内容区自己的滚动槽位，避免弹层内部宽度抖动 */
  scrollbar-gutter: stable;
}

如果把 scrollbar-gutter 放在外层 .dialog，而 .dialog__body 才是滚动盒子，外层不一定会替内层保留槽位。组件库封装时尤其要把“谁设置了 overflow”和“谁设置了 scrollbar-gutter”放在同一层考虑。

用 @supports 做能力分层，不靠脚本补偿宽度

scrollbar-gutter 属于较新的 CSS 能力，MDN 将它标为 Baseline 2024，同时也提醒旧设备或旧浏览器可能不支持。稳妥做法是让基础布局先保持可用，再在支持时启用槽位策略。

.page-shell {
  /* 基础降级：内容仍可滚动，不能依赖新属性才能使用 */
  overflow: auto;
}

@supports (scrollbar-gutter: stable) {
  .page-shell {
    /* 支持新属性的浏览器再固定经典滚动条的布局槽位 */
    scrollbar-gutter: stable;
  }
}

这里不建议用脚本计算 window.innerWidth - document.documentElement.clientWidth，再把结果写入全局 padding-right。那种方案会把滚动条实现、缩放、嵌套滚动容器和页面方向判断都推给 JavaScript，维护成本比在滚动盒子上声明 CSS 关系更高。只有在必须兼容完全不支持该属性的旧环境，并且页面确实需要强制视觉补偿时，才应该把脚本方案作为明确的降级层。

按这张表复查布局位移

几个容易混淆的问题

scrollbar-gutter: stable 会强制显示滚动条吗？

不会把 overflow:auto 变成必须显示滚动条的 overflow:scroll。它表达的是经典滚动条槽位是否提前保留，实际滚动条是否呈现仍由溢出和平台滚动条实现共同决定。

为什么在 macOS 上看不到预留效果？

如果系统使用覆盖式滚动条，滚动条通常覆盖在内容上，不占用布局槽位，因此 stable 可能没有明显的宽度变化。不要拿这种环境的视觉结果去推断经典滚动条设备上的布局行为。

页面根节点和局部滚动列表都要设置吗？

不一定。先找出发生宽度变化的滚动盒子，再只在需要稳定布局的边界设置。页面整体滚动和局部列表滚动是两个不同的 CSS 盒子，不能因为都出现了滚动条就混为一个问题。

最后可以把决策压缩成一句话：滚动条出现前后需要保持同一宽度，就在真正的滚动容器上使用 stable；内容需要左右对称，就使用 stable both-edges；旧环境则用 @supports 把它作为渐进增强。