滚动条宽度不计入 width 样式值，但会挤占 content 区域；clientWidth 自动减去滚动条宽度，offsetWidth 则包含滚动条；使用 scrollbar-gutter: stable 可避免布局抖动。
滚动条宽度是否计入元素 width 样式值
不包含。你写的 width: 300px 永远只代表内容区（content）宽度，滚动条**不是** width 的一部分，也不会被算进这个声明里。但滚动条会实实在在“挤占”可用空间——它从 content 区域内部或 padding 区域内“抠出”一块地方来显示，导致实际可渲染内容变窄。
滚动条如何影响 offsetWidth 和 clientWidth
这是最容易混淆的实操点：
-
clientWidth：包含padding-left + content-width + padding-right，但自动减去滚动条宽度（如果存在）。也就是说，有滚动条时，clientWidth会比没滚动条时小（差值≈滚动条宽度）。 -
offsetWidth：包含border + padding + content-width，但不扣除滚动条——它反映的是元素在页面上“占了多少像素”，滚动条是附着在这个盒子上的视觉组件，属于该盒子的渲染输出，所以它被算进去了（注意：不同浏览器对滚动条是否计入offsetWidth曾有分歧，但现代 Chromium/Firefox/Safari 均一致计入）。
为什么加了 overflow:auto 就出现横向抖动
根本原因是：滚动条出现与否，改变了 clientWidth（进而影响布局计算），而父容器又没预留空间。比如一个 width: 100% 的卡片，在内容刚好溢出时突然出现垂直滚动条，它的 clientWidth 缩水约 12–17px（取决于系统），导致内部 flex/grid 子项重排、文字换行、图标错位。
- 强制显示滚动条：
html { overflow-y: scroll }（最简单，但略显生硬） - 现代推荐方案：
scrollbar-gutter: stable—— 浏览器自动在右侧预留滚动条位置，不改变布局流，且支持env(scrollbar-width)获取宽度做精细适配 - 避免依赖 clientWidth 做关键布局：比如用
getBoundingClientRect().width更稳定；或改用scrollWidth判断是否溢出（它不含滚动条，但包含全部内容）
box-sizing: border-box 能不能解决滚动条问题
不能直接解决。它只控制 width 是否包含 padding 和 border，和滚动条占位无关。但它能减少“因 padding 导致的意外溢出”，从而间接降低滚动条触发概率。
立即学习“前端免费学习笔记（深入）”；
- 错误写法：
width: 100%; padding: 16px;（content-box下总宽 = 100% + 32px → 溢出） - 正确基础：
box-sizing: border-box全局设置（如* { box-sizing: border-box }），再配合scrollbar-gutter: stable - 特别注意：表单控件（
input,textarea）默认是content-box且难以继承，需单独重置
滚动条不是“装饰”，它是盒模型中一个有真实物理尺寸、会参与渲染流的组件。很多人卡在“以为它只是 overlay”，结果在 resize 监听、动画宽度计算、SSR 客户端 hydration 差异等场景反复踩坑。真正稳定的方案，从来不是靠 JS 临时 patch，而是从 CSS 层级就声明好它的存在感。
