在维护稍微复杂一点的前端项目时，样式文件的数量往往会快速膨胀。把变量、mixin、重置样式、组件样式分别存放在不同SCSS文件里是常见的组织方式，但浏览器最终只需要一个CSS文件来渲染页面。Sass本身提供了模块化机制，但合并并非简单地把文件内容拼接在一起，而是需要理解加载顺序、作用域和输出规则。下面会从Sass命令行、构建工具两个层面展开，并说明合并过程中容易踩到的坑。

用Sass CLI编译入口文件实现合并

Sass编译器会从入口文件开始解析所有被引入的模块，并把最终样式输出到单个CSS文件。这是最直接的合并方式，不需要额外安装构建工具。假设项目结构如下：

styles/
├── main.scss
├── _variables.scss
├── _mixins.scss
├── _reset.scss
└── components/
    ├── _button.scss
    └── _card.scss

这里以下划线开头的文件是部分文件（partial），Sass不会单独编译它们，只在被引入时才会参与合并。入口文件main.scss负责按顺序引入其他模块：

// main.scss
@use 'variables';
@use 'mixins';
@use 'reset';
@use 'components/button';
@use 'components/card';

执行sass main.scss output.css后，Sass会把这些模块的编译结果依次输出到output.css。需要注意，如果使用@import而不是@use，每个被导入的文件内容都会直接展开到导入位置，这样虽然也能合并，但容易造成重复输出，尤其是当多个文件导入同一个变量文件时。@use规则只加载模块一次，并且默认使用命名空间访问变量和mixin，能有效避免全局污染。

如果不想手动指定每个文件，也可以通过Sass的--load-path或-I参数添加搜索路径，让@use 'button'能自动找到components/_button.scss。命令如下：

sass --load-path=styles --load-path=styles/components styles/main.scss dist/style.css

这种方式适合中小型项目或需要快速验证的场景。它的缺点也很明显：每次修改都要手动执行命令，文件变多后难以维护。因此在实际项目中，更普遍的做法是把Sass编译整合进构建流程。

借助Gulp或Webpack自动合并SCSS

构建工具可以监听文件变化，自动重新编译并输出合并后的CSS。以Gulp为例，只需要安装gulp、gulp-sass和gulp-postcss等插件，就能搭建一个简单的任务。

const gulp = require('gulp');
const sass = require('gulp-sass')(require('sass'));
const concat = require('gulp-concat');
function compileStyles() {
  return gulp.src('styles/main.scss')
    .pipe(sass({
      includePaths: ['styles', 'styles/components']
    }).on('error', sass.logError))
    .pipe(concat('bundle.css'))
    .pipe(gulp.dest('dist'));
}
function watchStyles() {
  gulp.watch('styles/**/*.scss', compileStyles);
}
exports.compile = compileStyles;
exports.watch = watchStyles;

上面的代码中，gulp.src只读取入口文件main.scss，Sass编译器在解析时会自动加载所有被@use引用的部分文件，最终通过gulp-concat合并成一个bundle.css。实际上如果只有Sass编译，concat不是必需步骤，因为Sass本身就输出单个文件。当项目中还包含第三方CSS文件需要合并时，concat才显得更有用。

Webpack的处理思路类似，但更依赖loader链。配置css-loader和sass-loader后，Webpack会把SCSS文件当作模块处理。在入口JavaScript文件中import './styles/main.scss'，Webpack通过MiniCssExtractPlugin可以把所有样式抽取成单独的CSS文件。配置片段如下：

module.exports = {
  module: {
    rules: [
      {
        test: /\.scss$/,
        use: [
          MiniCssExtractPlugin.loader,
          'css-loader',
          {
            loader: 'sass-loader',
            options: {
              sassOptions: {
                includePaths: ['styles', 'styles/components']
              }
            }
          }
        ]
      }
    ]
  },
  plugins: [
    new MiniCssExtractPlugin({
      filename: 'css/bundle.css'
    })
  ]
};

Webpack会从JavaScript入口出发，递归收集所有被import的SCSS文件，交由sass-loader编译成CSS，最后由MiniCssExtractPlugin输出成单个文件。这种方式的好处是能够和热更新、代码分割等功能集成，适合组件化开发的前端应用。

合并时需要避开的几个陷阱

第一个陷阱是变量和mixin的重复输出。在旧版Sass中使用@import导入变量文件时，如果多个样式文件都导入同一个变量文件，变量文件中的普通样式规则也会被重复输出多次。例如_variables.scss里除了变量定义，还写了body { font-size: 14px; }，那么每次@import 'variables'都会把这行规则复制一遍。解决方法是改用@use，并且只在入口文件引入一次；或者把需要输出的基础样式单独拆成_base.scss，确保只被加载一次。

第二个陷阱是加载顺序导致样式覆盖不符合预期。CSS的层叠特性使得后声明的规则优先级更高。如果@use的顺序不对，组件样式可能覆盖掉基础样式，或者变量默认值无法被覆盖。Sass官方推荐的做法是将变量和配置模块放在最前面，基础样式其次，最后是组件样式。如果使用@use ... with语法，还可以在导入模块时覆盖默认变量值，这比依赖全局变量顺序要可靠得多。

// _config.scss
$primary: #3366ff !default;
// main.scss
@use 'config' with (
  $primary: #ff6633
);
@use 'reset';
@use 'components/button';

第三个陷阱是源映射（source map）缺失带来的调试困难。合并后的CSS文件会丢失原来SCSS的文件结构和行号，浏览器调试时很难定位到具体源文件。在Sass CLI中添加--source-map参数，或者在构建工具中开启sourceMap选项，可以生成.map文件，让浏览器开发者工具直接展示原始SCSS代码。对于生产环境，可以通过额外参数控制是否暴露源映射，平衡调试需求和安全风险。

最后还要注意输出文件的压缩和兼容性。合并后的CSS可能包含大量注释和空白，需要配合--style=compressed或PostCSS的cssnano插件进行压缩。自动添加浏览器前缀则可以交给autoprefixer处理。在Gulp或Webpack的管道中，把这些后处理步骤放在Sass编译之后、输出之前即可。