cirry/microapp-main-interview

Fork 0

Files

cirry fb04230958 样式冲突问题解决

2026-06-21 20:19:21 +08:00

88 KiB

Raw Blame History

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

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

一、多子应用注册与路由

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

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

1. src/config/subApps.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 — 添加通配路由

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

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

<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`	用户需要入口点击进入子应用

能否合并？

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

// 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` 组件是如何做到"一个组件服务所有子应用"的？

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

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

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

工作流程：

用户访问 /vue3-app/dashboard
Vue Router 匹配到通配路由 → 渲染 ChildApp.vue
ChildApp.vue 内的 computed 检查 route.path 以哪个 baseroute 开头
找到 vue3-app 配置 → 绑定到 <micro-app> 标签
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 拦截，可能跳出微前端上下文	⭐ 低

最佳实践：

// 子应用 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           → 控制台

三层隔离保证：

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

三、SubAppConfig 接口设计

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

答：

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，核心原因：

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 个后，路由和导航如何自动管理？

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

路由自动生成：

// 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')
  }))
]

导航自动生成：

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

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

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

答：会出现不确定行为：

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

防御措施：

// 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 不同，如何管理？

答：使用环境变量：

// 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'
  }
]

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

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

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

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

答：三个关键点：

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

故障隔离效果：

场景	影响范围
子应用 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 子应用配置文件如下，每个配置项都有明确的原因：

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 重复不会直接冲突。但有两个隐患：

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

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

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

// 子应用 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 生命周期是如何设计的？

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

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 等），不导出类型。

// ❌ 错误写法：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：

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 个关键全局变量，必须显式声明类型：

/// <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 子应用的可用性？

答：三层验证策略：

第一层：类型检查

npx vue-tsc --noEmit

验证所有类型标注正确
检查 micro-app 全局变量的类型使用
确保 import type 用在正确的位置

第二层：独立构建

npm run build

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

第三层：联调验证

# 终端 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 检查：

{
  "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 值的设计覆盖了 两个关键场景：

场景一：独立开发调试

npm run dev
# 子应用独立运行在 localhost:3001
# window.__MICRO_APP_BASE_ROUTE__ === undefined
# router base → '/'  ← 走兜底
# 访问 /、/about 正常工作

场景二：单元测试 / E2E 测试

// 测试文件中直接创建 router
const router = createRouter({
  history: createWebHistory('/'),
  routes
})
// 不需要 mock __MICRO_APP_BASE_ROUTE__

如果不写兜底会怎样？

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

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

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

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

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

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

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

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

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

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

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

Bug 表现：

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 现场代码：

// 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。

修复： 将值导入和类型导入分开：

import { createApp } from 'vue'       // 值导入
import type { App as VueApp } from 'vue'  // 类型导入 — Rolldown 会删除此行

修复后验证：

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）机制 配合框架的生命周期，是一个零配置的内置能力。

核心代码：

<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"`	加载失败时在回调中做降级处理

常见优化：

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

// 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 的代码输出：

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

// 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 的代码输出：

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

// 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 语法：

// 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 路由定义如下：

// 子应用 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` 控制侧边栏/菜单高亮

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

// ✅ 这段代码在微前端环境中完全不需要改动
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` 做导航守卫

// ✅ 同样不需要改动
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 的写法，必须改造。

// ❌ 错误：独立运行能工作，微前端环境判断失败
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` 做页面跳转

// ❌ 错误：跳过 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()` 打开子应用内页面

// ❌ 错误
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` 解析

// ❌ 错误
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 重定向使用硬编码路径

// ❌ 错误：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`	动态拼接，适配任何环境

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

// ============================================
// 改造前 — 充满隐患的旧代码
// ============================================
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 采用）

// 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}/`)
})

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

验证修复：

curl -s -I http://localhost:5173/ | grep -i access-control
# → Access-Control-Allow-Origin: *           ✅
# → Access-Control-Allow-Methods: GET, POST  ✅

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

// vite.config.ts
export default defineConfig({
  server: {
    port: 3001,
    headers: {
      'Access-Control-Allow-Origin': '*'
    }
  }
})

Vite 的 dev server 本身支持自定义 headers，不需要额外写服务器代码。

方案三：Webpack 项目配置 devServer

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

方案四：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）机制的经典问题。答案分两层：冲突确实存在，但不是"谁覆盖谁"，而是产生了双方都不想要的"混合样式"。

一、两套样式规则对比

/* 主应用的 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 的配置：

{
  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 规则添加作用域前缀：

/* 子应用写的 */
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 打开开发者工具：

# 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：已经发现了样式冲突问题，如何修复？有哪些方案？

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

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

根因回顾：

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

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

// ✅ 修复后的配置
{
  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 } 泄漏进了子应用。

修复方案：

/* ❌ 主应用当前写法 — 全局 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	验证	启动子应用 → 启动主应用 → 访问对应路由确认加载成功

88 KiB Raw Blame History Unescape Escape