自定义滚动条不会改变盒模型宽度，所谓“变窄”实为浏览器预留滚动条空间或父级盒模型影响所致；应确保容器尺寸可控、避免全局设置，并注意移动端兼容性限制。
直接给容器加 ::-webkit-scrollbar 不会改变盒模型宽度——它只是绘制在原有滚动区域上的覆盖层，不影响 width、padding 或 border 计算。
为什么自定义滚动条后元素宽度“变窄”了
这不是 ::-webkit-scrollbar 本身导致的，而是浏览器在渲染时为滚动条预留了空间（即使你没显式设 overflow）；更常见的是：容器设置了 width: 100%，但父级有 padding 或 border，而子元素又没设 box-sizing: border-box，导致视觉上“挤窄”。
-
::-webkit-scrollbar的width/height值仅控制伪元素自身尺寸，不触发重排（reflow），也不修改盒模型 - 真正影响布局的是
overflow属性值：当设为auto或scroll且内容溢出时，浏览器才可能在视口内“挤占”可用宽度（尤其在垂直滚动条常驻的 macOS 上） - macOS 默认启用“自动隐藏滚动条”，但 Safari/Chrome 仍会在计算布局时预留约 15px 空间（取决于系统设置），这个行为无法用 CSS 关闭
如何确保滚动条样式不干扰现有布局
关键不是“隐藏滚动条”，而是“不让它参与盒模型计算”。最稳的做法是保持容器尺寸完全由内容或显式声明控制，滚动条纯属视觉叠加。
- 给滚动容器设
overflow-y: overlay（仅 WebKit 支持）——滚动条浮在内容上方，不占空间；但注意：该值在 Chrome 120+ 已被废弃，Safari 仍支持，实际项目中慎用 - 更通用方案：用
overflow-y: auto+ 固定容器width，并确认父级没有意外的padding-inline或margin挤压 - 避免对
html或body直接写::-webkit-scrollbar，它们的盒模型受文档流和 UA 样式影响更大；优先作用于明确高度约束的div容器 - 检查 DevTools 的 Layout 面板，看“Computed”里的
width和 “Layout Shifts” 是否真由滚动条引起——大概率是scrollbar-gutter或系统级留白在作祟
移动端 Safari 和 Chrome 的现实限制
iOS Safari（截至 iOS 17.5）和 Android Chrome（v120+）已基本禁用 ::-webkit-scrollbar 的样式能力，即使写了也只渲染默认滑块，且不响应 hover 或 border-radius。这意味着：你在桌面调试完美的圆角淡蓝滚动条，在真机上大概率退回原生灰色细条，还带惯性回弹。
立即学习“前端免费学习笔记（深入）”；
- 不要为移动端依赖
::-webkit-scrollbar实现交互反馈（比如点击滑块跳转） - 若需统一行为，必须降级到 JS 方案（如
simplebar），但它会替换原生滚动，带来position: sticky失效、scrollIntoView行为偏移等副作用 - Android WebView（基于 Chromium）部分版本仍支持，但行为不一致；建议用
@supports selector(::-webkit-scrollbar)做特性检测，而非 UA 判断
真正容易被忽略的点是：::-webkit-scrollbar 的生效前提是“滚动容器必须真实触发滚动”，而这个触发条件在 flex/grid 布局里极易被高度约束破坏——比如父容器 display: flex; flex-direction: column，子容器设了 flex: 1 却没给父级设 height，那子容器根本不会产生滚动，伪元素自然不渲染，你调半天 width 都是白忙。
