scrollbar-thumb 和 scrollbar-track 的定位由浏览器根据滚动状态自动计算，非常规 CSS 定位；width/height 无效，仅 min-width/min-height 生效；padding 会导致滑块错位；overflow: hidden 会裁剪而非禁用伪元素。
scrollbar-thumb 和 scrollbar-track 的定位本质是伪元素布局
scrollbar-thumb 和 scrollbar-track 不是真实 DOM 节点，而是浏览器为 ::-webkit-scrollbar 系列伪元素提供的渲染钩子。它们的“定位”不走常规 CSS 定位流（position: absolute 无效），而是由浏览器根据滚动容器尺寸、内容高度和当前滚动偏移自动计算位置与大小。你无法用 top、left 或 transform 移动滑块——它只响应滚动状态变化。
- 滑块长度 =
track高度 × (viewportHeight/scrollHeight) - 滑块顶部偏移 =
track顶部 × (scrollTop/ (scrollHeight−viewportHeight)) - 这些计算完全由 UA 控制，CSS 只能影响外观（
background、border-radius、width等）
为什么给 scrollbar-thumb 设置 width/height 没效果？
在垂直滚动条中，scrollbar-thumb 的尺寸由浏览器强制锁定：它的高度由轨道和滚动比例决定，height 属性被忽略；同理，水平滚动条中 width 无效。你只能通过 min-height（垂直）或 min-width（水平）设置下限，防止滑块过小难以拖拽。
- 垂直滚动条：用
min-height控制最小可拖区域，例如min-height: 40px - 水平滚动条：用
min-width，例如min-width: 40px -
width/height在 WebKit 中会被静默丢弃，DevTools 里可能显示“已禁用” - 注意：Firefox 不支持这些伪元素，
scrollbar-width和scrollbar-color是它的替代方案，但无滑块尺寸控制能力
自定义轨道 padding 导致滑块错位的常见原因
给 scrollbar-track 加 padding 或 margin 看似合理，实则破坏浏览器内置布局逻辑。轨道内边距会压缩可用空间，但滑块仍按原始轨道尺寸计算位置，结果就是滑块“悬空”或超出边界。
- 错误写法：
::-webkit-scrollbar-track { padding: 4px; }→ 滑块上下留白、拖动不跟手 - 正确思路：用
border或透明background模拟内边距，例如border: 4px solid transparent - 或者改用
background-clip: content-box+padding，但需配合box-sizing: border-box保证总尺寸不变 - 更稳妥的做法是放弃 padding，直接调整
scrollbar-track的background渐变或阴影来营造呼吸感
滚动容器 overflow 隐藏时，伪元素依然生效但不可见
当父容器设了 overflow: hidden，而子内容实际可滚动时，::-webkit-scrollbar 样式仍被解析并应用，但整个滚动条（包括轨道和滑块）被裁剪掉——这不是样式失效，是盒模型裁剪行为。
立即学习“前端免费学习笔记（深入）”；
- 常见误判：“我写了样式但没反应”，其实是滚动条被
overflow: hidden吃掉了 - 验证方式：临时改成
overflow: auto，看滑块是否出现 - 若必须隐藏默认滚动条又想保留自定义交互，得用 JS 模拟滚动（如
element.scrollTop+ 自绘滑块），此时 CSS 伪元素完全不参与 - 注意：移动端 Safari 对
::-webkit-scrollbar支持极弱，iOS 16+ 才开始有限支持scrollbar-width，别依赖它做关键交互
滚动条伪元素的“定位”不是你能控制的位置，而是浏览器对滚动状态的视觉映射。所有试图用常规布局手段去挪动滑块的操作，基本都会撞上这堵墙。
