CSS如何通过Sass创建可复用的UI组件：通过Mixin构建CSS库
直接用 @mixin 封装组件样式，这条路当然走得通，但关键在于控制调用方式。否则，CSS体积会像滚雪球一样指数级膨胀，后期的维护工作也会变得举步维艰。
为什么按钮类一多就编译出几百行重复CSS？
问题就出在调用机制上。每次你写下 @include btn($bg: #007bff)，Sass都会老老实实地把整套规则——包括hover、focus、disabled状态——原封不动地复制一遍。想象一下，10个按钮变体，就意味着10份完全相同的transition、border-radius、box-shadow声明。这冗余量，想想都头疼。
那么，怎么破局？
- 高频组件优先共享：像
btn-primary、btn-secondary这类使用率极高的组件，改用@extend来共享基础规则，让@mixin只专注于处理颜色、大小等差异化部分。 - 警惕媒体查询嵌套：避免在
@mixin内部直接嵌套@media或@supports规则。这些代码块会被完整复制到每个调用点，而不是被智能合并，这同样是体积膨胀的元凶之一。 - 生产环境保护：在构建生产版本时，记得使用
/* purgecss start ignore */这样的注释，将核心类名显式地加入安全列表（safelist），防止它们被CSS清理工具误删。
如何让 @mixin card() 支持主题切换而不炸开体积？
直接把颜色值写死在mixin里？这条路走不远。Sass在编译期无法预知运行时的主题切换。真正具备扩展性的方案，是学会“分离关注点”：
- 结构层固化：创建一个
@mixin card-base，专门定义padding、border-radius、box-shadow这些与主题无关的、稳定的样式逻辑。 - 皮肤层动态化：视觉表现交给CSS自定义属性（比如
--card-bg、--card-border）来驱动。Sass只需要生成background-color: var(--card-bg)这样的声明即可。 - 调用与控制的分离：使用时这样写：
.card { @include card-base; }。至于主题色，则通过Ja vaScript动态注入，或者由根元素上的class来控制，实现真正的动态切换。
@mixin form-control() 必须处理的三个可访问性陷阱
只封装样式，很容易忽略语义和交互细节，结果就是键盘导航失灵，或者屏幕阅读器报出令人困惑的信息。以下是三个必须绕开的坑：
“前端免费学习笔记（深入）”；立即学习
- 禁用状态不只是变灰：处理disabled状态，不能仅仅依赖
opacity: 0.6。必须同时加上pointer-events: none来阻止所有交互，以及cursor: not-allowed来给用户明确的视觉提示。 - 焦点样式要明确且可用：覆盖浏览器默认的outline时，必须提供明确且高对比度的替代样式。在Sass里，用
lighten($color, 20%)来计算颜色并不可靠，更稳妥的做法是直接定义一个清晰的$focus-color变量。 - 标签关联是硬性要求：虽然label与input的关联不是mixin的职责，但在文档中必须强烈提醒开发者：使用
@mixin form-control时，HTML结构必须包含正确的for和id属性，或者使用包裹关系，这是可访问性的基石。
什么时候该停手，别再往 @mixin 里塞逻辑？
Mixin本质上是样式函数，而不是万能的配置中心。当出现以下迹象时，就说明你已经越界了，该考虑收手或重构：
- 参数膨胀且强耦合：当参数超过4个，并且它们之间存在强依赖关系（例如
$size一个参数要同时影响$padding、$font-size，还得联动计算$line-height）。这时候，更好的做法是拆分成多个职责单一、专注的小型mixin。 - 根据参数生成选择器：如果需要根据传入的参数动态生成像
.btn-lg、.btn-sm这样的不同类名。这其实是工具类（utility class）系统的职责，交给Tailwind这类框架，或者自己构建一套class系统会更合适。 - 手动处理浏览器兼容：比如为了兼容IE11，而在mixin里手动编写
-ms-flex-pack和justify-content。这类工作应该交给Autoprefixer这样的后处理工具来完成，而不是固化在mixin的逻辑里。
说到底，真正的挑战往往不在于写出一个能运行的mixin，而在于拥有判断“哪些逻辑不该放进mixin”的克制与智慧。
