微前端与 qiankun
微前端解决 多团队、多仓库、多技术栈 在同一门户内 独立开发、独立部署，对外呈现为一个站点体验。
常见方案对比（极简）
| 方案 | 特点 |
|---|---|
| iframe | 隔离最强，通信与体验成本高（路由、高度、双滚动条） |
| qiankun（single-spa） | 同页集成接近 SPA，需处理公共依赖与样式隔离 |
| Module Federation | webpack5 模块联邦，共享依赖粒度细，运维心智不同 |
qiankun 核心概念
| 概念 | 说明 |
|---|---|
| 主应用（基座） | 路由、菜单、登录态、加载子应用 |
| 子应用 | 独立构建；publicPath、路由 basename 与网关路径对齐 |
| 生命周期 | bootstrap → mount → unmount，需幂等、卸载时清理定时器与监听 |
| 沙箱 | 减轻子应用对 window 的全局污染（实现随版本演进） |
选型优势
- 团队边界清晰：子团队拥有完整仓库与发布节奏。
- 技术栈可异构：例如主 Vue + 子 React（成本高于同栈，需评估）。
- 增量迁移：老系统可渐进迁入子应用。
集成注意点
activeRule/basename/ Nginxlocation一致，否则刷新 404。- 静态资源路径：生产环境
publicPath必须为可解析绝对前缀或 CDN 根。 - 样式隔离：BEM、CSS Modules、
scoped、Shadow DOM（按版本能力选用）。 - 公共依赖：
vue/react是否提升为主应用 externals，避免重复加载或版本冲突。
调试建议
子应用 单独可访问（直连 devServer），集成时在基座对应路由打开；Network 优先排查 JS/CSS 404、跨域与 Cookie 域。
小结
微前端 不是没有成本的银弹：运维、监控、样式与依赖治理都会变复杂。适用场景是 组织规模与发布独立性 确实需要；若仅是代码体量大可优先 Monorepo + 懒加载。选型 qiankun 时把 路由与静态资源路径 一次性对齐，可省去大部分线上故障。