大型项目必须用 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 就自动消失，反而会在多人协作时集中爆发。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！