Sass编译内存溢出主因是node-sass或Dart Sass解析大量@import及sass-resources-loader重复注入全局文件；应优先设NODE_OPTIONS扩堆内存，根治需精简@import、禁用sass-resources-loader并改用@use/@forward模块化。
直接结论：Sass编译内存溢出，90% 是 node-sass 或 sass（Dart Sass）在解析大量 @import 或全局混入时撑爆 Node 默认堆内存；优先改 NODE_OPTIONS 临时绕过，但根治得砍掉冗余 @import 和禁用 sass-resource-loader。
为什么改 NODE_OPTIONS 能快速生效
Node.js 默认老版本（v8.x–v14.x）只分配约 1.4 GB 堆内存，而 node-sass 编译含几十个 @import 的 SCSS 文件时，AST 解析+字符串拼接极易触顶。v8.0+ 支持通过环境变量扩限：
-
export NODE_OPTIONS="--max-old-space-size=4096"（Linux/macOS） -
set NODE_OPTIONS=--max-old-space-size=4096（Windows CMD） - 若用 npm script，写成：
"build:css": "cross-env NODE_OPTIONS=--max-old-space-size=4096 sass src/main.scss dist/main.css"
注意：v16+ 默认已提升到 ~2 GB，但若项目里有自定义 Webpack 插件或 loader（比如旧版 sass-resources-loader），仍可能触发溢出。
sass-resources-loader 是隐形内存杀手
这个 loader 会把指定 SCSS 文件（如 variables.scss、mixin.scss）强制注入到每个被编译的 SCSS 模块顶部——相当于每编译一个文件，都重复解析一遍全部变量和 mixin。当它混入 5 个以上大文件时，内存占用呈线性增长。
ZenHeart zenlink 与 zenlink-mcp 为 OpenClaw，涵盖安装、MCP 注册、钩子接线、入站轮询及升级维护。
- 典型错误现象：
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory - 排查方法：临时注释掉 webpack 配置中
sass-resources-loader的 use 项，再跑一次编译，看是否消失 - 替代方案：改用 Dart Sass 的
additionalData选项（Webpack 5+），或直接在入口 SCSS 里手动@use/@forward
真正省内存的 SCSS 组织方式
不是所有 @import 都该留着。现代 Sass（Dart Sass）推荐模块化写法，避免“一导全”：
- 删掉类似
@import "base/all";这种聚合文件，它会让每个组件都加载整套基础样式 - 把全局变量拆成按需
@use "variables" as var;，而不是@import "variables" - 禁止在
_mixins.scss里@import其他文件——mixins 应该是纯函数，不带副作用 - 检查
node_modules中第三方 UI 库的 SCSS 引入方式，很多库文档写@import "~xxx/styles"，实际应改为@use "xxx" with (...)
一个真实案例：某后台系统移除 sass-resources-loader + 改用 @use 后，编译内存从 1.8 GB 降到 320 MB，耗时从 15 分钟压到 22 秒。
最易被忽略的一点：Dart Sass 的 style 输出模式（compressed / expanded）对内存影响极小，别指望换 mode 来救；真正吃内存的是解析阶段，不是生成阶段。
