CSS如何通过Sass封装滚动条样式：通过Mixin实现自定义
为什么直接写 ::-webkit-scrollbar 在 Sass 里会失效
这事儿挺常见的，很多开发者第一次尝试自定义滚动条时都会踩到这个坑。原因在于，::-webkit-scrollbar 及其一系列子伪元素（比如 ::-webkit-scrollbar-track）是 WebKit 内核的“专属品”，并非 CSS 标准。Sass 编译器在处理嵌套语法时，默认并不认识它们。
如果你直接这么写：
.box {
&::-webkit-scrollbar {
width: 8px;
}
}
编译出来的结果很可能“跑偏”——生成一个错误的选择器，例如 .box -webkit-scrollbar。这种情况在使用旧版 Dart Sass 的兼容模式，或者 @use 规则配置不当时尤为明显。
- 关键解法：必须用引号把整个伪元素名包裹起来，写成
"&::-webkit-scrollbar"。记住，要完整包裹，不能拆开或省略冒号。 - Sass 3.5 之后虽然支持了原生的伪类插值，但
::-webkit-scrollbar是个特例，稳妥起见还是得用字符串拼接。 - 别忘了，Firefox 和 IE 压根不支持这个伪元素。在它们那里，
scrollbar-width和scrollbar-color才是唯二的“官方”控制手段。
如何用 @mixin 封装滚动条样式并兼顾兼容性
一个真正实用的 @mixin，绝不能只照顾 WebKit 一家。如果只封装了 WebKit 部分，那么在 Firefox 里，滚动条就会直接“打回原形”，变回系统默认的样式，粗细和颜色都控制不了，体验上会割裂。
所以，一个合格的封装应该同时覆盖两大阵营：
@mixin custom-scrollbar($thumb-bg: #c1c1c1, $track-bg: #f1f1f1, $thumb-radius: 4px) {
// Firefox 方案
scrollbar-width: thin;
scrollbar-color: $thumb-bg $track-bg;
// WebKit 方案
&::-webkit-scrollbar {
width: 8px;
height: 8px;
}
&::-webkit-scrollbar-track {
background: $track-bg;
}
&::-webkit-scrollbar-thumb {
background-color: $thumb-bg;
border-radius: $thumb-radius;
border: 2px solid $track-bg;
}
&::-webkit-scrollbar-thumb:hover {
background-color: darken($thumb-bg, 10%);
}
}
- 参数设计：给参数设置合理的默认值，调用时就能省心不少。另外，
$thumb-bg（滑块颜色）和$track-bg（轨道颜色）建议优先使用灰阶色，这样在适配深色模式时不容易“翻车”。 - 交互细节：
&::-webkit-scrollbar-thumb:hover这行千万别漏！少了它，用户鼠标悬停时滑块没反应，会让人觉得这个滚动条“不可拖拽”，交互反馈就断了。很多团队都栽在这个细节上。 - 兼容性差异：需要明确的是，Firefox 的
scrollbar-color只接受两个颜色值（滑块色和轨道色），像圆角、边框这些花哨的效果它一概不支持。这是 WebKit 和 Firefox 在实现上的根本差异。
什么时候该用 @include，什么时候该用 CSS 自定义属性动态控制
如果项目的滚动条颜色需要随着主题切换（比如浅色/深色模式），那么把颜色值硬编码在 @mixin 里就显得不够灵活了。这时候，更聪明的做法是把颜色抽离成 CSS 变量，让 @mixin 只负责结构逻辑：
立即学习“前端免费学习笔记（深入）”；
@mixin theme-aware-scrollbar {
scrollbar-color: var(--scrollbar-thumb, #aaa) var(--scrollbar-track, #eee);
&::-webkit-scrollbar-thumb {
background-color: var(--scrollbar-thumb, #aaa);
}
&::-webkit-scrollbar-track {
background-color: var(--scrollbar-track, #eee);
}
}
- 动态主题：在
:root或组件作用域里，通过 Ja vaScript 或媒体查询（如@media (prefers-color-scheme: dark)）来动态设置--scrollbar-thumb和--scrollbar-track的值。这比针对每个主题重复@include不同的 mixin 要轻量和高效得多。 - 注意限制：这里有个技术细节需要注意：WebKit 内核不支持在
::-webkit-scrollbar伪元素中直接使用var()函数。因此，要么搭配 Ja vaScript 动态写入内联样式，要么就提前用媒体查询预设好所有主题变量。 - 工具类优先：话说回来，如果你的项目已经使用了 Tailwind CSS 这类原子化框架，那就别自己折腾封装了。直接使用
scrollbar-thin scrollbar-thumb-gray-400这样的工具类，往往更稳妥，维护成本也更低。在原子化 CSS 的场景下，自己写 Sass Mixin 有时反而会增加复杂度。
容易被忽略的布局与交互陷阱
自定义滚动条可不仅仅是换个皮肤那么简单，它直接关系到容器的尺寸计算和用户的交互体验。下面这几个陷阱，一不留神就会踩中。
- Overflow 的选择：给容器设置
overflow-y: scroll后，即使内容没有溢出，WebKit 也会强制显示一个空的滚动条轨道（占着空间）。所以，统一使用overflow-y: auto是更推荐的做法，只在需要时才显示滚动条。 - Padding 的冲突：滚动条的宽度会占用容器的空间。如果容器设置了
padding-right，滚动条可能会遮挡右侧内容。解决方案是使用calc计算：padding-right: calc(1em + 8px)，其中 8px 就是你定义的滚动条宽度。 - 移动端支持：移动端 Safari 对
::-webkit-scrollbar的支持一直很差，直到 iOS 16+ 才开始部分支持scrollbar-width。如果真要兼容 iOS，可能需要结合overscroll-beha vior属性，甚至考虑自己实现一个滚动条组件。 - Transform 的影响：如果容器应用了 CSS
transform属性（比如常见的translateZ(0)用来触发硬件加速），在某些旧版本的 Chrome 下，::-webkit-scrollbar的样式可能会“神秘消失”。这时，可以尝试添加will-change: scroll-position来强制触发重绘，找回样式。
