大型项目必须用 CSS 预处理器，因原生 CSS 缺乏作用域、复用逻辑和依赖管理，导致维护困难；Sass/Less 通过 @use/@import（reference）、路径别名、模块拆分和 BEM 嵌套实现可控的样式封装与复用。
大型项目不用 CSS 预处理器，样式维护很快就会变成“改一处、崩三处”的状态——不是靠经验压得住，而是靠工具兜得住。
为什么原生 CSS 在大型项目里撑不住
原生 CSS 缺乏作用域、无法复用逻辑、没有依赖管理，直接导致几个硬伤：
-
@import是同步阻塞加载，每个@import都触发一次 HTTP 请求（旧版）或至少一次解析开销（现代），模块越多，构建越慢 - 颜色、间距、断点这些值散落在各处，全局搜索替换易漏，
Ctrl+F找不到所有使用位置 - 组件样式和布局样式混写，
.header .nav li a这类长选择器反复出现，既难读又难改，还容易被其他样式意外覆盖 - 响应式逻辑靠复制粘贴媒体查询，
@media (min-width: 768px)出现几十次，改个阈值得手动翻十多个文件
Sass 的 @use 和 Less 的 @import（带路径别名）怎么组织模块
关键不在“能不能分文件”，而在“分完之后能否精准控制依赖和作用域”。
Miller CSV TSV JSON 数据处理器
下载
Miller (mlr) 是一个命令行工具，用于查询、整形和重新格式化名称索引数据，如 CSV、TSV、JSON 和 JSON Lines。它将 awk、sed、cut、join 和 sort 的功能整合到一个专为结构化数据处理而构建的单一工具中。
- Sass 推荐用
@use "base/variables"而非@import：变量默认私有，必须显式as *或as base才能访问，避免命名污染 - Less 的
@import (reference)可以导入但不输出 CSS，适合只提供 mixin 或变量的“纯逻辑文件” - 两者都支持路径别名（如 Webpack 的
resolve.alias或 Vite 的resolve.alias），把@styles/mixins映射到src/styles/mixins，避免 ../../../ 写到怀疑人生 - 别把所有变量塞进一个
_variables.scss：按用途拆，比如_colors.scss、_spacing.scss、_breakpoints.scss，@use时按需引入，减少无用代码注入
模块化不是“多建几个 .scss 文件”，而是控制样式泄漏和复用粒度
真正卡住团队协作的，从来不是“怎么写”，而是“谁改了什么、影响了谁”。
立即学习“前端免费学习笔记（深入）”；
- 用 Sass 的
%placeholder替代@mixin做基础样式抽象（比如%text-emphasis），它只在@extend时才生成 CSS，不会像@mixin那样重复输出相同规则 - Less 中避免滥用
.helper-class式的通用类（如.flex-center），这类类名一旦泛滥，就等于把样式逻辑从组件内搬到了 HTML 层，破坏封装 - 组件级样式建议用 BEM + 预处理器嵌套：
.card { &__header { } &__body { } }，编译后是.card__header，既保留语义，又杜绝意外继承 - 注意
@use的循环依赖检测：Sass 会报错Invalid operation: A tried to load B, but B already tried to load A；Less 不报错但可能静默失效，得靠目录结构提前规避
模块化真正的门槛不在语法，而在团队是否对“哪些该抽、抽到哪一级、谁负责维护”有共识。变量命名冲突、@extend 破坏选择器权重、mixins 参数默认值写死——这些问题不会因为用了 Sass 或 Less 就自动消失，反而会在多人协作时集中爆发。
