解读

面试官真正想考察的不是“会不会用 Rollup”，而是能否用数据说服技术决策者。国内团队普遍面临“老项目跑得好好的，为什么要折腾”这一灵魂拷问，因此回答必须围绕成本、收益、风险三轴展开，给出可落地的量化指标，并兼顾国内常见的CI/CD 基础设施、人员技能、合规审计等现实约束。回答时先给评估模型，再用真实数字说话，最后给出决策阈值，体现“高级工程师拍板”的能力。

知识点

1. 构建性能基线：首次冷启动耗时、增量构建耗时、内存峰值、CPU 占用。
2. 产物指标：bundle 体积（gzip 前后）、Tree-shaking 后无效代码占比、运行时 chunk 数、HTTP 请求数。
3. 研发效率：本地热更新时间、CI 平均构建时长、插件生态覆盖率（Grunt 4000+ vs Rollup 官方+社区 700+）。
4. 维护成本：配置行数、插件年更新频率、CVE 漏洞数、TS 类型完整度。
5. 风险指标：迁移人日、回滚窗口（国内上线窗口多为周二/周四晚）、合规要求（如金融项目需通过第三方代码扫描）。
6. 国内特色：
   – 阿里/腾讯/字节内部镜像源对 Rollup 插件的同步延迟；
   – 信创环境（麒麟、统信 UOS）Node 版本锁死 14.x，需验证 Rollup 插件兼容性；
   – 国企代码托管在内网 GitLab，需离线打包所有依赖并生成 SBOM 清单。

答案

我采用“三阶段七指标”模型，两周内给出量化结论。

阶段一：基线采集（3 天）

1. 在现有 Grunt 流程中植入 time-grunt 与 grunt-metrics 插件，连续采集 5 次生产构建数据，取中位数作为基线：
   – 冷启动 127 s、增量 31 s、内存峰值 1.8 GB、产物 1.47 MB（gzip）。
2. 使用 webpack-bundle-analyzer 对 Grunt 拼接后的文件做逆向分析，得出23% 代码未引用。

阶段二：POC 对照（5 天）

1. 抽离 3 个核心入口，用 Rollup 重写构建，插件锁定同一版本（如 @rollup/plugin-terser@0.4.4）。
2. 在同等 Runner（GitLab CI 4 核 8 G）下跑 20 次，得到：
   – 冷启动 38 s（↓70%）、增量 9 s（↓71%）、内存 0.7 GB（↓61%）、产物 0.97 MB（↓34%）。
3. 插件缺口评估：Grunt 用到的 42 个插件中，39 个已有官方或社区 Rollup 等价实现，剩余 3 个自研插件（内部 Less 主题色替换）预计 2 人日可迁移。

阶段三：综合打分（2 天）
建立公式：
迁移得分 = (构建性能提升权重 30% + 产物优化 25% + 维护成本降低 20% + 风险系数 25%) × 100
代入数据：
– 构建性能提升 70% → 30 分
– 产物体积下降 34% → 25×0.85 = 21.3 分
– 维护成本：Gruntfile 763 行 → rollup.config.ts 198 行，下降 74%，得 20×0.9 = 18 分
– 风险系数：迁移人日 10、回滚窗口 4 h、CVE 减少 3 个，按国内经验公式折算 0.28 → 25×(1-0.28)=18 分
总得分 87.3，高于预设阈值 75，结论：值得迁移。
同时给出红线：若 CI 构建时长不能压缩到 50 s 以内或插件缺口 >10%，则中止迁移。

拓展思考

1. 灰度策略：先切 20% 流量到 Rollup 产物，使用阿里云 SLS 实时对比 JS 错误数，若 24 h 内错误率上升 ≥0.05% 立即回滚。
2. 长期演进：Rollup 仅解决“打包”环节，后续可顺势把 Grunt 剩下的“任务编排”迁移到 pnpm monorepo + turbo，实现缓存命中 90% 的终极提效。
3. 人员培养：国内前端普遍对 Rollup 插件开发陌生，可建立**“插件种子库”：把自研插件拆成 5 个标准模板，配套内部直播 + 考试**，两周内让 80% 成员通过“Rollup 插件开发认证”，降低二次开发门槛。