解读

在真实项目里，Grunt 任务链往往同时扫描「业务源码」与「node_modules 里的第三方库」。
如果 JSHint、ESLint、Uglify、PostCSS 等插件对第三方库启用与业务代码同一套规则，就会出现：

1. 控制台刷屏式警告，CI 直接失败；
2. 压缩或转译阶段因语法差异报错，阻塞部署；
3. 团队被迫降低全局规则，反而让业务代码质量下滑。
   面试官想确认候选人是否理解 「规则作用域隔离」 与 「Grunt 多目标机制」，并能在不污染全局配置的前提下，让第三方库“无痛”通过构建。

知识点

1. Grunt 多目标（multi-task）：每个插件可声明多个 target，各自独立 files/options。
2. glob 负向匹配：! 排除特定路径，是 Gruntfile 的标配写法。
3. 插件级 exclusions：如 jshint 的 ignores、eslint 的 .eslintignore、uglify 的 exclude 数组。
4. 动态过滤函数：使用 filter: function(filepath){ ... } 在任务运行前二次筛除。
5. .gruntignore：部分社区插件支持类似 .gitignore 的语法，一次性声明豁免名单。
6. 任务链顺序：先 copy 或 concat 把第三方文件单独输出到 dist/vendor，后续 uglify:vendor 用宽松规则，与 uglify:app 隔离。
7. CI 场景：在 process.env.CI 为真时，通过 grunt.option 动态开关是否对第三方库做静态检查，既保证本地快速调试，又保证线上安全。

答案

“我会分三步实现豁免，不改第三方源码，也不降低业务规则：

第一步，用多目标把‘源码’与‘第三方’拆成两个独立 target。
示例：

jshint: {
  options: { esversion: 2022, strict: true },
  app: {
    src: ['src/**/*.js']
  },
  vendor: {
    options: { esversion: 5, strict: false, '-W040': true }, // 宽松规则
    src: ['<%= dirs.vendor %>/**/*.js']
  }
}

第二步，在全局扫描任务里用负向匹配直接跳过 node_modules。

eslint: {
  target: {
    src: ['src/**/*.js', '!node_modules/**', '!src/lib/legacy/**/*.js']
  }
}

第三步，对必须打包的第三方文件，在 uglify 或 babel 阶段再单独开一个 target，关闭压缩警告、关闭严格模式，甚至用 filter 函数把已 min 过的文件直接复制而不二次压缩。
这样 CI 运行 grunt jshint:app eslint uglify:app 时，第三方库完全不会触发规则，也不参与质量门禁，但业务代码依旧保持高标。

拓展思考

1. 大型仓库如何做“按需豁免”？
   把豁免列表抽成 grunt.config.set('vendorIgnore', ['jquery/dist/*.min.js', 'lodash/lodash.js'])，然后在所有插件的 filter 里统一引用，一处修改、全链生效。
2. Monorepo 场景下，子项目各自维护自己的 .gruntignore，父项目通过 grunt.file.readJSON 动态合并，避免“一刀切”导致子项目规则冲突。
3. 性能优化：第三方库通常已 min，二次压缩收益接近 0 却耗时显著；可以在 uglify 的 filter 里判断文件是否含 .min，若是则直接 return false，任务耗时降低 30% 以上。
4. 安全合规：豁免不等于放任，把第三方库交给 npm audit 与 snyk 做依赖漏洞扫描，与 Grunt 构建解耦，形成“静态检查豁免 + 安全扫描兜底”的双保险，面试官会认可你对工程化全局的考量。