摘要（Auto）

• 生成时间：2025-12-20
• 简历中出现的项目标题（提取）：大疆用户中心重构 / 大疆售后 RMS 系统重构 / 跨平台公告插件系统 / 大疆 DevOps 平台维护 / XDR 系统 - 魔方大屏 + 报表
• 面试大纲关键词（提取 Top10）：1）大疆用户中心重构：性能优化 + HTTP 原理 + Webpack 架构 / 性能指标与方法论 / 简历可落地点（结合你的“优化四板斧”） / HTTP 常考点（从“为什么变快”倒推） / Webpack 架构（工程化面试常考） / 按优化顺序，把方案“串起来”（排查 → 定位 → 选择 → 验证） / 0. 排查与基线（先把问题“量化”） / 1. 先保“可见”——骨架屏预渲染（直接拉低 LCP） / 2. 再减“阻塞”——关键渲染路径（CRP）梳理：CSS/字体/首图优先级 / 3. 再降“下载与解析成本”——更小的包体与更少的无效代码

建议追问（Auto）

• 你为什么在该项目/场景里选择这个方案？替代方案为何不选？
• 最大一次事故/踩坑是什么？如何定位与回滚？
• 如果重做：架构/边界/工程化会怎么调整？

在我项目中的角色与使用场景

关联卡片

• 技术：
  • tech__webpack
  • tech__vite
  • tech__rollup
• 项目：
  • project__dji-user-center
  • project__dji-rms
  • project__announce-plugin

在我项目中的角色与使用场景

• 我常见的选型场景有三类：
  • 大存量应用（中后台/多团队）：优先考虑生态与可控性（Webpack）。
  • 新项目或中等存量：优先开发体验与迭代效率（Vite）。
  • SDK/组件库/插件：优先产物质量与 tree-shaking（Rollup）。
• 面试表达重点：不是背表格，而是先讲约束（存量、团队、发布风险），再讲目标（DX/产物/治理），最后讲回滚策略。

原理简述

把“本质”讲清楚就能自然做取舍：

• Webpack：模块图 + loader/plugin 生命周期，适合“复杂应用构建 + 强定制”。
• Vite：开发期原生 ESM + 依赖预构建（esbuild），生产用 Rollup，适合“追求 DX 的应用构建”。
• Rollup：以 ESM 静态分析为核心，tree-shaking 强，适合“库构建/多格式输出”。

适用边界（面试常问）：

• Webpack：当你依赖大量 loader/plugin、并且构建链路很复杂（多入口、多环境、多团队）时更稳。
• Vite：当你更在乎“启动与 HMR”，并且依赖生态可满足、迁移风险可控时更划算。
• Rollup：当产物需要被外部系统引用，external/exports/types 很关键时更合适。

对比表格

（A=Webpack，B=Vite，C=Rollup）：

维度	Webpack	Vite	Rollup
开发体验	中（大项目易慢）	高（启动/HMR 快）	中（不以 dev 为核心）
构建速度	中（可优化）	中-高（生产 Rollup）	高（库场景）
产物体积	中（取决于配置）	中（Rollup）	小且干净
生态成熟度	最高	高（成长快）	高（偏库）
迁移成本	低（存量）	中	高（应用链路不完整）
风险与回滚	配置变更可灰度	迁移期需双构建/旁路	更适合新库，不建议全量替换

模拟问答

• [ ] Q1：为什么最终选这个？反例是什么？
  • 推荐回答结构：Context → Problem → Solution → Outcome → Learnings

<<<<<<< Current (Your changes) <<<<<<< Current (Your changes)

• [ ] Q2：你怎么把“构建性能预算（budgets）”做成团队可执行的门禁？

  • 预算维度：入口/关键路由 chunk、vendor、首屏关键资源（CSS/字体/首图），分别设上限。
  • 门禁落地：CI 解析 stats.json 或产物体积清单；超阈值直接 fail 或要求审批。
  • 反例：只盯“总包体”容易误导，应该盯“关键路径 + 关键路由”。

• [ ] Q3：sourceMap 怎么选？为什么生产不一定开 source-map？

  • 开发：优先反馈速度（例如 cheap/inline/eval 类）。
  • 生产：考虑构建耗时/体积/源码泄露风险；通常用 hidden-source-map 并只上传到错误系统。
  • 口径：线上要“可追溯”，但不需要“对外暴露”。

• [ ] Q4：Webpack → Vite 迁移你最担心什么？怎么旁路验证与回滚？

  • 风险点：loader/plugin 替代、CJS/UMD 兼容、legacy 浏览器 polyfill、产物 chunk/缓存策略差异。
  • 验证：双构建并行（Webpack 主线、Vite 旁路），先对齐产物功能一致性，再灰度观察 LCP/INP/CLS/错误率。
  • 回滚：路由级开关/回滚到上一个稳定构建产物（与 CI/CD 可追溯配套）。

• [ ] Q5：为什么“库构建”更偏 Rollup？Vite 的库模式和 Rollup 有什么差别？

  • 核心：库更在乎 external/多格式输出/产物干净/tree-shaking。
  • Vite 库模式底层仍是 Rollup，但对 dev/生态更友好；复杂库场景仍可能直接 Rollup 更可控。

• [ ] Q6：并行化/缓存怎么选？什么时候优化会适得其反？

  • 并行：核数少/CI 资源紧张时线程切换成本可能 > 收益；I/O 瓶颈时并行会抢磁盘。
  • 缓存：输入稳定才能命中（依赖版本、配置、环境变量）；否则“看起来开了缓存但没收益”。

Incoming (Background Agent changes)

Incoming (Background Agent changes) 建议你背的“选型回答模版”（通用，能打所有构建工具问题）：

• Context：我们的约束是 X（存量/团队/插件/发布节奏）。
• Problem：当前痛点是 Y（启动慢、HMR 慢、产物不友好、库体积大）。
• Solution：对比 A/B/C，从“DX/产物/治理/迁移成本/回滚”五个维度做取舍。
• Outcome：用“口径”说结果（构建时长、包体预算、线上性能趋势、回滚次数等）。
• Learnings：下次会怎么更快做决策（先试点、双构建、以指标驱动）。

手写代码区

一个“选型验证 PoC”清单（伪代码/步骤）：

1) 选一个真实业务路由作为样板（依赖复杂、首屏关键）
2) 在 Webpack/Vite 各做一份构建（保持功能一致）
3) 记录指标：
   - dev 冷启动耗时、HMR 耗时
   - prod 构建耗时、产物体积、chunk 数量
   - 线上关键指标（LCP/INP/CLS）趋势（灰度）
4) 风险清单：
   - loader/plugin 替代方案
   - legacy 浏览器与 polyfill
   - CI/CD 与回滚策略

我的补充（Manual）

（不会被脚本覆盖：真实约束、组织因素、踩坑）

复盘与反思（Learnings）

• 如果重做会怎么改？

面试官追问（面试官视角）

• [ ] 为什么选这个方案？替代方案为什么不选？
• [!] 最大一次事故/踩坑是什么？如何定位与回滚？
• [ ] 如果重做会怎么改？