解释在 grunt 流中保持组件状态不丢失的底层原理 - 问题详情 - 创脉思

解读

面试官真正想考察的是：

你是否理解 Grunt 的 “配置驱动 + 任务管道” 模型；
你是否清楚 task、target、file、options 四级作用域的合并顺序；
你是否能说明 grunt.file、grunt.config、grunt.option 三大 API 如何把状态写回内存对象，从而保证后续 task 读到的是最新值；
你是否知道 “中间文件”与“内存对象” 两种状态暂存方式的取舍，以及国内企业在 CI 镜像、云构建缓存场景下的最佳实践。

一句话：不是“变量怎么不丢”，而是“Grunt 如何显式持久化中间结果，并让后续 task 可靠复用”。

grunt.config.data 根对象：所有 grunt.initConfig 写入最终都会落到这个纯 JSON 对象上，运行时只读但可动态二次写入。
grunt.config.set(key, val) / grunt.config.get(key)：提供点式路径读写能力，把状态挂到内存树，不落地文件也不会随 task 结束而销毁。
grunt.option(key, val)：针对命令行透传参数设计，生命周期与 grunt 进程一致，适合开关型状态，不适合大体积数据。
中间文件约定：国内团队普遍在 .tmp/ 目录下存放转译未压缩产物，后续 task 通过 grunt.file.readJSON('.tmp/manifest.json') 重新载入状态，既解决内存溢出风险，又兼容增量构建缓存。
task.run() 的立即调度：Grunt 把子任务压入同步队列，同一进程内共享全局 grunt 实例，因此内存状态天然不会丢失。
插件的 files 数组展开：expandMapping 会把通配符预展开成绝对路径数组，写入 this.files，后续 task 即使修改磁盘，路径数组仍保持引用稳定，避免“文件找不到”导致状态断裂。

在 Grunt 的单进程、同步队列模型里，所有 task 共享同一个 grunt 全局实例，状态本质上是挂在grunt.config.data这棵内存 JSON 树上的节点。

若状态体积小、只在 task 间传递，优先用 grunt.config.set/get，把结果挂到自定义命名空间，例如 grunt.config.set('buildInfo.timestamp', Date.now())；后续 task 通过 grunt.config('buildInfo.timestamp') 直接读取，全程不落磁盘，性能最高。
若状态体积大或需要跨构建缓存，则先写入约定的中间文件（如 .tmp/build-manifest.json），并在下一个 task 里 grunt.file.readJSON 重新载入；配合国内云构建的增量缓存策略（只缓存 .tmp/ 与 node_modules/），即可实现“二次构建跳过转译”。
对于命令行开关（如是否启用 sourcemap），用 grunt.option('sourcemap', true) 在首 task 设置，后续 task 通过 grunt.option('sourcemap') 读取，生命周期与 grunt 进程一致，保证多 target 下状态统一。

通过以上机制，Grunt 既能在内存中保持引用级一致性，又能通过显式落地解决大体积状态与缓存问题，从而在整个任务流中“组件状态不丢失”。

在微前端仓库群场景，如果 A 仓库的 grunt 任务需要把版本号传递给 B 仓库的 grunt 任务，可借助共享 NFS 缓存盘或企业 npm 私服的元数据接口，把状态写成 .tmp/shared-version.json 并加文件锁，避免并发写冲突。
当 grunt 与 webpack/vite 共存时，可用 grunt-webpack 的 stats.json 输出，把 chunk 映射表反写回 grunt.config.set('webpackStats', stats)，让后续 grunt 任务做精确注入；此时要注意内存阈值，超过 200 MB 建议落盘。
国内 CI（如云效、Coding）默认每次构建起新容器，若想复用 .tmp/ 缓存，需在 Jenkinsfile 里声明 cache(key: "grunt-tmp", paths: [".tmp/"])，否则内存或磁盘状态都会随容器销毁而丢失。