解读

面试官抛出“如何保留自定义脚本扩展点”，并不是想听你罗列 grunt.loadNpmTasks 或 grunt.registerTask，而是考察你在企业级多团队协作场景下，如何既用 Grunt 保证构建流程统一可维护，又给业务线、外包团队甚至第三方插件留下安全、可升级、可插拔的“后门”。国内大厂常把构建脚本放在独立 Git 仓库，由基础架构组统一维护；业务方若直接改 Gruntfile，下次同步主干就会冲突。因此“扩展点”必须不侵入主干、可配置、可灰度、可回滚，还要符合国内安全审计（代码扫描、权限管控）要求。

知识点

1. Grunt 任务运行时序：init → config → register → run，扩展点必须在 config 之后、register 之前注入，否则会被主干覆盖。
2. grunt.config.merge 与 grunt.config.get.raw：利用 merge 的深度合并特性，允许业务脚本只覆盖指定字段，而不会丢掉主干默认配置。
3. grunt.file.expandMapping + grunt.file.readJSON：在 Gruntfile 末尾动态加载 grunt/custom/*.json 配置片段，实现配置级扩展。
4. grunt.task.run 的异步数组：通过 this.args 拿到运行时参数，把业务脚本路径 push 到数组，实现任务级扩展。
5. 国内私有 npm 与 Verdaccio：把公司级扩展点封装成 @company/grunt-xxx 私有包，利用 .npmrc 限定 registry，解决内网隔离与版本溯源问题。
6. husky + lint-staged 二次校验：在 pre-commit 阶段再次扫描 grunt/custom/ 目录，防止业务方上传恶意 node 脚本。
7. 环境变量灰度方案：借助 process.env.GRUNT_EXT 控制是否加载扩展，支持按项目、按人、按时间灰度，符合国内“安全生产”红线要求。

答案

“我们采用三层扩展模型，保证主干稳定、业务可插、运维可管。
第一层配置扩展：在 Gruntfile 末尾统一执行

const customCfg = grunt.file.expandMapping('grunt/custom/*.json', '', {cwd: process.cwd()});
customCfg.forEach(f => grunt.config.merge(grunt.file.readJSON(f.src[0])));

业务方只需在自家项目丢一份 grunt/custom/pc.json，写

{"uglify": {"files": [{"src": "src/pc/**/*.js", "dest": "dist/pc.min.js"}]}}

即可无痛追加压缩规则，无需改主干。

第二层任务扩展：在默认任务队列里留一个占位

grunt.registerTask('default', ['clean', 'eslint', 'customSlot', 'uglify']);
grunt.registerTask('customSlot', function() {
  const ext = grunt.option('ext') || process.env.GRUNT_EXT;
  if (ext && grunt.file.exists(`grunt/custom/${ext}.js`)) {
    require(`./grunt/custom/${ext}.js`)(grunt);
  }
});

业务方提交 grunt/custom/msp.js，内部再 grunt.task.run('concat:msp')，就能动态注入私有任务，且默认不执行，必须通过 grunt default --ext=msp 显式开启，满足审计要求。

第三层插件扩展：把高度复用的逻辑封装成私有包 @company/grunt-plugin-fleximg，在 package.json 的 devDependencies 里按需引用，主干通过

if (grunt.config.get('fleximg')) grunt.loadNpmTasks('@company/grunt-plugin-fleximg');

条件加载，既保持插件生态，又避免无意义安装。

上线流程配合GitLab CI：合并请求触发 grunt validate-ext，脚本会检查 grunt/custom/ 目录是否包含 eval、child_process、fs.chmod 等高危关键字，一旦命中直接驳回，零人工干预。通过这三层，我们让20+业务线在两年内零冲突地共用同一套 Grunt 主干，平均**节省30%**构建时间。”

拓展思考

1. 如果公司未来要迁到 Vite/Rollup，如何复用现有扩展点？可以把三层模型抽象成构建中间层，把 Grunt 任务输出成标准 npm scripts，再让 Vite 通过 defineConfig 读取同一 custom/*.json，实现渐进式迁移。
2. 对于toB交付型项目，客户现场无法访问私有 npm，可预先把扩展点打成离线包，利用 grunt.cli.tasks 动态载入本地 .tgz，兼顾内网安全与交付效率。
3. 在Monorepo场景，可以结合 lerna bootstrap 把 grunt/custom/ 提升到根目录，通过 grunt.file.setBase 切换子包上下文，实现一次配置，多包复用，避免重复安装4000+插件带来的幽灵依赖风险。