# micro-app 多子应用接入实战面试题

> 基于在已有主应用中接入第二个 Vue 3 + Vite 子应用（端口 3001）的完整实战经验整理。

---

## 一、多子应用注册与路由

### Q1：如何在已有 micro-app 主应用中新增一个子应用？需要改哪些文件？

**答：**
只需要改 **3 个文件**，遵循「配置 → 路由 → 导航」的顺序：

**1. `src/config/subApps.ts` — 添加子应用配置**

```ts
export const subApps: SubAppConfig[] = [
  {
    name: 'vue2-app',
    url: 'http://localhost:5173/',
    baseroute: '/child-app',
    iframe: true,
    keepAlive: true,
    routerMode: 'native'
  },
  // ✅ 新增
  {
    name: 'vue3-app',
    url: 'http://localhost:3001/',
    baseroute: '/vue3-app',
    iframe: true,
    keepAlive: true,
    routerMode: 'native'
  }
]
```

**2. `src/router/index.ts` — 添加通配路由**

```ts
const routes = [
  // ... 其他路由
  {
    path: '/vue3-app/:page*',   // ✅ 新增：通配符匹配子应用所有内部路由
    name: 'vue3App',
    component: () => import('@/views/ChildApp.vue')
  }
]
```

**3. `src/App.vue` — 导航栏添加入口**

```html
<router-link to="/vue3-app">Vue3 子应用</router-link>
```

**不需要改的文件：**
- `ChildApp.vue` — 容器组件是通用的，根据 URL 自动匹配配置
- `main.ts` — `microApp.start()` 是框架级初始化，不绑定具体子应用
- `vite.config.ts` — `isCustomElement` 配置对所有 `<micro-app>` 标签生效

---

### Q2：为什么要设计成"3 个文件改动"的模式？能否进一步减少？

**答：**
这是 micro-app 架构设计中最简洁的扩展模式：

| 改动 | 为什么必须 |
|------|-----------|
| `subApps.ts` | 子应用的元信息（name、url、baseroute）必须有地方存储 |
| `router/index.ts` | Vue Router 需要知道哪些 URL 前缀交给子应用处理 |
| `App.vue` | 用户需要入口点击进入子应用 |

**能否合并？**

可以。如果子应用数量很多，可以优化为**自动注册**模式：

```ts
// router/index.ts — 自动为所有子应用生成路由
import { subApps } from '@/config/subApps'

const subAppRoutes = subApps.map(app => ({
  path: `${app.baseroute}/:page*`,
  name: app.name,
  component: () => import('@/views/ChildApp.vue')
}))

const routes = [
  { path: '/', redirect: '/home' },
  { path: '/home', component: () => import('@/views/Home.vue') },
  ...subAppRoutes  // 自动展开
]
```

导航栏同理，用 `v-for` 遍历 `subApps` 自动生成。这样新增子应用只需要改 `subApps.ts` 一个文件。

---

### Q3：`ChildApp.vue` 组件是如何做到"一个组件服务所有子应用"的？

**答：**
核心原理是通过 **路由路径匹配配置**：

```ts
// ChildApp.vue 的核心逻辑
const currentApp = computed(() => {
  const matched = subApps.find((app) =>
    route.path.startsWith(app.baseroute)
  )
  return matched || subApps[0]
})
```

```html
<micro-app
  :key="currentApp.url"
  :name="currentApp.name"
  :url="currentApp.url"
  :baseroute="currentApp.baseroute"
  <!-- 所有属性都从 currentApp 动态绑定 -->
/>
```

**工作流程：**
1. 用户访问 `/vue3-app/dashboard`
2. Vue Router 匹配到通配路由 → 渲染 `ChildApp.vue`
3. `ChildApp.vue` 内的 `computed` 检查 `route.path` 以哪个 `baseroute` 开头
4. 找到 `vue3-app` 配置 → 绑定到 `<micro-app>` 标签
5. micro-app 框架根据 `name` + `url` 加载对应的子应用

**关键设计点：**
- `:key="currentApp.url"` — 当切换到不同子应用时，Vue 会销毁旧的 `<micro-app>` 重建新的
- `keepAlive: true` — 切换回来时不销毁，保持应用状态
- 未匹配到任何 `baseroute` 时的兜底逻辑：`|| subApps[0]`

---

## 二、路由冲突与优先级

### Q4：如果主应用有一个 `/about` 路由，子应用也有一个 `/about` 路由，且子应用没有设置 router base，访问时会发生什么？

**答：**
**结论：不会冲突，展示哪个取决于 URL。**

| 访问路径 | 展示内容 | 原因 |
|----------|----------|------|
| `/about` | 主应用的 About | 主应用路由直接匹配，不经过子应用 |
| `/vue3-app/about` | 子应用的 About | 主应用路由匹配 `/vue3-app/:page*`，交给子应用处理 |

**完整流程图：**

```
浏览器输入: http://localhost:8080/about
                │
                ▼
    主应用 Vue Router 开始匹配
                │
        ┌───────┴───────┐
        │               │
   主应用有 /about   主应用没有 /about
        │               │
        ▼               ▼
   展示主应用 About   404 / fallback
   （子应用完全不会
     被加载）
```

```
浏览器输入: http://localhost:8080/vue3-app/about
                │
                ▼
    主应用 Vue Router 匹配
                │
                ▼
    命中 /vue3-app/:page* 通配路由
                │
                ▼
    渲染 ChildApp.vue → 加载 <micro-app>
                │
                ▼
    micro-app 剥离 baseroute(/vue3-app)
    传给子应用内部路由: /about
                │
                ▼
    子应用 Vue Router 匹配 /about
                │
                ▼
    展示子应用 About 页面
```

---

### Q5：子应用不设置 router base 会有什么隐患？

**答：**
虽然 micro-app 的 `baseroute` 机制能拦截 pushState 并自动拼接前缀，让大部分场景"看起来正常"，但仍有 **4 个隐患**：

| 隐患 | 说明 | 风险等级 |
|------|------|----------|
| `window.location` 误用 | 代码中直接读 `location.pathname` 会得到完整路径 `/vue3-app/about`，而不是期望的 `/about` | ⭐⭐⭐ 高 |
| 静态资源 404 | `<img src="/assets/logo.png">` 会请求主应用的 8080 端口而非子应用的 3001 端口 | ⭐⭐⭐ 高 |
| 独立运行失败 | 不经过主应用直接访问子应用时，base 为空字符串，路由跳转可能出错 | ⭐⭐ 中 |
| `history.go()` 异常 | 直接操作浏览器历史时不经过 micro-app 拦截，可能跳出微前端上下文 | ⭐ 低 |

**最佳实践：**

```ts
// 子应用 router/index.ts
import { createRouter, createWebHistory } from 'vue-router'

const router = createRouter({
  history: createWebHistory(
    // 动态适配：微前端环境用 baseroute，独立运行用 '/'
    window.__MICRO_APP_BASE_ROUTE__ || '/'
  ),
  routes: [
    { path: '/about', component: () => import('@/views/About.vue') }
  ]
})
```

`window.__MICRO_APP_BASE_ROUTE__` 是 micro-app 注入到子应用 window 上的全局变量，值就是主应用中配置的 `baseroute`。

---

### Q6：micro-app 是如何实现"主应用路由和子应用路由互不干扰"的？

**答：**
通过 **URL 命名空间隔离** 机制：

```
主应用路由空间（Vue Router 管理）
├── /                    → 重定向到 /home
├── /home                → Home.vue
├── /about               → About.vue (如果定义了)
├── /child-app/:page*    → 子应用 vue2-app 的领地
└── /vue3-app/:page*     → 子应用 vue3-app 的领地

子应用 vue2-app 路由空间（内部 Router 管理，剥离 /child-app 前缀后）
├── /                    → 首页
├── /about               → 关于页
└── /user/:id            → 用户详情

子应用 vue3-app 路由空间（内部 Router 管理，剥离 /vue3-app 前缀后）
├── /                    → 首页
├── /about               → 关于页
└── /dashboard           → 控制台
```

**三层隔离保证：**

1. **Vue Router 层级** — 主应用的 `/about` 和通配路由 `/vue3-app/:page*` 互斥匹配，不会同时命中
2. **baseroute 剥离** — micro-app 在将 URL 传给子应用前，自动去除 baseroute 前缀
3. **iframe 沙箱** — Vite 子应用运行在独立 iframe 中，`window.location` 指向自己的 origin

---

## 三、SubAppConfig 接口设计

### Q7：`SubAppConfig` 接口各字段的作用和设计考量是什么？

**答：**

```ts
export interface SubAppConfig {
  name: string              // 全局唯一标识，字母开头
  url: string               // 子应用 devServer / 生产地址
  baseroute: string         // 主应用分配给子应用的 URL 命名空间
  iframe?: boolean          // 是否使用 iframe 沙箱
  keepAlive?: boolean       // 切换时是否保活
  routerMode?: 'native' | 'native-scope'
  disableScopecss?: boolean // 禁用样式隔离
  disableSandbox?: boolean  // 禁用 JS 沙箱
}
```

| 字段 | 为什么可选/必填 | 设计考量 |
|------|----------------|----------|
| `name` | 必填 | micro-app 框架需要唯一标识来管理子应用生命周期 |
| `url` | 必填 | 不知道地址就无法加载；生产环境应通过环境变量注入 |
| `baseroute` | 必填 | 决定 URL 命名空间，也影响子应用的资源路径解析 |
| `iframe` | 可选，默认 false | Vite 子应用必须设为 true（ES Module 兼容性） |
| `keepAlive` | 可选 | 高频切换场景开启可提升体验，但占用内存 |
| `routerMode` | 可选 | `native-scope` 提供额外的作用域隔离 |
| `disableScopecss` | 可选 | 调试时临时关闭样式隔离，排查样式问题 |
| `disableSandbox` | 可选 | 调试时临时关闭沙箱，确认是否是沙箱引起的 bug |

---

### Q8：为什么 Vite 子应用的 `iframe` 必须设为 `true`？

**答：**
见 [基础面试题 Q7](./micro-app面试题.md#q7遇到-cannot-use-import-statement-outside-a-module-报错是什么原因如何解决)，核心原因：

```
Vite devServer 输出 ES Module (type="module")
        ↓
with 沙箱用 new Function() 执行 JS
        ↓  
new Function() 无法解析 import/export 语法
        ↓
❌ SyntaxError: Cannot use import statement outside a module
```

**解决：** `iframe: true` → 浏览器原生 iframe 天然支持 `<script type="module">`

---

## 四、扩展与自动化

### Q9：子应用数量从 1 个增长到 10 个后，路由和导航如何自动管理？

**答：**
将硬编码改为**配置驱动**：

**路由自动生成：**

```ts
// router/index.ts
import { subApps } from '@/config/subApps'

const routes = [
  { path: '/', redirect: '/home' },
  { path: '/home', name: 'home', component: () => import('@/views/Home.vue') },
  // 自动为每个子应用生成通配路由
  ...subApps.map(app => ({
    path: `${app.baseroute}/:page*`,
    name: app.name,
    component: () => import('@/views/ChildApp.vue')
  }))
]
```

**导航自动生成：**

```html
<!-- App.vue -->
<router-link
  v-for="app in subApps"
  :key="app.name"
  :to="app.baseroute"
>
  {{ app.name }}
</router-link>
```

这样新增子应用只需要在 `subApps` 数组中加一行配置，路由和导航自动生效。

---

### Q10：如果有两个子应用的 `baseroute` 配置成了同一个值，会发生什么？

**答：**
会出现**不确定行为**：

1. **路由层面**：Vue Router 按数组顺序匹配，第一个通配路由先命中，后面的永远不会被访问
2. **`ChildApp.vue`**：`subApps.find(app => route.path.startsWith(app.baseroute))` 返回数组中第一个匹配的配置
3. **结果**：第二个子应用永远加载不到，且不会有任何报错提示

**防御措施：**

```ts
// subApps.ts — 启动时校验
if (import.meta.env.DEV) {
  const routes = subApps.map(a => a.baseroute)
  const duplicates = routes.filter((r, i) => routes.indexOf(r) !== i)
  if (duplicates.length) {
    console.error(`[SubApp] 重复的 baseroute: ${duplicates.join(', ')}`)
  }

  const names = subApps.map(a => a.name)
  const dupNames = names.filter((n, i) => names.indexOf(n) !== i)
  if (dupNames.length) {
    console.error(`[SubApp] 重复的 name: ${dupNames.join(', ')}`)
  }
}
```

---

## 五、环境管理与部署

### Q11：开发环境和生产环境子应用 URL 不同，如何管理？

**答：**
使用环境变量：

```ts
// src/config/subApps.ts
export const subApps: SubAppConfig[] = [
  {
    name: 'vue3-app',
    // 开发环境用 localhost，生产环境用实际部署地址
    url: import.meta.env.VITE_VUE3_APP_URL || 'http://localhost:3001/',
    baseroute: '/vue3-app',
    iframe: true,
    keepAlive: true,
    routerMode: 'native'
  }
]
```

```bash
# .env.development
VITE_VUE3_APP_URL=http://localhost:3001/

# .env.production
VITE_VUE3_APP_URL=https://vue3-app.your-domain.com/
```

这样开发和部署环境自动切换，无需修改代码。

---

### Q12：这套架构中，如何保证子应用独立部署时不影响其他子应用？

**答：**
三个关键点：

1. **独立端口/域名**：每个子应用有自己的 devServer（3001、5173）和生产域名
2. **独立的 CI/CD**：每个子应用独立构建、独立发版，不耦合
3. **主应用只做路由分发**：主应用不包含子应用的业务逻辑，子应用挂了只影响自己的路由

**故障隔离效果：**

| 场景 | 影响范围 |
|------|----------|
| 子应用 vue2-app 挂了 | 只有 `/child-app/*` 不可用，主应用和 vue3-app 正常 |
| 主应用挂了 | 所有子应用都不可访问（主应用是入口） |
| 子应用 JS 报错 | iframe 沙箱内错误不污染主应用 |

---

## 六、Vue 3 子应用工程化创建（实战完整流程）

### Q13：从零创建一个 Vue 3 + Vite 子应用，需要哪几步？

**答：**
完整流程分 **4 个阶段，共 8 步**：

| 阶段 | 步骤 | 操作 |
|------|------|------|
| 脚手架 | 1 | `npm create vite@latest microapp-vue3 -- --template vue-ts` |
| 脚手架 | 2 | `npm install && npm install vue-router@4 @micro-zoe/micro-app` |
| 配置改造 | 3 | 改造 `vite.config.ts`（端口/base/CORS/alias/isCustomElement） |
| 配置改造 | 4 | 改造 `tsconfig.app.json`（`@/*` 路径别名） |
| 入口改造 | 5 | 创建 `vite-env.d.ts`（micro-app 全局类型声明） |
| 入口改造 | 6 | 改造 `index.html`（独立挂载点 id） |
| 入口改造 | 7 | 改造 `main.ts`（mount/unmount 生命周期 + 双模式） |
| 业务代码 | 8 | 创建 router + views（完成路由通配和页面） |

下面逐一拆解每个阶段的细节和踩坑点。

---

### Q14：子应用的 `vite.config.ts` 需要配置哪些关键项？为什么？

**答：**
完整的 Vite 子应用配置文件如下，每个配置项都有明确的原因：

```ts
import { fileURLToPath, URL } from 'node:url'
import { defineConfig } from 'vite'
import vue from '@vitejs/plugin-vue'

export default defineConfig({
  // ① 路径别名 — 与 tsconfig 的 paths 配合，支持 @/ 导入
  resolve: {
    alias: {
      '@': fileURLToPath(new URL('./src', import.meta.url))
    }
  },

  plugins: [
    vue({
      template: {
        compilerOptions: {
          // ② 自定义元素注册 — 避免 Vue 对 <micro-app> 标签报警告
          isCustomElement: (tag) => /^micro-app/.test(tag)
        }
      }
    })
  ],

  // ③ base 路径 — 必须与主应用的 baseroute 一致
  base: '/vue3-app/',

  server: {
    // ④ 端口 — 子应用独立端口，避免与主应用(8080)或其他子应用冲突
    port: 3001,

    // ⑤ CORS 头 — 主应用跨域加载子应用资源必须配置
    headers: {
      'Access-Control-Allow-Origin': '*'
    }
  }
})
```

| 配置项 | 必须？ | 不配置的后果 |
|--------|--------|-------------|
| `resolve.alias` | 推荐 | `import xxx from '@/views/Home.vue'` 无法解析 |
| `isCustomElement` | 推荐 | Vue 警告 `Failed to resolve component: micro-app` |
| `base` | **必须** | 静态资源 404，路由跳转路径错乱 |
| `port` | 推荐 | 默认 5173，可能与已有子应用冲突 |
| `CORS` | **必须** | 主应用无法加载子应用资源（跨域被浏览器拦截） |

---

### Q15：为什么子应用的 `index.html` 挂载点不能用 `#app`？

**答：**
这是一个**两个项目共用同一个 DOM 根节点**的经典问题。

```
主应用 index.html：      <div id="app"></div>
子应用 index.html：      <div id="app"></div>  ← ❌ 冲突！
```

在 iframe 沙箱模式下，子应用运行在独立 iframe 中，理论上 id 重复不会直接冲突。但有两个隐患：

1. **语义混乱** — 维护者无法从 id 区分是主应用还是子应用的根节点
2. **非 iframe 模式风险** — 如果未来改用 with 沙箱（禁用 iframe），两个 `#app` 同时存在于同一个 document，`mount('#app')` 会挂载到错误的节点，导致页面错乱

**正确做法：** 使用语义化的独立命名：

```html
<!-- 子应用 index.html -->
<div id="microapp-vue3-root"></div>
```

```ts
// 子应用 main.ts — 挂载点保持一致
app.mount('#microapp-vue3-root')

// 卸载时清理
function unmount() {
  const root = document.getElementById('microapp-vue3-root')
  if (root) {
    root.innerHTML = ''
  }
}
```

**命名建议：** `<项目名>-root`，如 `microapp-vue3-root`、`portal-root`、`dashboard-root`。

---

### Q16：子应用的 `main.ts` 中 mount/unmount 生命周期是如何设计的？

**答：**
核心模式是 **双模式入口**：微前端环境导出生命周期，独立运行直接挂载。

```ts
import { createApp } from 'vue'
import type { App as VueApp } from 'vue'  // ① type-only import
import App from './App.vue'
import router from './router'

let app: VueApp | null = null

function mount(): void {
  app = createApp(App)
  app.use(router)
  app.mount('#microapp-vue3-root')        // ② 独立挂载点
}

function unmount(): void {
  if (app) {
    app.unmount()                          // ③ Vue 3 销毁
    const root = document.getElementById('microapp-vue3-root')
    if (root) root.innerHTML = ''          // ④ 清空 DOM 残留
    app = null
  }
}

// ⑤ 环境判断 — 决定使用哪种模式
if (window.__MICRO_APP_ENVIRONMENT__) {
  // 微前端环境：导出生命周期给 micro-app 框架调用
  window[`micro-app-${window.__MICRO_APP_NAME__}`] = { mount, unmount }
} else {
  // 独立运行：直接挂载，方便开发调试
  mount()
}
```

**设计要点：**

| 要点 | 说明 |
|------|------|
| `type-only import` | `App` 类型从 `vue` 导入必须用 `import type`，否则生产构建报 `MISSING_EXPORT` 错误 |
| `app: VueApp \| null` | 用闭包变量持有实例引用，mount 创建、unmount 销毁 |
| `unmount()` 清理 | Vue 3 的 `app.unmount()` 不会清除 DOM，需手动 `innerHTML = ''` |
| 微前端环境判断 | `window.__MICRO_APP_ENVIRONMENT__` 是 micro-app 注入的，框架级保证 |
| 生命周期导出 | `window['micro-app-' + name]` 是 micro-app 约定的命名规则 |

---

### Q17：为什么 `import { App } from 'vue'` 在生产构建时会报错？如何修复？

**答：**
这是 Vite 8 / Rolldown 构建时的 **类型导出与运行时分包** 问题。

**报错信息：**
```
[MISSING_EXPORT] "App" is not exported by "node_modules/vue/dist/vue.runtime.esm-bundler.js"
```

**根因分析：**

Vue 3 的 `App` 是一个 **TypeScript 接口**，不是运行时值。在生产构建中，Vue 的 `esm-bundler` 版本只导出运行时 API（`createApp`、`ref`、`computed` 等），不导出类型。

```ts
// ❌ 错误写法：App 既是值又是类型，构建工具无法区分
import { createApp, App as VueApp } from 'vue'

// ✅ 正确写法：用 import type 明确告知这仅用于类型标注
import { createApp } from 'vue'
import type { App as VueApp } from 'vue'
```

**为什么会混淆？**
- `vue-tsc --noEmit` 类型检查能通过（TypeScript 知道 `App` 是类型）
- `vite build` 构建失败（Rolldown 试图在运行时模块中找 `App` 的值导出）

**核心原则：** 凡是只用于 TypeScript 类型标注的导入，一律使用 `import type`：

```ts
import type { App } from 'vue'           // ✅ Vue 实例类型
import type { Router } from 'vue-router'  // ✅ 路由实例类型
import type { DefineComponent } from 'vue' // ✅ 组件类型
```

---

### Q18：`vite-env.d.ts` 中需要声明哪些 micro-app 相关的全局类型？

**答：**
micro-app 框架会在子应用的 `window` 上注入 4 个关键全局变量，必须显式声明类型：

```ts
/// <reference types="vite/client" />

declare module '*.vue' {
  import type { DefineComponent } from 'vue'
  const component: DefineComponent<object, object, unknown>
  export default component
}

// micro-app 全局类型声明
interface Window {
  /** 是否运行在微前端环境中 */
  __MICRO_APP_ENVIRONMENT__?: boolean

  /** 应用名称（等于主应用中配置的 name） */
  __MICRO_APP_NAME__?: string

  /** 基础路由（等于主应用中配置的 baseroute） */
  __MICRO_APP_BASE_ROUTE__?: string

  /** 公共路径（用于拼接静态资源路径） */
  __MICRO_APP_PUBLIC_PATH__?: string
}
```

| 全局变量 | 谁注入 | 典型用途 | 示例值 |
|----------|--------|----------|--------|
| `__MICRO_APP_ENVIRONMENT__` | micro-app | 判断是否在微前端环境，决定导出生命周期还是直接挂载 | `true` / `undefined` |
| `__MICRO_APP_NAME__` | micro-app | 拼接生命周期导出 key：`window['micro-app-' + name]` | `'vue3-app'` |
| `__MICRO_APP_BASE_ROUTE__` | micro-app | Vue Router 的 `base` 参数 | `'/vue3-app'` |
| `__MICRO_APP_PUBLIC_PATH__` | micro-app | 拼接静态资源 URL | `'http://localhost:3001/'` |

**面试延伸：** 为什么要声明为 `?:`（可选）而不是必填？
> 因为子应用需要同时支持**独立运行**（直接 `npm run dev` 访问 3001 端口）和**微前端环境**（通过主应用 8080 端口加载）。独立运行时这些变量不存在，所以必须标记为可选。

---

### Q19：`tsconfig.app.json` 中 `@/*` 路径别名和 Vite 的 `resolve.alias` 有什么关系？为什么需要两处配置？

**答：**
这对应了**类型系统**和**构建系统**两条独立管线：

```
tsconfig.app.json 的 paths                vite.config.ts 的 resolve.alias
         │                                           │
         ▼                                           ▼
    TypeScript 编译器                             Vite/Rolldown 打包器
    (类型检查阶段)                               (构建阶段)
         │                                           │
         └───────────┬───────────────────────────────┘
                     │
                     ▼
              开发者写 import xxx from '@/views/Home.vue'
              TypeScript 能找对类型 ✓
              Vite 打包能找到文件 ✓
```

**配置对比：**

| 位置 | 配置 | 作用 |
|------|------|------|
| `tsconfig.app.json` | `"paths": { "@/*": ["./src/*"] }` + `"baseUrl": "."` | 让 TS 理解 `@/` 指向 `src/` |
| `vite.config.ts` | `resolve: { alias: { "@": fileURLToPath(...) } }` | 让 Vite 构建时正确解析路径 |

**常见错误：**

| 现象 | 原因 | 修复 |
|------|------|------|
| TS 报红波浪线但能跑 | 只配了 Vite alias，没配 tsconfig paths | 补充 `tsconfig.app.json` 的 paths |
| `vue-tsc --noEmit` 报错但能构建 | 同上（tsconfig 缺 paths） | 同上 |
| 构建报错找不到模块 | 只配了 tsconfig paths，没配 Vite alias | 补充 `vite.config.ts` 的 resolve.alias |

---

### Q20：子应用开发完成后，如何验证它作为 micro-app 子应用的可用性？

**答：**
三层验证策略：

**第一层：类型检查**
```bash
npx vue-tsc --noEmit
```
- 验证所有类型标注正确
- 检查 micro-app 全局变量的类型使用
- 确保 `import type` 用在正确的位置

**第二层：独立构建**
```bash
npm run build
```
- 验证 Vite 生产构建能通过（暴露 `import type` 问题）
- 输出 `dist/` 产物，确认资源路径基于 `/vue3-app/` 正确生成
- 典型坑：`"App" is not exported` → 修复 `import type`

**第三层：联调验证**
```bash
# 终端 1 — 启动子应用（独立模式）
cd microapp-vue3 && npm run dev
# 访问 http://localhost:3001 — 确认页面正常、路由跳转正常

# 终端 2 — 启动主应用
cd microapp-main && npm run dev
# 访问 http://localhost:8080/vue3-app — 确认通过主应用加载正常
```

**验证清单：**

| 检查项 | 通过标准 |
|--------|----------|
| 独立运行首页 | `localhost:3001` 展示 Home 页面，路由跳转正常 |
| 独立运行 about | `localhost:3001/about` 展示 About 页面 |
| 主应用加载 | `localhost:8080/vue3-app` 通过主应用正常渲染子应用 |
| 子应用内路由 | `localhost:8080/vue3-app/about` 展示子应用的 About 页 |
| 环境检测 | Home 页面显示"🟢 微前端环境"而非"🔵 独立运行" |
| 控制台无报错 | 无 CORS 错误、无 MIME type 错误、无 Vue 警告 |

---

### Q21：Vite 8 项目中 `erasableSyntaxOnly` 和 `noUnusedLocals` 配置对 micro-app 子应用开发有什么影响？

**答：**
Vite 8 的默认 `tsconfig.app.json` 引入了更严格的 TypeScript 检查：

```json
{
  "compilerOptions": {
    "noUnusedLocals": true,      // 未使用的局部变量报错
    "noUnusedParameters": true,   // 未使用的参数报错
    "erasableSyntaxOnly": true    // 仅允许可擦除的 TS 语法
  }
}
```

| 选项 | 含义 | 对子应用开发的影响 |
|------|------|-------------------|
| `erasableSyntaxOnly` | 只允许不产生运行时痕迹的 TS 语法 | **强制使用 `import type`** — 因为普通的 `import { App }` 会在 JS 输出中留下导入语句，如果模块不存在该导出，会运行时/构建时出错 |
| `noUnusedLocals` | 未使用的局部变量报错 | 生命周期回调参数如果未使用，需用 `_` 前缀（如 `_e`） |
| `noUnusedParameters` | 未使用的函数参数报错 | 同上，回调参数必须消费或以 `_` 开头 |

**`erasableSyntaxOnly` 与 micro-app 的关系：**

这个选项恰好帮我们避免了 Q17 中的构建错误 — 如果开启了 `erasableSyntaxOnly`，你写的 `import { App } from 'vue'` 会在类型检查阶段就报错（因为 `App` 是类型，应使用 `import type`），从而**在开发阶段就暴露了生产构建才会出现的问题**。

这是一个很好的 **"左移"工程实践** — 类型检查期间就捕获构建期错误。

---

### Q22：子应用路由中使用 `window.__MICRO_APP_BASE_ROUTE__ || '/'` 的兜底逻辑，在什么场景下会用到 `'/'`？

**答：**
`'/'` 作为 fallback 值的设计覆盖了 **两个关键场景**：

**场景一：独立开发调试**
```bash
npm run dev
# 子应用独立运行在 localhost:3001
# window.__MICRO_APP_BASE_ROUTE__ === undefined
# router base → '/'  ← 走兜底
# 访问 /、/about 正常工作
```

**场景二：单元测试 / E2E 测试**
```ts
// 测试文件中直接创建 router
const router = createRouter({
  history: createWebHistory('/'),
  routes
})
// 不需要 mock __MICRO_APP_BASE_ROUTE__
```

**如果不写兜底会怎样？**

```ts
// ❌ 没有兜底
const router = createRouter({
  history: createWebHistory(window.__MICRO_APP_BASE_ROUTE__)
  // 独立运行时：createWebHistory(undefined) → 可能报错或行为异常
})
```

**设计哲学：** 子应用不应该依赖微前端环境才能运行。`'/'` 兜底体现了 **"独立可运行"** 的工程原则 — 子应用脱离主应用后依然是一个完整的、可访问的网站。

---

### Q23：在子应用中展示"当前运行环境"指示器有什么实用价值？

**答：**
在 `Home.vue` 中我们设计了环境检测展示：

```vue
<p v-if="isMicroApp">🟢 当前运行在 <strong>micro-app 微前端环境</strong> 中</p>
<p v-else>🔵 当前<strong>独立运行</strong>模式</p>
```

这个看似简单的小功能有 4 个实用价值：

| 价值 | 说明 |
|------|------|
| **调试可视化** | 一眼看出当前是通过主应用加载还是独立访问，快速定位"为什么行为不同"的问题 |
| **新人友好** | 新加入的开发者不需要理解整个架构就能知道当前运行模式 |
| **排查跨环境 Bug** | "在独立运行正常、主应用里出问题" → 有了指示器更容易复现和对比 |
| **演示/汇报** | 向 Leader 或面试官展示时，直观证明微前端架构确实在工作 |

**延伸设计：** 可以在指示器中进一步展示：

```ts
// 环境信息面板
const envInfo = computed(() => ({
  运行模式: isMicroApp ? '微前端环境' : '独立运行',
  baseroute: window.__MICRO_APP_BASE_ROUTE__ || '/',
  应用名称: window.__MICRO_APP_NAME__ || '独立运行',
  实际路径: window.location.pathname
}))
```

---

### Q24：这次 Vue3 子应用创建过程中遇到了什么实际 bug？是如何修复的？

**答：**
实际遇到了**一个构建错误**：

**Bug 表现：**
```bash
npm run build
# ❌ Build failed with 1 error:
# [MISSING_EXPORT] "App" is not exported by
# "node_modules/vue/dist/vue.runtime.esm-bundler.js"
# at src/main.ts:1:21
```

**Bug 现场代码：**
```ts
// src/main.ts — 第 1 行
import { createApp, App as VueApp } from 'vue'
//                         ^^^ 这是类型，不是值
```

**排查过程：**

| 排查步骤 | 结果 | 判断 |
|----------|------|------|
| `vue-tsc --noEmit` | ✅ 零错误 | 类型检查通过，排除了类型标注问题 |
| 检查 `node_modules/vue/dist/` | `vue.runtime.esm-bundler.js` 存在 | 排除安装问题 |
| 在 `vue` 包中搜索 `App` 导出 | 只找到 `interface App`，无运行时导出 | **确认：`App` 是类型，不是值** |
| 检查 `tsconfig.app.json` | `"erasableSyntaxOnly": true` 但未触发报错 | TS 认为用法正确（作为类型的别名） |

**根因：** Vite 8 的 Rolldown 打包器在生产构建时使用 Vue 的 `esm-bundler` 版本，该版本只导出运行时 API。`App` 是 TypeScript 接口，在 JS 运行时不存在。`import { App }` 让 Rolldown 尝试从运行时模块中找 `App`，找不到就报 `MISSING_EXPORT`。

**修复：** 将值导入和类型导入分开：
```ts
import { createApp } from 'vue'       // 值导入
import type { App as VueApp } from 'vue'  // 类型导入 — Rolldown 会删除此行
```

**修复后验证：**
```bash
npx vue-tsc --noEmit   # ✅ 类型检查通过
npx vite build          # ✅ 构建成功，产物正常
```

**教训总结：**

| 经验 | 说明 |
|------|------|
| `vue-tsc` 通过 ≠ 构建通过 | 类型检查器不模拟打包器的模块解析 |
| `import type` 不是可选的 | 在 Vite 8 项目中使用 Vue 类型，必须用 type-only import |
| `erasableSyntaxOnly` 是好配置 | 理论上能提前发现此类问题（但别名场景未覆盖） |

---

## 七、加载状态与沙箱机制

### Q25：`<micro-app>` 标签加载子应用时的 Loading 效果是如何实现的？

**答：**
利用了 micro-app 自定义元素的 **默认插槽（slot）机制** 配合框架的生命周期，是一个零配置的内置能力。

**核心代码：**

```html
<micro-app
  name="vue3-app"
  url="http://localhost:3001/"
  baseroute="/vue3-app"
  @created="onCreated"
  @mounted="onMounted"
>
  <!-- 🔑 这里的内容就是 Loading 占位 -->
  <div class="loading-placeholder">
    <div class="spinner"></div>
    <p>正在加载子应用 {{ currentApp.name }}...</p>
    <p class="loading-hint">
      请确保子应用已启动：<code>{{ currentApp.url }}</code>
    </p>
  </div>
</micro-app>
```

**工作原理（时间线）：**

```
时间 →
──────────────────────────────────────────────────────────────

① micro-app 标签插入 DOM
   │
   │  此时 slot 内容立即渲染：
   │  ┌─────────────────────────┐
   │  │  ⟳ 正在加载子应用...     │
   │  │  请确保子应用已启动      │
   │  └─────────────────────────┘
   │
   ▼
② fetch(url) — 请求子应用 HTML
   │  [Loading 持续展示]
   │
   ▼
③ @created 触发 — HTML 已下载，资源正在加载
   │  [Loading 持续展示]
   │
   ▼
④ @beforemount 触发 — 沙箱准备就绪
   │  [Loading 持续展示]
   │
   ▼
⑤ 子应用 JS 执行完毕，根组件挂载完成
   │
   │  micro-app 框架做 DOM 替换：
   │  移除 slot 内容 → 插入子应用渲染结果
   │
   ▼
⑥ @mounted 触发 — 子应用完全渲染
   ┌─────────────────────────┐
   │  子应用的实际页面内容      │
   └─────────────────────────┘
```

| 阶段 | DOM 状态 | 用户看到 |
|------|----------|----------|
| `<micro-app>` 插入 DOM | 框架初始化 | 插槽内容（Loading） |
| `fetch` 请求中 | 插槽内容 | Loading + spinner 动画 |
| `created` 触发 | 插槽内容 | Loading |
| `beforemount` 触发 | 插槽内容 | Loading |
| 子应用挂载完成 → `mounted` | **插槽被替换为子应用内容** | 子应用页面 |

**为什么不需要手动控制 Loading 的显示/隐藏？**

这是 `<micro-app>` 作为 Web Component 的**原生插槽机制**：

```
<micro-app> 的 Shadow DOM 内部逻辑：

if (子应用未就绪) {
  渲染 <slot></slot>  ← 显示用户传入的 Loading 内容
} else {
  渲染子应用的 DOM  ← 替换掉 slot
}
```

当 `mounted` 生命周期触发时，micro-app 框架自动用子应用的实际 DOM 替换插槽内容。开发者**不需要手动写 `v-if` / `v-show`** 来控制 loading 和子应用之间的切换。

**Loading 设计的最佳实践：**

| 要素 | 示例 | 作用 |
|------|------|------|
| **加载动画** | CSS spinner 旋转圈 | 视觉反馈，安抚用户等待 |
| **应用标识** | `{{ currentApp.name }}` | 多个子应用时，用户知道正在加载哪个 |
| **调试信息** | `{{ currentApp.url }}` | 开发阶段帮助排查"子应用是否已启动" |
| **错误兜底** | `@error="onError"` | 加载失败时在回调中做降级处理 |

**常见优化：**

```html
<micro-app ... @error="onError">
  <!-- 正常加载 -->
  <div class="loading-placeholder">
    <div class="spinner"></div>
    <p>正在加载子应用...</p>
  </div>
  
  <!-- 加载失败（可在 error 回调中切换状态来展示） -->
  <!-- 这里需要用 Vue 响应式变量控制，因为 slot 的可见性由 micro-app 框架管理 -->
</micro-app>
```

```ts
// error 回调中可以做重试或降级
function onError(error: Error) {
  console.error(`[ChildApp] ${currentApp.value.name} 加载失败:`, error)
  // 可在此处设置 UI 状态提示用户刷新
}
```

---

### Q26：为什么 Vite 子应用必须用 `iframe: true`，而 Webpack 子应用可以用 `iframe: false`？

**答：**
根因是两种构建工具产出的 **JS 格式** 不同，导致 micro-app 的 with 沙箱对 Vite 输出的 ES Module 无法执行。

---

#### Webpack 子应用：with 沙箱可执行

**Webpack 的代码输出：**

```html
<!-- Webpack dev/build 输出的 HTML -->
<script src="/js/chunk-vendors.js"></script>    <!-- 普通脚本 -->
<script src="/js/app.js"></script>              <!-- 普通脚本 -->
```

```js
// Webpack 打包后的 JS 格式（UMD / IIFE）：
(function(module, exports, __webpack_require__) {
  // 所有模块代码都在一个函数闭包里
  // 没有 import/export 语句！
  var Vue = __webpack_require__('vue')
  // ...
})
```

**关键特征：** Webpack 打包产物是**普通脚本（Regular Script）**，不包含 `import`/`export` 语句。

**with 沙箱的工作方式：**

```
micro-app with 沙箱执行流程：

1. 获取子应用的 JS 代码（字符串）
2. 用 with(window.proxy) 创建一个作用域链
3. 通过 new Function(code) 执行 JS

   伪代码：
   const sandboxCode = `
     with (this.proxyWindow) {
       ${子应用的JS代码}    ← 普通 JS，可以执行 ✅
     }
   `
   const fn = new Function('window', 'document', sandboxCode)
   fn(proxyWindow, proxyDocument)
```

因为 Webpack 产出的 JS 是普通的 IIFE/UMD 代码，`new Function()` 完全可以执行它。Proxy 劫持了 `window.document` 等全局变量的访问，实现了沙箱隔离。

---

#### Vite 子应用：with 沙箱不可执行（必须用 iframe）

**Vite devServer 的代码输出：**

```html
<!-- Vite devServer 返回的 HTML -->
<script type="module" src="/src/main.ts"></script>
```

```js
// Vite 不对源码打包，直接输出 ES Module：
import { createApp } from '/node_modules/.vite/deps/vue.js?v=abc123'
import App from '/src/App.vue'
import router from '/src/router/index.ts'
// ↑ 全是 import/export 语句！
```

**关键特征：** Vite devServer 输出的是 **ES Module（`<script type="module">`）**，包含大量 `import`/`export` 语句。

**with 沙箱为什么失败：**

```
micro-app with 沙箱执行流程：

1. 获取子应用的 JS 代码（字符串）
2. 用 with(window.proxy) 创建作用域
3. 通过 new Function(code) 执行 JS

   伪代码：
   const sandboxCode = `
     with (this.proxyWindow) {
       import { createApp } from '...'    ← ❌ SyntaxError!
       //     ↑
       // import 语句只能在 Module 上下文中使用
       // new Function() 创建的是 Script 上下文，不是 Module 上下文
     }
   `
   const fn = new Function('window', 'document', sandboxCode)
   fn(proxyWindow, proxyDocument)
```

**报错本质：**

```
浏览器 JS 规范中有两种脚本类型：

┌─────────────────────────────────────────────────────────┐
│  Script（普通脚本）           │  Module（ES 模块）       │
├───────────────────────────────┼─────────────────────────┤
│ <script src="...">            │ <script type="module">  │
│ 不能用 import/export          │ 可以用 import/export    │
│ 顶层 this = window            │ 顶层 this = undefined   │
│ new Function() 创建的         │ ❌ 没有 new Module()    │
│ 就是这个类型                   │   这个 API 不存在！      │
└───────────────────────────────┴─────────────────────────┘
```

**核心矛盾：** JavaScript 规范里**没有 `new Module()` 这样的 API**。`new Function()` 创建的函数永远运行在 Script 上下文，永远无法解析 `import`/`export`。这是 ECMAScript 规范层面的限制，不是 micro-app 的 bug。

---

#### iframe 沙箱为什么能解决

```
┌─────────────────────────────────────────────┐
│              主应用页面 (8080)                │
│                                              │
│  <micro-app iframe="true" url="...3001">     │
│       │                                      │
│       │  创建 iframe                          │
│       ▼                                      │
│  ┌──────────────────────────────────────┐    │
│  │        iframe (沙箱)                  │    │
│  │                                      │    │
│  │  <html>                              │    │
│  │    <script type="module" src="...">  │    │
│  │    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^  │    │
│  │    iframe 是浏览器原生文档环境         │    │
│  │    天然支持 ES Module！               │    │
│  │  </html>                             │    │
│  └──────────────────────────────────────┘    │
└─────────────────────────────────────────────┘
```

iframe 是浏览器原生的独立文档环境，拥有完整的浏览器能力——包括 `<script type="module">` 的解析和执行。Vite 的所有 ES Module 在 iframe 中可以正常工作，因为浏览器内核直接处理模块加载。

---

#### 完整对比表

| 维度 | Webpack (with 沙箱) | Vite (iframe 沙箱) |
|------|---------------------|--------------------|
| **产物格式** | UMD / IIFE 普通脚本 | ES Module |
| **`<script>` 标签** | `<script src="...">` | `<script type="module" src="...">` |
| **含 import/export？** | ❌ 不含有 | ✅ 大量 |
| **`new Function()` 能执行？** | ✅ 可以（普通 JS） | ❌ 不行（模块语法） |
| **沙箱方案** | with + Proxy 代理 window | 浏览器原生 iframe |
| **性能** | 较快（无额外渲染上下文） | 略慢（需创建 iframe） |
| **隔离性** | 中等（Proxy 可被绕过） | 强（浏览器原生隔离） |
| **Vite 兼容** | ❌ 不兼容 | ✅ 兼容 |
| **配置** | `iframe: false`（默认） | `iframe: true`（必须） |

---

#### 深入追问：Vite 生产构建后也不能用 with 沙箱吗？

**答：即使生产构建也不行。**

Vite 生产构建虽然打包了代码，但内部仍然使用 **动态 import** 和 **ES Module 语法**：

```js
// Vite 生产构建产物（简化）
const __vite__mapDeps = (i) => {
  // 大量 import() 动态导入，用于 code splitting
}
// 仍然是 Module 格式
```

而且 Vite 的子应用在生产环境下图片、字体等静态资源的路径依赖 `base` 配置和 ES Module 的 `import.meta.url`，这些在 with 沙箱的 `new Function()` 上下文中同样不可用。

**结论：只要是 Vite 项目，无论开发还是生产，一律 `iframe: true`。**

---

#### 延伸：Webpack 子应用也能用 iframe 吗？

**答：可以，但不是必须。**

Webpack 子应用用 with 沙箱就能正常工作，用 iframe 也行——只是在不需要的情况下创建额外的 iframe 略微浪费资源。选择逻辑：

```
子应用构建工具是什么？
    │
    ├── Vite → 必须 iframe: true
    │         （new Function() 无法处理 ES Module）
    │
    └── Webpack → iframe: false 即可
              （UMD/IIFE 在 new Function() 中正常执行）
              │
              └── 但如果对隔离性要求极高
                  → 也可以设 iframe: true（牺牲少量性能换更强隔离）
```

---

## 八、子应用路由改造与业务兼容

### Q27：接入 micro-app 后，子应用的路由行为发生了哪些变化？原本基于 `route.name` 的业务判断该如何改造？

**答：**
这是一个子应用迁移中最容易忽视但影响面最大的问题。结论先行：**`route.name` 和 `route.path`（子应用内部值）不变，但 `window.location` 和 `route.fullPath` 变了。所有直接操作浏览器 URL 的代码必须改为使用 Vue Router API。**

---

#### 一、路由行为变化全景图

假设子应用 `vue3-app` 有一个 `/dashboard` 路由，用户通过主应用访问 `localhost:8080/vue3-app/dashboard`：

```
┌─────────────────────────────────────────────────────────────────┐
│                        浏览器地址栏                               │
│                  localhost:8080/vue3-app/dashboard               │
└──────────────────────────────┬──────────────────────────────────┘
                               │
                               ▼
         主应用 Vue Router (createWebHistory)
              匹配 /vue3-app/:page*
                               │
                               ▼
         渲染 ChildApp.vue → 加载 <micro-app>
                               │
                               ▼
         micro-app 框架: baseroute 剥离
               去掉 /vue3-app 前缀
                               │
                               ▼
         子应用内部 Vue Router (createWebHistory)
               收到路径: /dashboard
                               │
               匹配路由: { name: 'dashboard', path: '/dashboard' }
```

**关键结论：子应用的 Vue Router 在内部看到的是一个"干净"的路径（baseroute 已剥离），所有 route 对象的 `name`、`path`、`params`、`query` 都和独立运行时完全一致。**

但是 — `window.location` 是浏览器层面的，不受 Vue Router 控制，所以它不变。

---

#### 二、各路由 API 的实际值对比

假设子应用 `/dashboard` 路由定义如下：

```ts
// 子应用 router
const routes = [
  {
    path: '/dashboard',
    name: 'dashboard',
    meta: { requiresAuth: true },
    component: () => import('@/views/Dashboard.vue')
  }
]
```

用户在浏览器访问：`http://localhost:8080/vue3-app/dashboard?id=1`

| API | 独立运行时的值 | 微前端环境中的值 | 是否变化 |
|-----|--------------|-----------------|---------|
| `route.name` | `'dashboard'` | `'dashboard'` | ✅ 不变 |
| `route.path` | `'/dashboard'` | `'/dashboard'` | ✅ 不变 |
| `route.params` | `{}` | `{}` | ✅ 不变 |
| `route.query` | `{ id: '1' }` | `{ id: '1' }` | ✅ 不变 |
| `route.meta` | `{ requiresAuth: true }` | `{ requiresAuth: true }` | ✅ 不变 |
| `route.fullPath` | `'/dashboard?id=1'` | ⚠️ **取决于 micro-app 版本** | ⚠️ 可能变化 |
| `route.matched` | `[dashboardRoute]` | `[dashboardRoute]` | ✅ 不变 |
| `window.location.pathname` | `'/dashboard'` | **`'/vue3-app/dashboard'`** | ❌ 变了！ |
| `window.location.href` | `'http://localhost:3001/dashboard?id=1'` | **`'http://localhost:8080/vue3-app/dashboard?id=1'`** | ❌ 变了！ |
| `window.location.origin` | `'http://localhost:3001'` | **`'http://localhost:8080'`** | ❌ 变了！ |

---

#### 三、典型业务场景的改造方法

##### 场景 1：基于 `route.name` 控制侧边栏/菜单高亮

这是最常见也最无需担心的场景。

```ts
// ✅ 这段代码在微前端环境中完全不需要改动
import { useRoute } from 'vue-router'

const route = useRoute()

// 判断当前是否在 dashboard 页面
const isDashboard = computed(() => route.name === 'dashboard')

// 侧边栏菜单项
const menuItems = [
  { title: '首页', routeName: 'home', icon: 'home' },
  { title: '控制台', routeName: 'dashboard', icon: 'dashboard' },
]

// 当前激活的菜单项
const activeMenu = computed(() => menuItems.find(item => item.name === route.name))
```

**原因：** `route.name` 是子应用内部路由器解析出来的，不经过浏览器 URL。baseroute 对它完全透明。

---

##### 场景 2：基于 `route.name` 做导航守卫

```ts
// ✅ 同样不需要改动
router.beforeEach((to, from) => {
  if (to.name === 'dashboard' && !isLoggedIn()) {
    return { name: 'login', query: { redirect: to.path } }
  }
})
```

**原因：** 导航守卫接收的 `to`/`from` 是子应用内部路由解析结果，`name` 和 `path` 都已被 micro-app 处理过。

---

##### 场景 3：❌ 直接读取 `window.location.pathname` 做业务判断

这是**最容易出 bug 的写法**，必须改造。

```ts
// ❌ 错误：独立运行能工作，微前端环境判断失败
function getActiveTab() {
  if (window.location.pathname === '/dashboard') {
    return 'dashboard'  // → 微前端环境：pathname 是 '/vue3-app/dashboard'，永不匹配
  }
  if (window.location.pathname.startsWith('/user')) {
    return 'user'
  }
  return 'home'
}

// ✅ 正确：使用 Vue Router 的 route 对象
import { useRoute } from 'vue-router'

function getActiveTab() {
  if (route.name === 'dashboard') {
    return 'dashboard'  // → 无论独立运行还是微前端，永远正确
  }
  if (route.path.startsWith('/user')) {
    return 'user'
  }
  return 'home'
}
```

---

##### 场景 4：❌ 使用 `window.location.href` 做页面跳转

```ts
// ❌ 错误：跳过 Vue Router，且跳出微前端命名空间
function goToDashboard() {
  window.location.href = '/dashboard'
  // 微前端环境实际跳转: localhost:8080/dashboard
  // 但主应用 /dashboard 可能是主应用的页面！子应用的 dashboard 实际路径是 /vue3-app/dashboard
}

// ✅ 正确：使用 Vue Router
import { useRouter } from 'vue-router'
const router = useRouter()

function goToDashboard() {
  router.push({ name: 'dashboard' })  // ← 最推荐：命名路由
  // 或 router.push('/dashboard')     // ← 也可以，micro-app 会自动加 baseroute 前缀
}
```

**为什么 `router.push('/dashboard')` 也能正常工作？**

```
子应用代码: router.push('/dashboard')
        │
        ▼
子应用 Vue Router: 解析路径 → /dashboard
        │
        ▼
micro-app 拦截 pushState
        │
        ▼
自动拼接 baseroute: /vue3-app + /dashboard = /vue3-app/dashboard
        │
        ▼
浏览器地址栏: localhost:8080/vue3-app/dashboard ✅
```

micro-app 通过**劫持 `history.pushState` / `replaceState`** 实现了路由的自动前缀拼接。

---

##### 场景 5：❌ 使用 `window.open()` 打开子应用内页面

```ts
// ❌ 错误
function openDetail(id: string) {
  window.open(`/detail/${id}`)
  // 微前端环境实际打开: localhost:8080/detail/123
  // 主应用无此路由 → 404
}

// ✅ 正确方案 1：使用 Vue Router
function openDetail(id: string) {
  const url = router.resolve({ name: 'detail', params: { id } }).href
  window.open(url) // micro-app 已处理路径拼接
}

// ✅ 正确方案 2：手动拼接 baseroute
function openDetail(id: string) {
  const base = window.__MICRO_APP_BASE_ROUTE__ || ''
  window.open(`${base}/detail/${id}`)
}
```

---

##### 场景 6：❌ 面包屑基于 `window.location` 解析

```ts
// ❌ 错误
function getBreadcrumbs() {
  const segments = window.location.pathname.split('/').filter(Boolean)
  // 微前端环境: segments = ['vue3-app', 'dashboard', 'overview']
  // 独立运行:   segments = ['dashboard', 'overview']
  // → 第一段不一致，面包屑不一致！
  return segments.map((seg, i) => ({
    label: seg,
    path: '/' + segments.slice(0, i + 1).join('/')
  }))
}

// ✅ 正确：基于 route.matched
import { useRoute } from 'vue-router'

function getBreadcrumbs() {
  return route.matched
    .filter(r => r.meta?.title)
    .map(r => ({
      label: r.meta.title as string,
      path: r.path
    }))
}

// 路由定义中配置 meta.title
// { path: '/dashboard', name: 'dashboard', meta: { title: '控制台' } }
```

---

##### 场景 7：❌ 接口回调 URL / OAuth 重定向使用硬编码路径

```ts
// ❌ 错误：OAuth 回调写死路径
function login() {
  const callbackUrl = 'http://localhost:3001/auth/callback'
  // 微前端环境的实际域名是 localhost:8080，端口也不对
  window.location.href = `https://oauth.example.com?redirect=${callbackUrl}`
}

// ✅ 正确：动态构建完整 URL
function login() {
  const base = window.__MICRO_APP_BASE_ROUTE__ || ''
  const callbackPath = router.resolve({ name: 'authCallback' }).href
  const callbackUrl = window.location.origin + callbackPath
  // → localhost:8080/vue3-app/auth/callback
  window.location.href = `https://oauth.example.com?redirect=${callbackUrl}`
}
```

---

#### 四、改造原则总结

```
       是否涉及 URL 字符串？
              │
     ┌────────┴────────┐
     │                 │
    否                 是
     │                 │
     ▼                 ▼
  ✅ 不需要改     这个 URL 是谁用的？
                     │
          ┌──────────┼──────────┐
          │          │          │
     Vue Router   外部系统    浏览器跳转
     （router.push （回调URL （window.open
      route.name    fetch）    location.href）
      route.path）
          │          │          │
          ▼          ▼          ▼
       ✅ 不改     ⚠️ 需要     ⚠️ 需要
       micro-app  手动拼接    使用 router
       自动处理    baseroute    API
```

**核心口诀：**

| 旧习惯 | 新习惯 | 原因 |
|--------|--------|------|
| `window.location.pathname` | `route.path` / `route.name` | route 对象已被 micro-app 处理，值正确 |
| `window.location.href = '...'` | `router.push(...)` | 走 Vue Router，micro-app 自动加前缀 |
| `window.open('/xxx')` | `window.open(router.resolve(...).href)` | 手动解析出带 baseroute 的正确路径 |
| 手动 `split('/')` 解析路径 | `route.matched` + `meta` | 用路由元信息替代字符串解析 |
| 硬编码完整 URL | `window.location.origin + baseroute + path` | 动态拼接，适配任何环境 |

---

#### 五、一个完整的改造前后对比

```ts
// ============================================
// 改造前 — 充满隐患的旧代码
// ============================================
export function useNavigation() {
  // ❌ 基于 window.location 判断
  const currentPage = window.location.pathname.split('/').pop()
  
  function navigateTo(page: string) {
    // ❌ 硬编码路径
    window.location.href = `/${page}`
  }
  
  function isActive(pageName: string): boolean {
    // ❌ 字符串匹配
    return window.location.pathname.includes(pageName)
  }
  
  // ❌ 直接拼接 URL 给外部
  function getShareUrl(): string {
    return `http://localhost:3001${window.location.pathname}`
  }
  
  return { currentPage, navigateTo, isActive, getShareUrl }
}

// ============================================
// 改造后 — 微前端安全的代码
// ============================================
import { useRouter, useRoute } from 'vue-router'

export function useNavigation() {
  const router = useRouter()
  const route = useRoute()
  
  // ✅ 基于 route.name，与环境无关
  const currentPage = computed(() => route.name as string)
  
  function navigateTo(name: string) {
    // ✅ 命名路由跳转，micro-app 自动处理 URL
    router.push({ name })
  }
  
  function isActive(name: string): boolean {
    // ✅ 精确匹配 route.name
    return route.name === name
  }
  
  function getShareUrl(): string {
    // ✅ 动态拼接完整路径
    const base = (window as any).__MICRO_APP_BASE_ROUTE__ || ''
    const fullPath = base + route.fullPath
    return window.location.origin + fullPath
  }
  
  return { currentPage, navigateTo, isActive, getShareUrl }
}
```

---

## 九、CORS 跨域排错实战

### Q28：子应用加载时报 CORS 错误 `No 'Access-Control-Allow-Origin' header is present`，如何排查和修复？

**答：**
这是搭建样式冲突 Demo 时实际遇到的一个排错案例，完整的排查链路非常有教学价值。

---

#### 一、错误现场

**控制台报错：**

```
Access to fetch at 'http://localhost:5173/' from origin 'http://localhost:8080'
has been blocked by CORS policy:
No 'Access-Control-Allow-Origin' header is present on the requested resource.
```

**micro-app 错误回调：**

```
[micro-app] 子应用 vue2-app 加载错误:
CustomEvent { isTrusted: false, detail: {...}, type: 'error', ... }
```

**用户看到的现象：** 子应用页面白屏（或一直显示 Loading），无法加载。

---

#### 二、排查步骤

```
第 1 步：确认子应用服务器是否在运行
─────────────────────────────────
curl -s -o /dev/null -w "%{http_code}" http://localhost:5173/
→ 200  ✅ 服务器在运行，HTML 能正常返回

第 2 步：检查响应头中是否有 CORS 头
─────────────────────────────────
curl -s -I http://localhost:5173/ | grep -i access-control
→ (空)  ❌ 没有 Access-Control-Allow-Origin 头！

第 3 步：确认请求的 Origin 和服务器的 Origin 是否不同
─────────────────────────────────
主应用:    http://localhost:8080
子应用:    http://localhost:5173
→ 不同端口 = 不同源 → 浏览器强制 CORS 检查

第 4 步：定位服务器为什么不发 CORS 头
─────────────────────────────────
当前使用:  npx serve -p 5173
→ npx serve 默认不添加 CORS 头 ❌
```

---

#### 三、根因分析

```
┌─────────────────────────────────────────────────────────────┐
│                    浏览器同源策略                              │
│                                                             │
│  http://localhost:8080 (主应用)                              │
│         │                                                   │
│         │  fetch('http://localhost:5173/')                  │
│         │  协议相同 (http)                                   │
│         │  域名相同 (localhost)                               │
│         │  端口不同 (8080 ≠ 5173)  ← 跨域！                  │
│         │                                                   │
│         ▼                                                   │
│  http://localhost:5173 (子应用服务器)                         │
│         │                                                   │
│         │  响应头中没有 Access-Control-Allow-Origin           │
│         │                                                   │
│         ▼                                                   │
│  ❌ 浏览器拦截响应 → 子应用加载失败                            │
└─────────────────────────────────────────────────────────────┘
```

**本质：** `npx serve` 是一个简化版静态文件服务器，设计目标是本地预览，不包含 CORS 配置。在微前端场景下，主应用需要通过 `fetch()` 跨域请求子应用的 HTML，所以子应用服务器**必须**返回 CORS 头。

**注意：** 即使子应用服务器正常运行、curl 能拿到 HTML，浏览器也会拦截跨域请求的响应。这是浏览器安全策略，不是网络问题。

---

#### 四、解决方案

**方案一：写一个带 CORS 的 Node.js 服务器（Demo 采用）**

```js
// server.js — 最简单的带 CORS 的静态文件服务器
const http = require('http')
const fs = require('fs')
const path = require('path')

const PORT = 5173

http.createServer((req, res) => {
  // 每个响应都加上 CORS 头
  res.setHeader('Access-Control-Allow-Origin', '*')
  res.setHeader('Access-Control-Allow-Methods', 'GET, POST, OPTIONS')
  res.setHeader('Access-Control-Allow-Headers', '*')

  // 处理预检请求
  if (req.method === 'OPTIONS') {
    res.writeHead(204)
    res.end()
    return
  }

  // 返回静态文件
  let filePath = req.url === '/' ? '/index.html' : req.url.split('?')[0]
  const fullPath = path.join(__dirname, filePath)
  
  fs.readFile(fullPath, (err, data) => {
    if (err) {
      res.writeHead(404)
      res.end('Not Found')
    } else {
      res.writeHead(200, { 'Content-Type': 'text/html; charset=utf-8' })
      res.end(data)
    }
  })
}).listen(PORT, () => {
  console.log(`Mock sub-app with CORS: http://localhost:${PORT}/`)
})
```

```bash
node server.js
# → Mock sub-app with CORS: http://localhost:5173/
```

**验证修复：**
```bash
curl -s -I http://localhost:5173/ | grep -i access-control
# → Access-Control-Allow-Origin: *           ✅
# → Access-Control-Allow-Methods: GET, POST  ✅
```

**方案二：Vite 项目自带 CORS（推荐用于真实子应用）**

```ts
// vite.config.ts
export default defineConfig({
  server: {
    port: 3001,
    headers: {
      'Access-Control-Allow-Origin': '*'
    }
  }
})
```
Vite 的 dev server 本身支持自定义 headers，不需要额外写服务器代码。

**方案三：Webpack 项目配置 devServer**

```js
// vue.config.js 或 webpack.config.js
module.exports = {
  devServer: {
    port: 3000,
    headers: {
      'Access-Control-Allow-Origin': '*'
    }
  }
}
```

**方案四：nginx 反向代理（生产环境）**

```nginx
location /child-app/ {
    proxy_pass http://localhost:5173/;
    add_header Access-Control-Allow-Origin *;
}
```

---

#### 五、排查 CORS 问题的通用检查清单

| 检查项 | 命令/方法 | 通过标准 |
|--------|-----------|----------|
| 子应用服务器在运行 | `curl -s -o /dev/null -w "%{http_code}" http://localhost:PORT/` | 返回 200 |
| 有 CORS 头 | `curl -s -I http://localhost:PORT/ \| grep -i access-control` | 看到 `Access-Control-Allow-Origin` |
| 主应用和子应用同源？ | 比较 `protocol + host + port` | 如果同源则不需要 CORS |
| 浏览器 Network 面板 | F12 → Network → 找到子应用请求 → Response Headers | 有 CORS 相关头 |
| 控制台无 CORS 报错 | F12 → Console | 无 `blocked by CORS policy` |

---

#### 六、常见 CORS 相关误区

| 误区 | 纠正 |
|------|------|
| "curl 能返回 HTML，说明服务器没问题" | curl 不执行同源策略，浏览器会执行。curl 成功 ≠ 浏览器能加载 |
| "两个 localhost 不同端口也跨域？" | 对，同源 = 协议+域名+端口**完全相同**。不同端口就是跨域 |
| "加了 CORS 头就不安全了" | `Access-Control-Allow-Origin: *` 确实允许任何来源，生产环境建议限定具体域名 |
| "生产环境部署在同域就不需要 CORS" | 正确。如果子应用部署在主应用的子路径（如 `/vue3-app/`），由 nginx 统一转发，浏览器看到的是同源请求，不需要 CORS |

---

## 十、样式冲突深度剖析

### Q29：mock-app 的 h2 样式（橙色系）在页面上实际渲染出来了吗？有样式冲突吗？为什么？

**答：**
这是一个考察 CSS 级联（Cascade）机制的经典问题。答案分两层：**冲突确实存在，但不是"谁覆盖谁"，而是产生了双方都不想要的"混合样式"。**

---

#### 一、两套样式规则对比

```css
/* 主应用的 h2（紫色系）*/
h2 {
  font-family: 'Microsoft YaHei', sans-serif !important;
  font-size: 20px !important;
  color: #667eea !important;
  border-bottom: 2px solid #667eea !important;   /* ← 底边框 */
  padding-bottom: 8px !important;                /* ← 下内边距 */
  margin: 12px 0 !important;
  text-transform: none !important;
  border-left: none !important;                  /* ← 明确取消左边框 */
}

/* mock-app 的 h2（橙色系）*/
h2 {
  font-family: 'Georgia', serif !important;
  font-size: 32px !important;
  color: #ff6b35 !important;
  border-left: 6px solid #ff6b35 !important;     /* ← 左边框 */
  padding-left: 14px !important;                 /* ← 左内边距 */
  margin: 18px 0 !important;
  text-transform: uppercase !important;
}
```

---

#### 二、为什么会产生冲突：两个条件同时满足

`subApps.ts` 中 mock-app 的配置：

```ts
{
  name: 'mock-app',
  iframe: false,           // ① DOM 直接嵌入主文档，无隔离
  disableScopecss: true,   // ② 关闭样式前缀，h2 就是全局 h2
}
```

| 条件 | 作用 | 如果没有会怎样 |
|------|------|---------------|
| `iframe: false` | 子应用 HTML 被直接注入主文档的 DOM 树 | `iframe: true` → 独立文档，双方样式物理隔离 |
| `disableScopecss: true` | micro-app 不为子应用 CSS 加 `micro-app[name=mock-app]` 前缀 | 子应用的 `h2` 变成 `micro-app[name=mock-app] h2`，只作用于子应用内部 |

**两者叠加 → 子应用的 `h2 { ... }` 就是整个文档的 `h2 { ... }`。**

---

#### 三、CSS 属性级别的逐条分析

关键认知：**CSS 的覆盖单位是"属性"，不是"规则"。** 浏览器不会整体选择"用主应用的 h2"还是"用子应用的 h2"，而是逐属性比较。

由于两套规则都使用了 `!important` 且选择器都是 `h2`（特异性相同），**后加载的样式表在冲突属性上胜出**。mock-app 的样式是在主应用样式之后由 micro-app 注入的，所以 mock-app 的属性在冲突时优先。

下面是 h2 元素实际渲染结果的逐属性分析：

```
h2 最终渲染结果：
┌──────────────────────────────────────────────────────┐
│                                                      │
│  ┃ ← 橙色左边框 (border-left: 6px solid #ff6b35)     │
│  ┃   来源: mock-app（胜出，覆盖了主应用的 none）        │
│  ┃                                                    │
│  ┃  GEORGIA 32px 橙色大写文字                          │
│  ┃  来源: mock-app（font-family/size/color/text-transform 均胜出）│
│  ┃                                                    │
│  ━━━━━ ← 紫色底部边框 (border-bottom: 2px solid #667eea) │
│          来源: 主应用（mock-app 没设这个属性，所以保留） │
│                                                      │
└──────────────────────────────────────────────────────┘
```

| CSS 属性 | 主应用设置的值 | mock-app 设置的值 | 最终渲染 | 胜出方 |
|----------|--------------|------------------|---------|--------|
| `font-family` | `'Microsoft YaHei', sans-serif` | `'Georgia', serif` | **Georgia** | mock（后加载） |
| `font-size` | `20px` | `32px` | **32px** | mock |
| `color` | `#667eea` (紫色) | `#ff6b35` (橙色) | **橙色** | mock |
| `text-transform` | `none` | `uppercase` | **uppercase** | mock |
| `margin` | `12px 0` | `18px 0` | **18px 0** | mock |
| `border-left` | `none` | `6px solid #ff6b35` | **6px 橙色** | mock |
| `padding-left` | (未设置) | `14px` | **14px** | mock |
| **`border-bottom`** | `2px solid #667eea` | **(未设置)** | **2px 紫色** | ⚠️ 主应用！ |
| **`padding-bottom`** | `8px` | **(未设置)** | **8px** | ⚠️ 主应用！ |

---

#### 四、关键洞察：这不是覆盖，是缝合

**这就是样式冲突的本质 — 它不是 A 替代 B，而是 A 和 B 搅拌在一起：**

- mock-app 的设计师期望 h2 是一个纯橙色的标题，没有底边框
- 主应用的设计师期望 h2 是一个纯紫色的标题，没有左边框
- 实际渲染：**既有橙色左边框，又有紫色底边框** — 双方都不想要这个效果

```
预期的 mock-app h2:              预期的 main-app h2:
┃ GEORGIA 橙色 大写               Microsoft YaHei 紫色
┃                                 ━━━━━━━━━━━━━━
┃                                 

实际渲染（冲突产物）:
┃ GEORGIA 橙色 大写
┃ ← 橙色左边框 (mock-app 的)
━━━ ← 紫色底边框 (主应用的)
   ← 双方都不想要的"缝合怪"
```

---

#### 五、为什么 `border-left` mock 胜出而 `border-bottom` 主应用胜出？

这是 CSS Cascade 中最容易误解的点：

```
border-left:
  - 主应用明确设置了 border-left: none
  - mock-app 明确设置了 border-left: 6px solid #ff6b35
  - 两者都声明了同一个属性 → 后加载的 mock-app 胜出 ✅

border-bottom:
  - 主应用设置了 border-bottom: 2px solid #667eea
  - mock-app 没有设置 border-bottom ← 关键！
  - 只有一方声明 → 不存在冲突 → 主应用的设置保留 ✅
```

**CSS 级联规则：** 后加载的规则只会覆盖它**声明了的属性**，不会影响前一个规则中它未涉及的属性。mock-app 没有声明 `border-bottom`，所以主应用的 `border-bottom` 永远不会被 mock-app 覆盖。

---

#### 六、如果 `disableScopecss: false`（默认），会怎样？

当样式隔离开启时，micro-app 会自动给子应用的 CSS 规则添加作用域前缀：

```css
/* 子应用写的 */
h2 { color: #ff6b35; }

/* micro-app 处理后注入（概念示意）*/
micro-app[name=mock-app] h2 { color: #ff6b35; }
```

此时：
- 主应用的 `h2 { color: #667eea }` 作用于整个文档
- 子应用的 `micro-app[name=mock-app] h2 { color: #ff6b35 }` 只作用于 `<micro-app name="mock-app">` 内部
- 两个规则的选择器不同，各管各的区域，**零冲突**

```
主应用 h2 → color: purple         子应用内部的 h2 → color: orange
(选择性作用在全局 h2)              (选择性作用在 micro-app[name=mock-app] 内的 h2)
```

---

#### 七、实际验证方法

在浏览器中打开 `http://localhost:8081/mock-app`，按 F12 打开开发者工具：

```bash
# 1. 检查 h2 元素的实际样式
# F12 → Elements → 选中 mock-app 内的 h2 → Styles 面板

# 你会看到：
# h2 {
#   font-family: 'Georgia', serif !important;   ← (来自 mock-app)
#   font-size: 32px !important;                 ← (来自 mock-app)
#   color: #ff6b35 !important;                  ← (来自 mock-app)
#   border-left: 6px solid #ff6b35 !important;  ← (来自 mock-app)
#   border-bottom: 2px solid #667eea !important; ← (来自主应用！被 mock-app 覆盖失败)
#   ...                                         ← 有些属性来自主应用，有些来自 mock-app
# }

# 2. 被划掉（strikethrough）的属性说明它被覆盖了
# 3. 注意 border-bottom 没有被划掉 — 因为 mock-app 根本没声明它
```

你会清楚地看到：**同一个 `h2` 的 Computed Style 里，既有主应用的紫色底边框，又有子应用的橙色左边框。**

---

#### 八、总结

| 问题 | 答案 |
|------|------|
| mock-app 的 h2 样式符合预期吗？ | **不符合。** mock-app 期望纯橙色无底边框，实际多了紫色底边框 |
| 有样式冲突吗？ | **有。** 颜色/字体/大小 mock 胜出（预期内），但底边框主应用残留（预期外） |
| 为什么有冲突？ | `iframe: false` + `disableScopecss: true` → 两套 h2 规则作用于同一文档，属性级搅拌 |
| 为什么底边框没被覆盖？ | mock-app 没声明 `border-bottom`，CSS 级联只覆盖声明的属性，不覆盖未涉及的 |

**核心教训：** CSS 冲突不是"整个规则"的替换，而是"逐属性"的混搭。在 `disableScopecss: true` 时，任何一个子应用未声明而主应用声明了的属性，都会在主应用的默认值上"残留"，产生双方都不想要的缝合效果。

---

### Q30：子应用之间的样式会互相影响吗？keepAlive 在其中扮演了什么角色？

**答：**
会。而且 **keepAlive 会让子应用间的样式冲突更隐蔽、更严重**。我们通过创建两个 mock 子应用进行了实际实验验证。

---

#### 一、实验设计

| 子应用 | 颜色主题 | 关键样式特征 | 端口 | 配置 |
|--------|----------|-------------|------|------|
| `mock-app` | 🟠 橙色 | h2 左边框 `border-left: 6px solid #ff6b35` | 5174 | `iframe: false, disableScopecss: true, keepAlive: true` |
| `mock-app-2` | 🔵 青色 | h2 右边框 `border-right: 5px solid #00838f` | 5175 | 同上 |

两个子应用都用了 `iframe: false` + `disableScopecss: true` + `keepAlive: true`。

---

#### 二、实验步骤与结果

```
步骤 1: 访问 http://localhost:8081/mock-app（橙色）
        → mock-app 的 CSS 被注入主文档
        → 文档中现有: main h2 + mock-app h2

步骤 2: 点击导航回到首页
        → mock-app DOM 隐藏（keepAlive）
        → ⚠️ 但 mock-app 的 <style> 标签仍在主文档 <head> 中！

步骤 3: 访问 http://localhost:8081/mock-app-2（青色）
        → mock-app-2 的 CSS 也被注入主文档
        → 文档中现有: main h2 + mock-app h2 + mock-app-2 h2
        → 三个 h2 规则同时存在！
```

**mock-app-2 的 h2 实际渲染结果（预期 vs 实际）：**

```
预期（mock-app-2 设计师想要）：
        青色文字右对齐 → 右边青色边框
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━→

实际（被 mock-app 污染后）：
┃ ← 橙色左边框（mock-app 残留！mock-app-2 根本没写 border-left）
┃  青色文字右对齐 → 右边青色边框（mock-app-2 本意）
┃ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━→
┃ ← 同时存在橙色左 + 青色右，双方都不想要！
```

---

#### 三、keepAlive 是"帮凶"

```
无 keepAlive 时:
  访问 mock-app → CSS 注入
  切换到首页 → mock-app 被销毁，CSS 被移除 ✅
  访问 mock-app-2 → 只有 mock-app-2 的 CSS ✅
  → 无残留问题

有 keepAlive 时:
  访问 mock-app → CSS 注入
  切换到首页 → mock-app DOM 隐藏，CSS 保留在 <head> ❌
  访问 mock-app-2 → mock-app 的 CSS + mock-app-2 的 CSS 共存 ❌
  → 前一个子应用的样式污染了后一个子应用！
```

**为什么会这样？**

micro-app 的 keepAlive 机制只负责隐藏/恢复子应用的 DOM，**不会去 `<head>` 中移除 `<style>` 标签**。这本身是性能优化（下次恢复时不需要重新注入 CSS），但在 `disableScopecss: true` 的场景下，这些残留的全局样式就成了污染源。

---

#### 四、冲突范围矩阵（完整版）

| 配置 | 主应用↔子应用 | 子应用↔子应用 | 原理 |
|------|:---:|:---:|------|
| `iframe: true` | ❌ 无 | ❌ 无 | iframe 独立文档，物理隔离 |
| `iframe: false` + `disableScopecss: false`（默认） | ❌ 无 | ❌ 无 | micro-app 自动给子应用 CSS 加 `[name=xxx]` 作用域前缀 |
| **`iframe: false` + `disableScopecss: true`** | **✅ 有** | **✅ 有** | 双方 `h2` 都是全局选择器，同一文档内逐属性混搭 |
| `iframe: false` + `disableScopecss: true` + **`keepAlive: true`** | **✅ 有** | **✅ 更严重** | 前一个子应用的 CSS 残留不清理，与后一个的 CSS 叠加 |

---



┌──────────────────────────────────────────────────────────────┬────────────────┬─────────────────────────────────────────────────────────┐
│                             场景                             │ 子应用间冲突？ │                          原因                           │
├──────────────────────────────────────────────────────────────┼────────────────┼─────────────────────────────────────────────────────────┤
│ 两方都 iframe: true                                          │     ❌  无      │ iframe 独立文档，物理隔离                               │
├──────────────────────────────────────────────────────────────┼────────────────┼─────────────────────────────────────────────────────────┤
│ 一方 iframe: true，一方 iframe: false                        │     ❌  无      │ iframe 内的样式出不来，传不进去                         │
├──────────────────────────────────────────────────────────────┼────────────────┼─────────────────────────────────────────────────────────┤
│ 两方都 iframe: false, disableScopecss: false                 │     ❌  无      │ micro-app 自动添加 micro-app[name=xxx] 前缀             │
├──────────────────────────────────────────────────────────────┼────────────────┼─────────────────────────────────────────────────────────┤
│ 两方都 iframe: false, disableScopecss: true                  │    ✅  有！     │ 所有 h2/button/p 等全局选择器作用在同一文档，逐属性混搭 │
├──────────────────────────────────────────────────────────────┼────────────────┼─────────────────────────────────────────────────────────┤
│ 两方都 iframe: false, disableScopecss: true, keepAlive: true │  ✅  更严重！   │ 前一个子应用的 CSS 残留 + 后一个子应用的 CSS 同时存在   │
└──────────────────────────────────────────────────────────────┴────────────────┴─────────────────────────────────────────────────────────┘

你可以现在就在浏览器里验证 — 先访问 mock-app，再切换到 mock-app-2，观察 h2 是否同时出现了橙色左边框和青色右边框。这就是子应用间样式污染的真实表现。


#### 五、在浏览器中亲自验证的方法

```
1. 打开 http://localhost:8081/mock-app
   F12 → Elements → <head> 观察 <style> 标签（橙色主题）
   
2. 导航到首页 /home
   F12 → <head> 中橙色 <style> 标签仍然存在！（keepAlive 未清理）
   
3. 打开 http://localhost:8081/mock-app-2
   F12 → <head> 中同时存在：
     - 主应用的紫色 <style>
     - mock-app 的橙色 <style>  ← 残留！
     - mock-app-2 的青色 <style>
   
4. 选中 h2 元素 → Styles 面板
   你会看到 border-left: orange 被划掉（或被覆盖）
   同时 border-right: teal 正常生效
   → Computed 面板中两个边框同时存在
```

---

#### 六、如何杜绝子应用间样式冲突

| 方案 | 做法 | 代价 |
|------|------|------|
| **用 `iframe: true`**（最推荐） | 每个子应用独立 iframe，物理隔离 | 性能略降，Vite 项目本来就必须用 |
| **用 `disableScopecss: false`**（默认） | 让 micro-app 自动加作用域前缀 | 几乎无代价，是最佳默认值 |
| **关掉 keepAlive** | 切换时销毁子应用，CSS 一并移除 | 切换回来需重新加载 |
| **子应用用 BEM/Scoped CSS** | 不强依赖全局选择器 | 工程量大，需改造存量代码 |

**推荐组合：**
```
Vite 子应用 → iframe: true                    （物理隔离 + ES Module 兼容）
Webpack 子应用 → iframe: false + 默认 scoped   （性能好 + 样式安全）
纯 HTML mock → iframe: false + 默认 scoped     （除非刻意演示冲突）
```

---

#### 七、总结

| 问题 | 答案 |
|------|------|
| 子应用之间会互相影响吗？ | **会**，当 `iframe: false` + `disableScopecss: true` 时 |
| keepAlive 有什么影响？ | **加重**冲突 — 隐藏子应用时不清理 `<style>`，CSS 残留累积 |
| 如何验证？ | F12 → Elements → `<head>` 看 `<style>` 标签数量 — 访问过的子应用越多，残留的 `<style>` 越多 |
| 如何避免？ | 默认配置（`disableScopecss: false`）就是安全的；Vite 子应用 `iframe: true` 物理隔离更安全 |

**一句话：主应用 ↔ 子应用之间有冲突，子应用 ↔ 子应用之间同样有，而且 keepAlive 让后者更隐蔽。三者在同一文档中共同搅拌所有同名的全局 CSS 属性。**

---

### Q31：已经发现了样式冲突问题，如何修复？有哪些方案？

**答：**
修复方案从简单到体系化分为四层。最简单的方案（也是我们实际采用的）只需**删掉一行配置**。

---

#### 一、方案一：恢复样式隔离（最简单，一行改动）

**根因回顾：**

```ts
// ❌ 冲突的配置
{
  name: 'mock-app',
  iframe: false,
  disableScopecss: true,   // ← 这行是罪魁祸首
  keepAlive: true,
}
```

**修复：删除 `disableScopecss: true`（恢复默认值 `false`）**

```ts
// ✅ 修复后的配置
{
  name: 'mock-app',
  iframe: false,
  // disableScopecss 不设置，默认为 false
  // → micro-app 自动为子应用 CSS 添加作用域前缀
  keepAlive: true,
}
```

**一行改动，问题解决。**

---

#### 二、修复原理：micro-app 的 CSS 作用域机制

当 `disableScopecss: false`（默认）时，micro-app 在注入子应用的 CSS 时，自动给每个选择器加上属性选择器前缀：

```
子应用原始 CSS:
─────────────────────────────────────────────
  h2 { color: #ff6b35; border-left: 6px solid orange; }
  button { background: #ff6b35; }
  p { font-size: 13px; }

        ↓ micro-app 自动转换 ↓

注入主文档后的 CSS:
─────────────────────────────────────────────
  micro-app[name=mock-app] h2 {
    color: #ff6b35;
    border-left: 6px solid orange;
  }
  micro-app[name=mock-app] button {
    background: #ff6b35;
  }
  micro-app[name=mock-app] p {
    font-size: 13px;
  }
```

**效果：**

| 选择器 | 作用范围 | 
|--------|----------|
| 主应用的 `h2 { color: purple }` | 整个文档 |
| 子应用转换后的 `micro-app[name=mock-app] h2 { color: orange }` | 只作用于 `<micro-app name="mock-app">` 内部的 h2 |

**两个选择器不再冲突** — 它们选择的是不同 DOM 范围内的元素。特异性不同，作用范围不同，互不干扰。

---

#### 三、修复前后对比

```
修复前 (disableScopecss: true):
───────────────────────────────────────────────
文档中的 CSS:
  h2 { color: purple; border-bottom: 2px solid purple; }    ← 主应用
  h2 { color: orange; border-left: 6px solid orange; }      ← mock-app
  h2 { color: teal; border-right: 5px solid teal; }         ← mock-app-2

结果: 三个 h2 规则搅拌在一起，逐属性混搭
      → 紫色底边框 + 橙色左边框 + 青色右边框 同时出现 ❌

修复后 (disableScopecss: false):
───────────────────────────────────────────────
文档中的 CSS:
  h2 { color: purple; ... }                                    ← 主应用（全局）
  micro-app[name=mock-app] h2 { color: orange; ... }           ← 仅 mock-app 内
  micro-app[name=mock-app-2] h2 { color: teal; ... }           ← 仅 mock-app-2 内

结果: 主应用的 h2 是紫色
      mock-app 内的 h2 是橙色 ✅
      mock-app-2 内的 h2 是青色 ✅
      → 各管各的区域，零冲突 ✅
```

---

#### 四、修复验证方法

```
1. 修复前先看一次：
   访问 /mock-app → F12 → Elements → <style> 标签
   → 看到 h2 { ... } 没有前缀 ← 这是冲突的根源

2. 修复后再看一次：
   刷新页面 → F12 → Elements → <style> 标签
   → 看到 micro-app[name=mock-app] h2 { ... } ← 自动加了前缀！
   → 主应用的紫色底边框不再出现在子应用的 h2 上 ✅
```

---

#### 五、多层防御体系（从简单到彻底）

| 层级 | 方案 | 适用场景 | 效果 |
|------|------|----------|------|
| **L1: 框架层** | `disableScopecss: false`（默认） | 所有 `iframe: false` 的子应用 | micro-app 自动加前缀，零成本 |
| **L2: 构建层** | `iframe: true` | Vite 子应用（必须）或高隔离需求 | 浏览器原生 iframe 隔离，最强 |
| **L3: 组件层** | Vue SFC `<style scoped>` | 子应用内部组件 | 组件级隔离，防止子应用内部样式冲突 |
| **L4: 规范层** | CSS Modules / BEM 命名 | 全局样式、公共组件 | 命名空间隔离，防止类名冲突 |

**推荐策略：**

```
Vite 子应用:
  L2 (iframe: true) → 物理隔离，必选 ✅
  L3 (Vue scoped)   → 组件级隔离，推荐 ✅

Webpack / 普通 HTML 子应用:
  L1 (disableScopecss: false) → 框架自动隔离，必选 ✅
  L3 (Vue scoped / BEM)       → 额外防护，推荐 ✅
```

---

#### 六、`disableScopecss: true` 的正确使用场景

这个选项不是为了"省事"，它的合法用途很窄：

| 场景 | 说明 |
|------|------|
| **调试排错** | 临时关闭隔离，确认是否是样式隔离导致的渲染问题 |
| **第三方 UI 库** | 子应用使用了不兼容 CSS 作用域的 UI 库（罕见） |
| **刻意演示** | 比如我们的 mock-app，故意制造冲突来教学 |

**生产环境应该永远保持 `disableScopecss: false`（默认值）。**

---

#### 七、如果主应用的全局样式也过于宽泛怎么办？

前面的修复解决了"子应用样式泄漏到主应用/其他子应用"。反向的问题——**主应用的全局样式污染子应用**——同样需要处理。

**问题回顾（Q29）：** 主应用的 `h2 { border-bottom: 2px solid purple !important }` 泄漏进了子应用。

**修复方案：**

```css
/* ❌ 主应用当前写法 — 全局 h2 会影响所有 iframe: false 的子应用 */
h2 {
  color: #667eea;
  border-bottom: 2px solid #667eea;
}

/* ✅ 修复方案 1：给主应用的内容区加作用域 */
.app-main h2 {
  color: #667eea;
  border-bottom: 2px solid #667eea;
}

/* ✅ 修复方案 2：重置子应用容器内的样式 */
micro-app h2 {
  border-bottom: none;  /* 清除主应用的底边框 */
}

/* ✅ 修复方案 3：主应用使用更具体的选择器 */
#main-app h2 { ... }     /* ID 选择器，特异性更高 */
.main-content h2 { ... } /* 类选择器 + 标签，限定范围 */
```

**推荐：** 主应用的全局样式始终挂在容器选择器下（如 `.app-main h2`、`#main-app h2`），避免使用裸标签选择器（`h2`、`button`、`p`）。

---

#### 八、决策树：拿到冲突问题怎么修？

```
发现样式冲突
    │
    ├── 子应用是 Vite 项目？
    │   └── 是 → 设置 iframe: true（物理隔离 + ES Module 兼容）
    │
    ├── 子应用是 Webpack / 普通 HTML？
    │   └── 检查 disableScopecss 配置
    │       ├── 是 true → 删掉它！（恢复默认隔离）← 90% 的情况
    │       └── 是 false → 检查是否是主应用的全局样式泄漏
    │           └── 主应用样式加 .app-main 等容器前缀
    │
    └── keepAlive 导致残留？
        └── 修复了样式隔离后，keepAlive 不再是问题
            （因为每个子应用的 CSS 有独立的作用域前缀）
```

---

#### 九、总结

| 问题 | 答案 |
|------|------|
| 修复成本高吗？ | **极低。** 删掉一行 `disableScopecss: true` 即可 |
| 默认值就是安全的吗？ | **是的。** `disableScopecss` 默认为 `false`，micro-app 自动隔离 |
| `disableScopecss: true` 什么时候用？ | 调试排错时临时开启，或刻意演示冲突时 |
| 主应用的全局样式泄漏怎么办？ | 全局样式加 `.app-main` 等容器前缀，不用裸标签选择器 |
| 为什么 Vite 项目不需要担心？ | `iframe: true` 提供物理隔离，比 CSS 作用域更强 |

**一句话修复指南：不要设置 `disableScopecss: true`，Vite 项目必须 `iframe: true`，主应用全局样式挂容器选择器。三层到位，样式冲突清零。**

---

## 附录：接入新子应用检查清单

| 步骤 | 文件 | 操作 |
|------|------|------|
| 1 | `src/config/subApps.ts` | 在 `subApps` 数组中添加新条目 |
| 2 | `src/router/index.ts` | 添加 `path: '/xxx/:page*'` 通配路由 |
| 3 | `src/App.vue` | 导航栏添加 `<router-link to="/xxx">` |
| 4 | 子应用 vite.config.ts | 设置 `base: '/xxx/'` 或使用 `__MICRO_APP_BASE_ROUTE__` |
| 5 | 子应用 router | `createWebHistory(window.__MICRO_APP_BASE_ROUTE__ \|\| '/')` |
| 6 | 子应用 devServer | 配置 CORS 头 `Access-Control-Allow-Origin: *` |
| 7 | 验证 | 启动子应用 → 启动主应用 → 访问对应路由确认加载成功 |