必须用@use而非@import，因其强制命名空间隔离（如vars.$primary），杜绝全局变量污染与静默覆盖；Dart Sass已弃用@import，且@use支持高效单次编译、禁止循环依赖、配合@forward实现可配置模块封装。
不需要从零造轮子，SCSS 本身就能支撑一个轻量级响应式框架的骨架——关键在模块组织、变量控制和 @use 的正确用法，而不是堆砌功能。
为什么不用 @import 而必须用 @use
旧项目里满屏 @import "_variables" 看似省事，实则埋雷：所有变量全局污染，改一个 $spacing-unit 可能意外影响按钮内边距、网格列间隙甚至模态框动画时长。Dart Sass 已正式弃用 @import，新项目必须用 @use 隔离作用域。
-
@use "base/variables" as vars后，必须写vars.$primary才能访问，杜绝隐式覆盖 - 同一模块被多次
@use，只编译一次，避免重复 CSS 输出 - 不支持循环
@use，强迫你理清依赖流向——比如mixins不能反向依赖variables的具体值，只能依赖其结构
断点系统怎么设计才真正可维护
硬编码 @media (max-width: 768px) 是最常见也最危险的习惯。真实场景中，导航栏文字变多、图标加宽、字体放大都会提前触发换行——断点应基于内容容器的实际撑开宽度，而非设备尺寸。
- 定义统一断点变量：
$breakpoint-sm: 576px（测出导航项开始折行的最小宽度）、$breakpoint-md: 768px、$breakpoint-lg: 1024px - 封装响应式 mixin：
@mixin for-sm { @media (max-width: $breakpoint-sm - 1) { @content; } }，注意减 1 避免边界重叠 - 移动端优先是默认逻辑，
.container初始按$breakpoint-sm设计，桌面端用@include for-lg增强，不是“降级”而是“增强”
如何用 @forward 构建可配置的入口
用户不该为引入一个按钮样式而手动 @use 十几个文件。@forward 是构建“开箱即用”体验的核心——它把底层模块打包成可控的 API 表面。
立即学习“前端免费学习笔记（深入）”；
- 建
framework/_index.scss，里面只写：@forward "variables" with ($primary: #2563eb !default); - 用户只需
@use "framework" as fw，就能拿到fw.$primary和fw.button()，且能通过with覆盖默认色 - 转发时加
as *会破坏命名空间，等同于倒退回@import，绝对禁止 - 暗色模式切换靠
@forward "themes/dark" if $theme == "dark"，条件转发比 JS 切换 class 更早介入编译流程
Flex/Grid 工具类为什么不能直接写 display: flex
看似一行 .d-flex { display: flex; } 最快，但实际项目里它会失控：不同组件对 flex-direction、flex-wrap、align-items 的需求完全不同，强行复用只会催生一堆 .d-flex-col、.d-flex-wrap 等补丁类。
- 用
@mixin flex-row($wrap: nowrap)封装，参数明确行为，调用时@include flex-row(wrap)比加 class 更易追溯 - Safari 下
flex-shrink: 0和min-width: 0必须成对出现，漏掉任一都会导致子元素被压缩变形——这是 Flex 布局的底层行为，不是 bug - 工具类只暴露高频、无歧义的组合，比如
.text-truncate（white-space: nowrap; overflow: hidden; text-overflow: ellipsis;），而不是把所有 CSS 属性都映射成 class
真正轻量的关键，是敢于砍掉“看起来有用但没人真用”的功能。比如放弃对 IE11 的支持、不提供 JS 组件、不内置图标字体——这些决定比写一百行 mixin 更影响框架的长期可维护性。SCSS 的能力不在语法多炫，而在让你清晰地知道哪一行代码在什么条件下生效、被谁覆盖、为何存在。
