摘要（Auto）

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

建议追问（Auto）

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

关联卡片

• 项目：
  • project__dji-devops
• 对比：
  • matrix__tech-compare-micro-frontend

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

• 典型场景（DevOps 平台/多业务线）：
  • 多团队并行、发布节奏不同：需要“独立部署 + 独立回滚”，降低互相阻塞。
  • 技术栈不完全一致：希望主框架统一壳能力（登录/权限/菜单/埋点），子应用可渐进演进。
• 我负责的落地：
  • 统一主应用壳能力（鉴权、路由、菜单、全局错误与日志链路）。
  • 定义子应用接入规范：资源加载、通信协议、样式隔离、公共依赖共享策略。
  • 处理“隔离与共享”的平衡：既要避免污染，又要避免重复依赖导致的体积与性能问题。

原理简述

qiankun 基于 single-spa 的微前端框架，核心是三件事：加载（Load）/挂载（Mount）/隔离（Sandbox）。

• 加载：
  • 主应用根据路由匹配到子应用，拉取子应用的 HTML/JS/CSS（通常是一个 entry）。
  • 把子应用资源解析并执行，拿到 bootstrap/mount/unmount 生命周期。
• 挂载：
  • 在主应用提供的容器节点里渲染子应用（React/Vue/Angular 都可以）。
  • 需要确保子应用的路由基座（basename）与主应用协调。
• 隔离：
  • JS 隔离（sandbox）：通过 Proxy/快照等方式隔离对 window 的修改，卸载时回滚。
  • 样式隔离：通过 scoped/CSS 前缀/Shadow DOM（视方案）减少样式互相污染。
  • 资源隔离：公共依赖共享与版本约束，避免“多份 React”引发运行时冲突。

权衡与边界：

• 微前端不是银弹：会引入额外的运行时复杂度（加载链路、跨应用状态、调试与监控）。
• 适合的前提：组织上确实需要“自治发布”，并愿意投入治理（规范、监控、性能预算）。

对比表格

方案	隔离	通信	性能	工程复杂度	适用场景
qiankun	JS sandbox + 样式策略	props/全局事件/共享模块	中（有额外 runtime）	中	多团队自治、渐进迁移
iframe	天然强隔离	postMessage	较差（资源重复/通信成本）	低	强隔离/安全优先、低集成需求
Module Federation	共享依赖强	共享模块/契约	佳（可共享依赖）	高	同栈、追求共享与性能、治理能力强

回滚/风险控制：

• 子应用独立回滚（按版本/灰度），主应用只负责加载策略。
• 关键依赖（React 等）统一版本与加载方式，避免“多份运行时”。

模拟问答

• [ ] Q1：你怎么做 JS 隔离？如果子应用改了 window 怎么办？
  • 解释：qiankun sandbox 会拦截对子应用的全局写入；卸载时回滚或还原快照，避免污染主应用与其他子应用。
  • 兜底：对必须共享的全局（埋点 SDK/国际化）走白名单与只读约束。
• [ ] Q2：微前端性能怎么治理？
  • 分层：首屏只加载壳与必要子应用；其他子应用按路由懒加载 + 预取。
  • 预算：子应用包体上限、关键资源 preload、共享依赖策略（避免重复 React）。
  • 监控：子应用维度的 Web Vitals/错误/接口耗时上报并聚合。
• [ ] Q3：注册与加载链路能讲到什么粒度？（entry 获取/HTML 解析/资源注入/生命周期调度）
  • 可复述要点：
    • 注册：主应用根据路由规则（activeRule）决定何时激活子应用。
    • 获取 entry：拉取子应用 HTML，解析出脚本/样式资源地址。
    • 资源注入：把资源按顺序加载执行，拿到 bootstrap/mount/unmount。
    • 调度：在容器内挂载；切换路由时卸载并回收副作用。
• [ ] Q4：CSS 隔离你怎么选？Shadow DOM、前缀化、严格隔离各有什么坑？
  • Shadow DOM：隔离强但样式穿透/第三方组件适配有成本。
  • 前缀化：成本低但不能 100% 防冲突（全局选择器/第三方库）。
  • 严格隔离：体验更“干净”，但需要更强治理与调试能力。
• [ ] Q5：通信怎么做才不“隐式耦合”？props/event bus/共享状态怎么划界？
  • props：同步能力注入（token、用户信息、埋点函数），适合“只读能力”。
  • event bus：跨应用广播与解耦，但要有 schema（事件类型/版本）防止乱发乱收。
  • 共享状态：仅限少数全局状态（登录态/权限），其余尽量业务域内自洽。

手写代码区

一个最小 qiankun 接入片段（主应用注册子应用）：

import { registerMicroApps, start } from 'qiankun'

registerMicroApps([
  {
    name: 'sub-app-a',
    entry: '//localhost:7100',
    container: '#subapp-container',
    activeRule: '/app-a',
    props: { tokenGetter: () => localStorage.getItem('token') }
  }
])

start({
  sandbox: { experimentalStyleIsolation: true },
  prefetch: 'all' // 可根据路由热度策略化
})

我的补充（Manual）

（不会被脚本覆盖：踩坑、细节、反例、排查路径）

复盘与反思（Learnings）

• 如果重做会怎么改？

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

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