解读

面试官真正想考察的是你对 Grunt 任务配置合并优先级 的理解深度，以及能否在真实 CI/CD 流程中可验证、可回溯地保证“全局默认 + 局部覆写”这一策略生效。国内项目普遍多人协作、构建链路长，一旦合并策略写错，常出现“本地能跑、线上崩了”的锅；因此，回答时要体现：

1. 知道 Grunt 内部用 grunt.util._.merge 做浅合并
2. 会用target 级同名属性直接覆盖全局 options
3. 会用 grunt --debug 或自定义 grunt.task.run 钩子把最终配置打印出来，让结果可复盘、可自动化校验

知识点

• task.options API：Grunt 0.4.0+ 引入，支持在 task 级和 target 级同时声明
• 合并顺序：defaults → task-level options → target-level options，后写的覆盖先写的
• 浅合并陷阱：数组、嵌套对象会被直接替换而非深度递归合并
• 验证手段：grunt --debug、自定义 log task、grunt.config.getRaw()、单元测试里用 grunt.test.helper 抓取配置快照
• 国内落地经验：在 package.json 里增加 "scripts": {"test:grunt": "grunt validate-config"}，配合 GitLab CI 跑配置校验任务，防止合并策略被 MR 误改

答案

1. 在 Gruntfile 中先声明全局默认配置

grunt.initConfig({
  uglify: {
    options: {               // 全局 options
      banner: '/*! <%= pkg.name %> */',
      compress: { drop_console: true }
    },
    dev: {
      options: {             // target 级覆盖
        compress: { drop_console: false }, // 只改这一层
        mangle: false        // 新增属性
      },
      files: { 'dist/app.js': 'src/**/*.js' }
    }
  }
});

关键点：dev 的 options.compress 会整对象覆盖全局的 compress，而不是深度合并；mangle 为新增，不影响全局。

2. 验证合并结果
   写一个纯诊断任务 validate-config：

grunt.registerTask('validate-config', function() {
  const merged = grunt.config.get(['uglify', 'dev', 'options']);
  console.log(JSON.stringify(merged, null, 2));
  // 自动化断言
  if (merged.compress.drop_console !== false) {
    grunt.fail.warn('target 级覆盖失败，请检查合并策略！');
  }
});

本地运行 grunt validate-config --debug，CI 里再跑一次，输出快照随构建日志永久留存，出现线上事故时可回溯。

3. 若需深度合并数组或嵌套对象，可借助 grunt.util._.mergeWith 自定义策略，但务必在任务文档里显式声明，防止后续维护者踩坑。

拓展思考

• 灰度场景：国内常分“国内版/海外版”两套构建，利用 grunt.option('region') 动态选择 target，再叠加 target 级 options，做到一行命令切换全局策略
• 性能与可维护性：插件越来越多时，把全局 options 抽成 grunt/config/shared.js，通过 grunt.file.readJSON 统一加载，既保持合并优先级，又避免 Gruntfile 膨胀
• 未来迁移：Grunt 已停止特性更新，但存量项目庞大。掌握“先验证再覆盖”的思路后，可平滑迁移到 gulp/webpack——它们的 rule.use、loader.options 同样遵循“就近覆盖”原则，面试时把这段经历讲成“配置治理方法论”，可显著加分