按职责拆分css组件：变量、工具类、样式逻辑各归其位，用@use隔离作用域，@forward可控暴露，确保每个文件只做一件事且边界清晰。
怎么拆一个 CSS 复杂组件才不乱
直接拆到「能独立改、不牵连其他地方」为止。不是按视觉区块切（比如 header / body / footer），而是按职责切：变量归变量，工具类归工具类，样式逻辑归具体组件文件。
常见错误是把整个组件塞进一个 _card.scss 里，结果改个圆角要翻三页，加个暗色模式得全局搜 background-color。
- 每个 Sass 文件只做一件事：比如
_card.variables.scss只放$card-padding、$card-border-radius - 用
@use显式声明依赖，别用@import—— 否则变量作用域混乱，改一个值可能在十个地方意外生效 - 组件主文件（如
_card.scss）只负责组装：引入变量、工具、状态类，自身几乎不写具体样式值
Sass 中哪些东西必须抽成单独文件
不是所有代码都值得拆，但以下三类不拆，后期维护成本会指数级上升：
-
$color-primary、$spacing-md这类设计系统级变量 → 抽到_foundations.variables.scss -
text-truncate()、visually-hidden()这类无上下文的工具 mixin → 放_tools.mixins.scss -
.card--hoverable、.card--compact这类纯状态修饰类 → 单独_card.modifiers.scss，和主体样式解耦
漏掉其中任何一类，都会导致“改一处，查八处”，尤其当项目接入 Design Token 或需要支持 RTL 时，混在一起的变量根本没法批量替换。
@use 和 @forward 怎么配着用才不翻车
@use 是隔离作用域的底线，@forward 是可控暴露的开关。不用 @forward，下游就得写一长串路径；滥用 @forward，又等于变相回到 @import 的全局污染时代。
- 基础变量/工具文件用
@forward "foundations.variables" as foundations-*;，让使用者明确知道引入了什么前缀 - 组件文件内部用
@use "tools.mixins"，但不@forward它——组件自己用就行，不该让调用方意外获得一堆 mixin - 禁止
@forward "all"，Sass 7 已废弃，且会破坏命名可追溯性
典型翻车场景：_card.scss 里 @forward "tools.mixins"，结果业务页面 @use "card" 后，直接能调 text-truncate() —— 看似方便，实则埋下样式不可控隐患。
拆完文件后怎么验证没拆散架
拆得细不是目的，能合得稳才是关键。最简单的验证方式：删掉某个子文件，看编译是否报错；改一个变量值，检查是否只影响预期组件。
- 用
sass --watch编译时，留意警告：如果出现"variable is not defined"，说明@use路径或命名空间错了 - 在组件 demo 页面里临时加个
border: 1px solid red，确认它只出现在目标元素上——如果父容器或隔壁组件也红了，大概率是@forward暴露了不该暴露的东西 - CI 里跑
sass --no-source-map --dry-run，确保所有@use路径存在且无循环依赖
真正难的不是拆，是让每个小文件都有清晰边界感。很多人卡在「这个 mixin 到底该放在 card 里还是 tools 里」——答案就一条：它能不能被另一个完全无关的组件（比如 button）安全复用？能，就进 tools；不能，就留在 card 内部。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
