sass-loader 中 sass-embedded 编译器未正确释放的问题分析

问题背景

在 webpack 生态系统中，sass-loader 是一个常用的 CSS 预处理器加载器，它允许开发者在 webpack 构建流程中使用 Sass/SCSS。近期在使用 sass-loader 的现代编译器 API（modern-compiler）时，发现了一个关于资源释放的重要问题。

问题现象

当使用 sass-embedded 作为编译器时，sass-loader 可能会创建多个编译器实例（通过多次调用 initAsyncCompiler）。在正常情况下，这些编译器实例应该在构建完成后被正确释放。然而，在某些情况下，特别是存在竞态条件时，新创建的编译器实例没有被正确释放。

这会导致以下问题：

1. 由 sass-embedded 启动的 dart sass.snapshot --embedded 子进程无法正常退出
2. Node.js 进程因此无法正常终止
3. 构建完成后进程仍然挂起

技术原理分析

sass-loader 在处理现代编译器 API 时，会维护一个 sassModernCompilers 的 Map 结构来存储编译器实例。当检测到 webpack 编译器尚未注册时，会创建新的编译器实例并注册到该 Map 中，同时设置 shutdown 钩子来确保资源释放。

问题出现在竞态条件处理逻辑中：当检测到已有编译器实例时（sassModernCompilers.has(webpackCompiler) === true），新创建的编译器实例没有被调用 dispose 方法进行释放。

解决方案

正确的处理方式应该是：

1. 如果没有已注册的编译器实例，则注册新实例并设置 shutdown 钩子
2. 如果已有注册实例，则立即释放新创建的实例

修复方案的核心代码变更如下：

if (!sassModernCompilers.has(webpackCompiler)) {
  sassModernCompilers.set(webpackCompiler, compiler);
  webpackCompiler.hooks.shutdown.tap("sass-loader", () => {
    compiler.dispose();
  });
} else {
  compiler.dispose();
}

影响范围

这个问题主要影响：

1. 使用 sass-embedded 作为编译器的项目
2. 使用 modern-compiler API 的项目
3. 项目规模较大、构建时间较长的场景（竞态条件更容易出现）

最佳实践建议

1. 确保使用最新版本的 sass-loader（16.0.3 及以上版本已修复此问题）
2. 对于使用 Rspack 等非标准 webpack 实现的场景，需要确认其是否支持标准的 shutdown 钩子
3. 在构建完成后，检查是否有残留的 Node.js 进程
4. 对于大型项目，考虑使用 api: "modern" 作为临时解决方案

总结

资源释放是构建工具中一个容易被忽视但非常重要的环节。sass-loader 的这个案例提醒我们，在处理竞态条件时，不仅要考虑数据一致性，还要确保资源的正确释放。开发者在使用构建工具时，应当关注构建完成后的进程状态，及时发现并解决类似的资源泄漏问题。