# Vite 面试题（含详细解答）

> 基于本项目的 Vue 3 + Vite + 自定义插件实战经验整理。  

---  

## 1. Vite 和 Webpack 在项目开发中有哪些区别？

这是一道高频面试题，关键不是背概念，而是从**开发体验、构建机制、配置复杂度、生态兼容性**四个维度说清楚。  

### 1.1 核心差异：开发阶段的模块处理方式

**Webpack** 是一个 **Bundle-based** 的构建工具。开发时它会从入口文件出发，递归解析所有依赖，把所有模块打包成一个（或多个）bundle，然后启动 dev server。每次代码变更，它需要重新打包受影响的模块并刷新 bundle，这就是为什么大项目中 Webpack 的 HMR 有时会明显变慢。  

**Vite** 在开发阶段不走打包流程，而是利用浏览器原生支持的 **ES Module (ESM)**。它直接把 `.vue`、`.ts`、`.jsx` 等源码文件按需编译后通过 ESM 发给浏览器。浏览器通过 `<script type="module">` 发起一个个 import 请求，Vite 的 dev server 拦截这些请求并实时编译返回。这种「按需编译」的方式使得冷启动和热更新都非常快，几乎与项目规模无关。  

```
Webpack 开发流程：  
  入口 → 递归打包所有依赖 → bundle → dev server → 浏览器  
  
Vite 开发流程：  
  浏览器 import → dev server 拦截 → 按需编译单个文件 → 返回浏览器  
```

### 1.2 冷启动速度

|        | Webpack                                            | Vite                                  |
| ------ | -------------------------------------------------- | ------------------------------------- |
| 冷启动 | 预先打包整个应用，大型项目可能需要几十秒甚至几分钟 | 只编译浏览器当前请求的文件，通常 < 1s |
| 原理   | Bundle-first                                       | ESM on-demand                         |

### 1.3 热更新（HMR）

- **Webpack**：文件变更后，需要重新构建受影响的模块链并替换 bundle，项目越大越慢。  
- **Vite**：只失效变更文件及其直接依赖链上的模块，通过 WebSocket 推送更新，浏览器重新 import 即可。因为本身就是按需加载的，HMR 粒度天然更细。

### 1.4 底层依赖

| 阶段     | Webpack                 | Vite                                         |
| -------- | ----------------------- | -------------------------------------------- |
| 开发构建 | Webpack 自己（JS 实现） | **esbuild**（Go 实现，快 10-100 倍）做预构建 |
| 生产打包 | Webpack / Terser        | **Rollup**（成熟的 ES module 打包器）        |

**为什么 Vite 不用 esbuild 打包生产环境？** esbuild 虽然极快，但在旧版本js代码支持，代码分割、Tree Shaking 的精细控制方面不如 Rollup 成熟。Vite 选择 Rollup 作为生产构建引擎是务实的选择。  

#### 1.4.1 依赖预构建的两大作用（关键技术）

Vite 的依赖预构建解决两个核心问题：  

**① 格式兼容 — CJS/UMD → ESM**  

很多第三方依赖（特别是老牌 npm 包）发布的是 CommonJS 或 UMD 格式。浏览器原生只支持 ESM，无法直接加载 CJS 模块。esbuild 在预构建阶段将这些包统一转换为浏览器可识别的 ESM 格式。  

```js
// node_modules 中的 CJS 包  
module.exports = function sum(a, b) { return a + b }  
  
// 预构建后（node_modules/.vite/deps/sum.js）  
export default function sum(a, b) { return a + b }  
```

**② 性能优化 — 合并细碎模块**  

有些包内部由成百上千个独立文件组成（典型如 `lodash-es`，每个工具函数一个文件）。如果不做合并，浏览器将发起数百个级联的 HTTP 请求，形成严重的请求瀑布：  

```
浏览器 import lodash-es  → 请求 /node_modules/lodash-es/add.js    → 请求 /node_modules/lodash-es/_baseAdd.js      → 请求 /node_modules/lodash-es/_createMathOperation.js        → ...（数百个请求层层依赖）  
```

Vite 将这些细碎模块预构建为单个或少数几个文件，把成百上千次请求合并成数次，大幅减少浏览器请求带来的性能开销。预构建结果缓存在 `node_modules/.vite/deps/`，只在依赖变更时重新执行。  

### 1.5 配置复杂度

**Webpack**：你需要配置 `entry`、`output`、`loader`（如 `css-loader`、`style-loader`、`babel-loader`）、`plugin`（如 `HtmlWebpackPlugin`、`MiniCssExtractPlugin`）。一个中等规模的项目 webpack.config.js 动辄几百行。  

**Vite**：开箱即用。`.vue`、`.ts`、`.jsx`、CSS、静态资源都不需要额外配置。一个典型的 Vite 配置：  

```js
// vite.config.js — 本项目实际配置  
import { defineConfig } from 'vite'  
import vue from '@vitejs/plugin-vue'  
  
export default defineConfig({  
  plugins: [vue()]   // 一行搞定 Vue SFC 支持  
})  
```

### 1.6 生态与兼容性

- **Webpack**：生态极其庞大，loader 和 plugin 覆盖几乎所有场景。如果你需要兼容 IE11 或做一些非常规的构建操作，Webpack 是更安全的选择。  
- **Vite**：插件生态快速增长中，但一些老旧/小众的 Webpack loader 可能没有直接对应。不过 Vite 的 Rollup 插件兼容层可以复用大量 Rollup 插件。

### 1.7 总结

| 维度       | Webpack          | Vite                     |
| ---------- | ---------------- | ------------------------ |
| 开发模式   | Bundle-first     | ESM on-demand            |
| 冷启动     | 慢（全量打包）   | 快（按需编译）           |
| HMR        | 随项目规模递减   | 几乎恒定                 |
| 预构建     | 无               | esbuild（Go）            |
| 生产打包   | Webpack + Terser | Rollup                   |
| 配置复杂度 | 高               | 低                       |
| 生态成熟度 | 极高             | 快速增长                 |
| 浏览器要求 | 无限制           | 需支持 ESM（现代浏览器） |

**一句话总结**：Vite 用「开发时不打包 + esbuild 预构建 + Rollup 生产打包」的组合拳，在开发体验上对 Webpack 形成了代际优势；Webpack 则在兼容性和极端定制场景上仍有不可替代的地位。  

---  

## 2. Vite 的核心工作原理是什么？

### 2.1 开发阶段

1. **启动 dev server**：Vite 启动一个基于 [connect](https://github.com/senchalabs/connect) 的 HTTP 服务器。  
2. **预构建依赖**：用 esbuild 把 `node_modules` 中的 CommonJS/UMD 依赖转换为 ESM，并合并细碎模块（如 lodash-es 的几百个文件）以减少浏览器请求数。  
3. **源码按需编译**：浏览器请求 `src/main.js` → Vite 拦截 → 用 esbuild 编译 JS/TS → 返回 ESM 格式。  
4. **`.vue` 文件处理**：由 `@vitejs/plugin-vue` 拦截 `.vue` 请求，将其拆分为 template、script、style 三部分分别处理。  
5. **HMR**：文件变更时，Vite 通过 WebSocket 通知浏览器，浏览器重新请求变更的模块。

### 2.2 生产构建

直接使用 Rollup 打包，因为 Rollup 在 tree-shaking、代码分割、输出稳定性方面是最好的 ESM 打包器。  

---  

## 3. Vite 的预构建（Pre-bundling）做了什么？为什么需要它？

### 3.1 做了什么

Vite 使用 **esbuild** 对 `node_modules` 中的依赖进行预构建：  

1. **CJS → ESM**：将 CommonJS/UMD 格式的包转为 ESM。  
2. **合并碎片模块**：有些包（如 `lodash-es`）由数百个独立文件组成，Vite 将它们合并为单个模块，大幅减少 HTTP 请求。

### 3.2 为什么需要

- **CJS 兼容**：浏览器只认识 ESM，而 npm 上有大量 CJS 包。  
- **请求瀑布**：如果不合并，`lodash-es` 的一个 import 可能触发几百个级联请求，拖慢页面加载。

### 3.3 缓存策略

预构建结果缓存在 `node_modules/.vite/deps/`，只有 `package.json` 中的依赖列表变更时才会重新执行，开发阶段几乎无感。  

---  

## 4. 为什么 Vite 开发时用 esbuild，生产打包用 Rollup？

|          | esbuild                                   | Rollup                                  |
| -------- | ----------------------------------------- | --------------------------------------- |
| 优势     | 极快（Go 语言，原生并发）                 | 成熟的 tree-shaking、精细的代码分割控制 |
| 劣势     | 代码分割能力弱，对 ESM 输出的精细控制不够 | 相对较慢                                |
| 适用阶段 | **开发**——需要快速编译和预构建            | **生产**——需要最优的输出质量            |

Vite 不是绑死在一个工具上，而是「谁适合干什么就让它干什么」。  

---  

## 5. Vite 的 HMR（热模块替换）是如何工作的？

1. **文件监听**：Vite 使用 [chokidar](https://github.com/paulmillr/chokidar) 监听文件变更。  
2. **模块失效**：文件变更后，Vite 以该文件为起点，沿着模块依赖图找到所有受影响的模块。  
3. **边界判定**：找到最近的「HMR 边界」（通常是接受热更新的组件/模块），只重载边界内的模块。  
4. **WebSocket 推送**：Vite 通过 WebSocket 向浏览器发送更新信息（变更文件路径 + 更新类型）。  
5. **浏览器处理**：客户端 runtime 收到消息后，重新 import 变更的模块并执行框架特定的更新逻辑（如 Vue 的 `hot.accept`）。

对于 Vue SFC，`@vitejs/plugin-vue` 为每个 `.vue` 文件注入 HMR 边界代码，所以修改一个组件只更新它自己，不影响页面状态。  

---  

## 6. Vite 中如何处理环境变量？

Vite 通过 `.env` 文件加载环境变量，支持四种优先级：  

| 文件                | 用途                             |
| ------------------- | -------------------------------- |
| `.env`              | 所有环境共享                     |
| `.env.local`        | 本地覆盖（应加入 .gitignore）    |
| `.env.[mode]`       | 特定模式（如 `.env.production`） |
| `.env.[mode].local` | 特定模式的本地覆盖               |

在代码中通过 `import.meta.env` 访问：  

```js
// 所有变量，VITE_ 前缀的才会暴露给客户端  
console.log(import.meta.env.VITE_API_BASE_URL)  
  
// 内置变量  
import.meta.env.MODE   // 'development' | 'production'  
import.meta.env.DEV    // boolean  
import.meta.env.PROD   // boolean  
import.meta.env.BASE_URL  // 部署基础路径  
```

**安全性**：只有 `VITE_` 前缀的变量会暴露给客户端，这防止了服务端密钥泄露到浏览器。  

---  

## 7. Vite 如何做代码分割（Code Splitting）？

Vite 使用 Rollup 的生产构建能力，代码分割主要通过以下方式：  

### 8.1 动态 import（自动分割）

任何动态 import 都会在打包时自动产生独立的 chunk，无需任何配置：  

```js
// 源码  
import('./sum.js').then(({ sum }) => {  
  console.log(sum(1, 2))})  
  
// 打包产物  
// dist/assets/sum-xxxx.js   ← 自动分离为独立 chunk  
```

打包产物文件名中的 `xxxx` 是内容哈希，用于浏览器长期缓存。当文件内容不变时，哈希不变，浏览器直接命中缓存。  

### 8.2 手动配置分割策略 — 对象语法

如果你的项目里有一个通用模块需要单独拆包（比如一段多处引用的工具函数），可以通过 `manualChunks` 手动指定：  

```js
// src/test.js  
export const sayHello = () => {  
  console.log('hello')}  
```

```js
// vite.config.js  
export default defineConfig({  
  build: {    rollupOptions: {      output: {        manualChunks: {          // key: chunk 名称，value: 模块路径  
          'test-vendor': './src/test.js'        }      }    }  }})  
```

### 8.3 手动配置分割策略 — 函数语法（更灵活）

对象语法只能匹配精确路径，函数语法可以基于模块 ID 做任意逻辑判断：  

```js
// vite.config.js  
export default defineConfig({  
  build: {    rollupOptions: {      output: {        manualChunks(id) {          if (id.includes('test')) {            return 'test-vendor'   // 所有路径含 'test' 的模块合并为一个 chunk          }        }      }    }  }})  
```

函数语法更适合实际项目：你可以按 `node_modules` 来源拆分 vendor，按业务域拆分 page chunks，或者按体积阈值动态决定是否拆分。  

---  

## 8. Vite 的 CSS 处理有什么特点？

1. **原生 CSS 支持**：直接 `import './style.css'`，Vite 自动注入到页面。  
2. **CSS Modules**：文件名以 `.module.css` 结尾，自动启用 CSS Modules。  
3. **PostCSS**：项目根目录放置 `postcss.config.js` 即可，Vite 会自动应用。  
4. **CSS 代码分割**：生产构建时，每个异步 chunk 的 CSS 会被提取为独立文件，按需加载。  
5. **`@import` 内联与 rebase**：`@import` 和 `url()` 路径会自动重写，避免开发与生产路径不一致。  
6. **预处理器**：安装 `sass` 或 `less` 即可直接使用 `.scss`、`.less` 文件，无需额外配置 loader。

---  

## 9. Vite 的静态资源处理策略是怎样的？

- **小资源（< 4KB）**：自动转为 base64 内联，减少 HTTP 请求。  
- **大资源**：复制到 `dist/assets/`，文件名包含 hash 用于缓存。  
- **`public` 目录**：此目录下的资源**不会被处理**，直接复制到 `dist/` 根目录，适合 `robots.txt`、`favicon.ico` 等。  
- **`new URL`**：支持通过 `new URL('./img.png', import.meta.url)` 动态引用资源。

---  

## 10. 如何调试 Vite 的自定义插件？

1. **添加 `name`**：每个插件必须有唯一的 `name`，方便定位问题。  
2. **在项目中引入 vite-plugin-inspect**  
3. **使用 console.log**：在插件的各个钩子中添加日志，观察执行时机和参数。  
   **启用 debug 模式**：  

   ```bash
   DEBUG=vite:* vite  
   ```5. **使用 Vite 的 `apply` 选项**：可以限制插件只在开发或生产环境生效：  
   ```js  
   {  
     name: 'dev-only-plugin',     apply: 'serve'   // 或 'build'，分别限制开发/生产  
   }  
   ```

---  

## 11. Vite 项目从开发到部署的完整流程是怎样的？

```bash
# 开发  
npm run dev         # vite — 启动 dev server，ESM 按需编译 + HMR  
# 构建  
npm run build       # vite build — Rollup 打包，输出到 dist/  
# 本地预览生产构建  
npm run preview     # vite preview — 在本地启动静态服务器预览 dist/  
```

典型部署：将 `dist/` 目录部署到 CDN 或静态服务器（Nginx、Vercel、Netlify 等）。  

对于 SPA 应用，需要配置 fallback 到 `index.html`：  

```nginx
location / {  
  try_files $uri $uri/ /index.html;}  
```

---  

## 12. 有没有了解微内核设计？Vite 的插件化设计思想是怎样完成个性化打包构建需求的？

### 12.1 什么是微内核架构

微内核（Microkernel）是一种架构模式，核心思想是：**内核只提供最精简的基础能力，所有扩展功能通过插件机制加载**。操作系统领域最经典的例子是 Minix 和 macOS 的 XNU 内核。  

在前端构建工具领域，这个思想同样适用：  

```
┌──────────────────────────────────────────┐  
│              插件层（Plugin Layer）        ││  Vue SFC  │  JSX  │  TS  │  CSS  │  ...  │ ├──────────────────────────────────────────┤  
│            微内核（Minimal Core）          ││  dev server  │  HMR  │  module graph     │  
│  esbuild预构建 │  中间件机制               │└──────────────────────────────────────────┘  
```

### 12.2 Vite 的微内核设计

Vite 的核心（内核）只做几件事：  

| 内核能力        | 说明                                        |
| --------------- | ------------------------------------------- |
| Dev Server      | 基于 connect 的 HTTP 服务器，拦截浏览器请求 |
| 模块图谱        | 追踪所有模块的依赖关系，驱动 HMR            |
| esbuild 预构建  | CJS → ESM 转换 + 细碎模块合并               |
| 中间件/钩子系统 | 提供插件接入点，但不做具体编译              |

**Vue SFC 编译、JSX 转换、TypeScript 类型检查、CSS 预处理 —— 这些全部由插件完成，不在内核里。** 这就是微内核思想：内核保持精简稳定，功能由插件按需扩展。  

### 12.3 插件机制如何实现个性化构建

Vite 的插件体系基于 **Rollup 插件接口** 并做了增强，通过一系列生命周期钩子让开发者在构建各阶段注入自定义逻辑。  

**钩子执行顺序（简化）：**  

```
config → configResolved → options → buildStart  
  → resolveId → load → transform → moduleParsed  → buildEnd  → outputOptions → renderChunk → generateBundle → writeBundle```  
  
**① 通用钩子（Rollup 兼容层）**  
  
```js  
{  
  name: 'my-plugin',  resolveId(id) {},       // 模块解析（虚拟模块入口）  
  load(id) {},            // 模块加载（返回自定义内容）  
  transform(src, id) {}   // 代码转换（最常用）  
}  
```

**② Vite 独有钩子**  

```js
{  
  name: 'my-vite-plugin',  config(config) {},              // 修改用户配置  
  configureServer(server) {},     // dev server 注入中间件  
  handleHotUpdate(ctx) {}         // 自定义 HMR 行为  
}  
```

**enforce 控制执行顺序：** `pre` → 核心插件 → 普通（默认） → `post` → Vite 内置插件  

### 12.4 一个完整的个性化构建案例

回到本项目的 `helloPlugin`，它实现了一个个性化需求——「生产环境自动移除 console.log」：  

```js
// vite.config.js  
function helloPlugin() {  
  return {    name: 'helloPlugin',    // 接入 transform 钩子，拿到每个模块的源码  
    transform(src, id) {      if (!id.includes('/src/')) return null     // 只处理业务代码  
      if (process.env.NODE_ENV === 'production') {        const result = src.replace(/console\.log\([^)]*\);?/g, '')        return { code: result, map: null }      }      return null                                 // 不处理则透传  
    }  }}  
```

这个插件展示了插件化的核心价值：**不需要修改 Vite 源码，不需要 fork 项目，只需写一个函数接入钩子，就能定制打包行为。** 这种「内核不动、插件扩展」的模式，正是微内核架构在前端工程化中的最佳实践。  

### 12.5 总结：Vite 的插件化设计思想怎样完成个性化打包构建需求？

一个结构化的回答应包含以下几点：  

1. **架构层面**：Vite 采用了**微内核设计**。它的核心非常轻量，仅包含一个 ESM 开发服务器和一套插件加载机制。所有高层功能，如框架支持、CSS 预处理、特定文件加载等，都由独立的插件实现。  
2. **接口层面**：Vite 提供了一套**兼容 Rollup 的、统一的插件接口**。这套接口通过暴露一系列生命周期钩子 (**Hooks**)，允许开发者在构建过程的各个关键节点（如配置解析、模块加载、代码转换、HTML 生成等）注入自定义逻辑。  
3. **实践层面**：开发者可以编写一个插件，通过选择合适的钩子来完成特定任务。例如，使用 `transform` 钩子可以支持一种新的语言或文件格式；使用 `configureServer` 钩子可以在开发时添加自定义的服务器中间件；使用 `transformIndexHtml` 则可以动态修改主页面的内容。

---  

## 13. 站在前端架构角度说说 Bundleless 原理

### 14.1 什么是 Bundleless

传统的 Bundle 模式（Webpack 为代表）是「先打包再启动」：  

```
源码 → 打包器（Bundle）→ 一个/多个 bundle 文件 → 浏览器加载  
```

Bundleless 模式（Vite 为代表）跳过了打包这一步：  

```
源码 → 开发服务器按需编译 → 浏览器通过 ESM 直接加载  
```

### 14.2 为什么 Bundleless 现在才成为主流

Bundleless 不是新概念——ESM 规范早在 2015 年就发布了。之前无法普及的原因：  

| 时间      | 瓶颈                              | 现状                                       |
| --------- | --------------------------------- | ------------------------------------------ |
| 2015-2018 | 浏览器 ESM 支持率低（IE 占主流）  | IE 已淘汰，现代浏览器全覆盖                |
| 2015-2019 | npm 包几乎全是 CJS 格式           | 新包逐渐提供 ESM 入口，且有 esbuild 做转换 |
| 2015-2019 | HTTP/1.1 并发连接有限（6个/域名） | HTTP/2 多路复用，数百个请求不再是瓶颈      |

**三个条件同时满足——浏览器 ESM 支持、npm 生态转换能力、HTTP/2 普及——Bundleless 才真正可行。**  

### 14.3 Bundleless 的架构优势

**① 按需编译，冷启动 O(1)**  

传统打包：启动时间 ∝ 项目模块数。Bundleless：只编译浏览器当前请求的文件，启动几乎恒定。  

**② HMR 粒度天然匹配 ESM 边界**  

每个文件就是一个 ESM 模块，热更新不需要重新打包 bundle，只需要让浏览器重新 import 变更的那个文件。  

**③ 开发与生产的明确分工**  

```
开发阶段（Bundleless）          生产阶段（Bundled）  
─────────────────────         ─────────────────────  
  不打包，按需编译                Rollup 全量打包  
  esbuild 做预构建               Tree-shaking  ESM 原生加载                  代码分割 + 压缩  
  追求开发体验                  追求加载性能```  
  
这两个阶段的目标本就不同：开发要快，生产要小。Bundleless 把这个分工理清了。  
  
### 14.4 Bundleless 的工程代价  
  
从架构角度，不是所有场景都适合 Bundleless：  
  
| 场景 | Bundleless 是否适用 | 原因 |  
|---|---|---|  
| 现代浏览器开发 | ✅ 完美 | ESM + HTTP/2 |  
| 需要兼容 IE | ❌ 不行 | IE 不支持 ESM |  
| 巨型 node_modules | ⚠️ 需预构建 | 否则请求数爆炸 |  
| 非 JS 资源（CSS/图片） | ⚠️ 需额外处理 | ESM 只管 JS |  
  
这也是为什么 Vite 不是纯 Bundleless——它用预构建和 Rollup 生产打包弥补了 Bundleless 的短板。**务实的设计比纯粹的理念更重要。**  
```
---  
  
## 扩展思考：如果你来设计一个类似的工具，会怎么做？  
  
这通常是大厂面试的进阶追问。可以从以下角度组织回答：  
  
1. **利用浏览器原生能力**：现代浏览器已经支持 ESM、ES2020+ 语法，开发阶段不需要向下兼容。  
2. **语言选择**：高频编译用 Go/Rust 实现的工具（如 esbuild、SWC），生产打包用成熟的 JS 生态工具。  
3. **按需编译**：改变「先打包再启动」的思路，变成「请求时编译」。  
4. **插件兼容**：设计插件接口时尽量对齐已有标准（如 Rollup 插件格式），降低迁移成本。


---

## 14. Webpack 的 Loader 和 Plugin 有什么区别？各自的工作原理是什么？

### 14.1 核心区别

| 维度     | Loader                                      | Plugin                                      |
| -------- | ------------------------------------------- | ------------------------------------------- |
| 职责     | **模块内容转换**——把非 JS 文件转为 JS 模块  | **构建流程扩展**——在打包各阶段注入自定义逻辑 |
| 作用对象 | 单个文件（模块）                            | 整个构建流程                                |
| 本质     | 一个**函数**，接收源码，返回转换后的代码    | 一个**类**（或包含 `apply` 方法的对象）     |
| 执行时机 | 模块加载时，在文件被添加到依赖图之前        | 通过钩子在编译各阶段触发                    |
| 典型例子 | `css-loader`、`babel-loader`、`vue-loader`   | `HtmlWebpackPlugin`、`MiniCssExtractPlugin` |

**一句话**：Loader 管"翻译"（把各种文件翻译成 JS），Plugin 管"编排"（控制打包流程的各个环节）。

### 14.2 Loader 的工作原理

Loader 是一个 Node.js 函数，它接收源文件内容，返回转换后的结果：

```js
// 一个最简单的 loader：把文件内容转为大写
module.exports = function (source) {
  return source.toUpperCase()
}
```

Loader 支持链式调用，从右到左（或从下到上）依次执行：

```
处理顺序：css-loader → style-loader
写法：use: ['style-loader', 'css-loader']
      // ←────────── 从右到左 ──────────
```

每个 loader 必须做三件事之一：返回转换后的代码、返回 `this.callback()`（支持 source map）、或通过 `this.async()` 转为异步。

**常见 Loader 分类：**

| 类型     | Loader 示例      | 作用                                  |
| -------- | ---------------- | ------------------------------------- |
| 编译类   | `babel-loader`   | ES6+ → ES5                            |
| 样式类   | `css-loader`     | 解析 CSS 中的 `@import` 和 `url()`    |
| 文件类   | `file-loader`    | 把文件复制到输出目录并返回 URL        |
| 模板类   | `vue-loader`     | 解析 `.vue` 单文件组件                |

### 14.3 Plugin 的工作原理

Plugin 基于 Webpack 的 **Tapable 事件机制**。Webpack 在编译的各个阶段广播事件，Plugin 通过监听这些事件介入构建：

```js
class MyPlugin {
  apply(compiler) {
    // compiler.hooks 提供了数十个生命周期钩子
    compiler.hooks.emit.tapAsync('MyPlugin', (compilation, callback) => {
      // compilation: 本次编译的上下文，可访问所有模块和产物
      // 在这里修改产物、添加文件等
      callback()
    })
  }
}
```

**Webpack 的编译生命周期（关键钩子）：**

```
environment → afterEnvironment → entryOption → afterPlugins → afterResolvers
  → initialize → run → compile → compilation → make → finishMake
    → afterCompile → emit → afterEmit → done
```

**Plugin 能做的典型事情：**

- **`HtmlWebpackPlugin`**：在 `emit` 阶段生成 HTML 文件并自动注入打包后的 JS/CSS 引用
- **`MiniCssExtractPlugin`**：在 `afterCompile` 阶段把 CSS 从 JS bundle 中提取为独立文件
- **`DefinePlugin`**：在 `compilation` 阶段做编译时常量替换

### 14.4 面试怎么答

1. 先说清楚二者本质区别：Loader 是**文件级转换器**，Plugin 是**流程级控制器**。
2. 各举一个熟悉的例子说明（如 `css-loader` 和 `HtmlWebpackPlugin`）。
3. 如果需要，简述 Loader 的链式调用和 Plugin 的 Tapable 钩子机制。

---

## 15. Tree Shaking 的原理是什么？为什么必须基于 ESM？

### 15.1 什么是 Tree Shaking

Tree Shaking（摇树优化）指**消除没有被使用的代码**（dead code elimination）。名字来源于：把应用比作一棵树，用到的代码是绿叶，没用到的代码是枯叶；摇晃这棵树，枯叶就会掉下来。

```
源代码                         Tree Shaking 后
┌───────────────────┐        ┌───────────────────┐
│ export const a    │        │ export const a    │
│ export const b ✗  │  ──→   │                   │
│ export const c    │        │ export const c    │
│ function d() ✗    │        │                   │
└───────────────────┘        └───────────────────┘
```

### 15.2 为什么必须基于 ESM

Tree Shaking 的前提是**编译时能确定模块的导入导出关系**。这要求模块语法必须是静态的：

| 模块系统 | 导入语法     | 能否做 Tree Shaking | 原因                   |
| -------- | ------------ | ------------------- | ---------------------- |
| ESM      | `import`/`export` | ✅ 能                | **静态声明**——编译时就能确定依赖关系 |
| CommonJS | `require()`       | ❌ 不能              | **动态调用**——`require()` 可以放在 if/for/函数里，运行时才知道 |

```js
// ESM — 静态，编译时即可分析
import { sum } from './math'   // 语法层面必须写在顶层

// CJS — 动态，运行时才能确定
const modulePath = condition ? './a' : './b'
const result = require(modulePath)   // require 就是一个函数调用
```

### 15.3 实现原理

以 Rollup/Webpack 为例，Tree Shaking 分三步：

1. **标记（Mark）**：从入口开始，遍历所有模块的 `import/export`，标记哪些导出被使用了。
2. **清除（Sweep）**：删除没有被标记的导出语句及其关联的代码。
3. **副作用处理**：如果一个模块有顶层副作用（如 `console.log()`、修改全局变量），即使没有导出被使用，整个模块也不会被摇掉。

```json
// package.json 中声明副作用可以优化 Tree Shaking
{
  "sideEffects": false   // 告诉打包器：所有模块都无副作用，放心摇
  // 或指定具体文件
  "sideEffects": ["*.css", "*.global.js"]
}
```

### 15.4 Webpack 和 Rollup 的差异

|          | Webpack                               | Rollup                      |
| -------- | ------------------------------------- | --------------------------- |
| 实现方式 | 通过 `usedExports` + `TerserPlugin`   | 原生支持，更彻底            |
| 产物     | 更"扁"——模块合并后再压缩              | 更"净"——尽可能保留 ESM 结构 |
| 生产效果 | 良好，但可能保留一些薄弱的引用        | 极简，几乎零冗余            |

这也是 Vite 选择 Rollup 做生产打包的原因之一：Rollup 的 Tree Shaking 天然更干净。

---

## 16. 什么是 Source Map？不同模式如何选择？

### 16.1 为什么需要 Source Map

构建工具会把源码编译、混淆、压缩成一个（或几个）bundle。浏览器中报错时，错误堆栈指向的是打包后的代码——行号、变量名都和源码对不上。Source Map 是一个映射文件，把打包产物的每一行/列映射回源码的对应位置。

```
源码 (main.js)              打包产物 (bundle.js)          Source Map (.map)
┌────────────────┐         ┌─────────────────┐         ┌──────────────────┐
│ 1: const a = 1 │         │ 1: !function(){ │         │ bundle.js L1:C10  │
│ 2: console.log │  ───→   │ 2:   const a=1, │  ───→   │   → main.js L1:C7 │
│ 3:   (a + 2)   │         │ 3:   console    │         │ bundle.js L3:C5   │
│                │         │ 4:     .log(a+2)│         │   → main.js L2:C9 │
└────────────────┘         └─────────────────┘         └──────────────────┘
```

## 17. 前端模块化的发展历程：从 IIFE 到 ESM

### 17.1 为什么需要模块化

前端代码从"一个 HTML 里写几百行 JS"到"几万行代码分布在几十个文件"，如果不做模块化，会遇到：

- **全局命名冲突**：两个文件定义了同名变量，互相覆盖
- **依赖管理混乱**：`<script>` 标签的加载顺序必须正确，手动维护极其脆弱

### 17.2 演进脉络

```
IIFE →  CommonJS (2009, Node.js)  →  AMD (2011, 浏览器)
  →  UMD (2011, 兼容)  →  ES Module (2015, 标准)  →  今天
```

**① IIFE（立即执行函数表达式）**

```js
// 用闭包隔离作用域，通过参数传入依赖
var myModule = (function ($) {
  var privateVar = 'secret'
  return {
    doSomething: function () { $('body').text('hello') }
  }
})(jQuery)
```

- ✅ 解决了全局命名冲突
- ❌ 依赖顺序仍需手动管理，没有标准的加载机制

**② CommonJS（Node.js 原生支持）**

```js
// math.js
module.exports = { sum: (a, b) => a + b }
// app.js
const { sum } = require('./math')
```

- ✅ 同步加载，适合服务端（文件在本地磁盘）
- ❌ 不适合浏览器——`require()` 是同步的，在浏览器中会阻塞渲染

**③ AMD（Asynchronous Module Definition）**

```js
// 专门为浏览器设计，异步加载
define(['jquery', './math'], function ($, math) {
  return { value: math.sum(1, 2) }
})
```

- ✅ 异步加载，不阻塞页面
- ❌ 写法繁琐，嵌套多了可读性差

**④ UMD（Universal Module Definition）**

一套兼容 CommonJS + AMD + 全局变量的样板代码，让一个模块同时运行在 Node.js 和浏览器中。今天的很多 npm 包仍然发布 UMD 格式。

**⑤ ES Module（ES2015，今天的标准）**

```js
// math.js
export const sum = (a, b) => a + b
// app.js
import { sum } from './math'
```

- ✅ **静态语法**——编译时即可做 Tree Shaking、代码分析
- ✅ **浏览器原生支持**——`<script type="module">` 直接可用
- ✅ **标准化**——不依赖任何第三方库

### 17.3 总结对比

| 模块系统  | 加载方式 | 适用环境 | 静态分析 | 当前状态         |
| --------- | -------- | -------- | -------- | ---------------- |
| IIFE      | 手动     | 浏览器   | ❌        | 历史遗留         |
| CommonJS  | 同步     | Node.js  | ❌        | Node.js 仍广泛用 |
| AMD       | 异步     | 浏览器   | ❌        | 基本淘汰         |
| UMD       | 兼容     | 通用     | ❌        | npm 包仍大量使用 |
| ES Module | 静态声明 | 所有环境 | ✅        | **现在的标准**   |

---

## 18. Babel 的工作原理（解析 → 转换 → 生成）及常用配置

### 18.1 Babel 做了什么

Babel 是一个 JavaScript 编译器，它的核心任务是把**新语法写的代码**转换成**旧环境能运行的代码**：

```js
// 输入：ES6+ 箭头函数 + const
const double = (n) => n * 2

// 输出：ES5
var double = function (n) { return n * 2 }
```

### 18.2 三阶段工作流

```
源码（字符串）
    ↓
【① Parse 解析】
    ↓
AST（抽象语法树）
    ↓
【② Transform 转换】← Plugin 在这一步介入
    ↓
新的 AST
    ↓
【③ Generate 生成】
    ↓
目标代码（字符串）
```

**① Parse（解析）**：把字符串代码解析为 AST。Babel 使用 `@babel/parser`（巴比伦），这一阶段分为词法分析（分词）和语法分析（构建语法树）。

**② Transform（转换）**：遍历 AST，对感兴趣的节点做增删改。这是 Babel 插件工作的核心阶段。每个 Plugin 就是一个 visitor——告诉 Babel"遇到 XX 类型的 AST 节点时做什么"。

```js
// 一个极简 Babel 插件：把所有标识符 name 反转
const babel = require('@babel/core')

const reversePlugin = {
  visitor: {
    Identifier(path) {
      path.node.name = path.node.name.split('').reverse().join('')
    }
  }
}

babel.transformSync('const hello = "world"', { plugins: [reversePlugin] })
// → "const olleh = "world";"
```

**③ Generate（生成）**：把转换后的 AST 重新生成为字符串代码，同时生成 Source Map。

## 19. 如何设计一个前端项目的 CI/CD 流水线？

### 19.1 典型流水线阶段

```
代码推送 → Lint 检查 → 单元测试 → 构建 → 部署
  Push      Lint        Test       Build   Deploy
─────────────────────────────────────────────────→
              ← 任何阶段失败，阻止后续，通知开发者
```

### 19.2 各阶段详解

**① Lint & 格式检查**

```yaml
# .github/workflows/ci.yml (GitHub Actions 示例)
- name: Lint
  run: |
    npx eslint src/ --ext .js,.ts,.vue
    npx prettier --check src/
    npx stylelint "src/**/*.{css,scss}"
```

- **ESLint**：代码逻辑规则检查（未使用变量、禁止 console 等）
- **Prettier**：代码格式一致性检查
- **Stylelint**：CSS/SCSS 代码规范

**② 类型检查（TypeScript）**

```bash
npx tsc --noEmit   # 只做类型检查，不产出 JS 文件
```

即使 Vite/esbuild 在构建时不检查类型（只做语法转换），CI 中也必须独立跑一次 `tsc --noEmit`，防止类型错误流入生产。

**③ 单元测试 & 覆盖率**

```bash
npx vitest run --coverage
```

设置覆盖率门槛，低于阈值阻断流水线：

```json
// vitest.config.ts
{
  coverage: {
    thresholds: {
      lines: 80,
      functions: 80,
      branches: 70,
      statements: 80
    }
  }
}
```

**④ 构建**

```bash
npm run build   # 触发 vite build / webpack build
```

构建产物通常上传为 artifact，供后续部署阶段使用。

**⑤ 部署**

根据环境不同选择策略：

| 环境     | 策略                              |
| -------- | --------------------------------- |
| 开发环境 | 合并到 `dev` 分支后自动部署       |
| 预发环境 | 合并到 `release` 分支后自动部署   |
| 生产环境 | 打 tag 后手动审批 + 部署          |

**⑥ 通知**

- 失败 → 企业微信/钉钉/Slack 通知 + @相关人员
- 成功 → 更新部署日志，通知（可选）

### 19.3 进阶实践

- **缓存依赖**：CI 中缓存 `node_modules`，大幅缩短安装时间
- **增量构建**：使用 Nx/Turborepo 等工具，只构建受影响的子项目
- **构建产物对比**：上传前对比产物大小，异常增长时报警
- **E2E 测试**：用 Playwright/Cypress 在部署后做端到端验证

---

## 20. Monorepo vs Multirepo：前端项目的代码组织方式

### 20.1 两个概念

|          | Monorepo                         | Multirepo                         |
| -------- | -------------------------------- | -------------------------------- |
| 定义     | 多个项目放在**一个仓库**中       | 每个项目**独立仓库**             |
| 依赖管理 | 共享 `node_modules`，统一版本   | 各自独立的依赖                   |
| 工具     | pnpm workspaces / Turborepo / Nx | 各自独立的 `package.json`        |
| 典型用户 | Vue/Vite/React/Babel             | 传统企业项目                     |

### 20.2 Monorepo 的核心优势

**① 代码共享零摩擦**

```bash
# Multirepo：改一个共享组件，要走 3-4 步
1. 改 shared-utils 仓库 → 发 npm 包
2. 项目 A 升级 shared-utils 版本
3. 项目 B 升级 shared-utils 版本
4. 如果 A 和 B 不兼容新 API → 继续修

# Monorepo：改完即生效
packages/
  shared-utils/   ← 改了这里
  project-a/      ← 自动看到变更
  project-b/      ← 自动看到变更
```

**② 原子化提交**：一个 feature 同时改三个包，一个 commit 搞定，不会出现"忘记升级依赖"的问题。

**③ 统一工具链**：一个 ESLint 配置、一套构建脚本、一致的 CI 流程，所有子项目共享。

### 20.3 Monorepo 的挑战

| 挑战           | 解决方案                             |
| -------------- | ------------------------------------ |
| 仓库体积大     | Git 浅克隆、部分检出                 |
| 构建速度       | pnpm workspace + Turborepo 并行构建  |
| 版本管理混乱   | Changesets / Lerna-Lite 管理发布     |
| 权限控制困难   | CODEOWNERS 文件 + 分支保护规则       |

**pnpm 的幽灵依赖隔离**是杀手特性：在 pnpm 下，package A 不能直接 `import` package B 的依赖（除非 B 显式声明了 peerDependencies 或 A 自己也安装了），彻底避免了"本地能跑、CI 炸"的问题。

---

## 21. npm/pnpm/yarn 的依赖管理机制对比

### 21.1 安装机制的底层差异

|          | npm                   | yarn                 | pnpm                                |
| -------- | --------------------- | -------------------- | ----------------------------------- |
| 安装方式 | 平铺 + 嵌套（v3 后改进） | 平铺（Plug'n'Play 可选）| **内容寻址存储 + 硬链接**           |
| `node_modules` 结构 | 扁平化（有幽灵依赖） | 扁平化（有幽灵依赖） | **非扁平化**（严格隔离）             |
| 磁盘效率 | 低（每个项目独立复制）| 中（有缓存但仍复制） | **高**（全局 store，跨项目共享）    |
| `node_modules` 体积 | ~500 MB（中型项目）| ~400 MB             | **~150 MB**                         |

### 21.2 pnpm 的非扁平 node_modules

这是 pnpm 最大的设计差异：

```
npm/yarn 的 node_modules（扁平化）
node_modules/
  react/          ← 你安装的
  loose-envify/ ← react 的依赖被提升到顶层，你可以 import
  object-assign/ ← 同上

pnpm 的 node_modules（非扁平）
node_modules/
  .pnpm/           ← 全局 store 的硬链接
  react/           ← 符号链接 → .pnpm/react@18.2.0/node_modules/react/
  // loose-envify 不在你的 node_modules 顶层！
```

```js
// npm/yarn 下能跑，pnpm 下报错
import looseEnvify from 'loose-envify'  // ❌ 你没安装它，react 才依赖它
```

**幽灵依赖（Phantom Dependency）** 指的就是这种"能访问但未声明"的依赖。pnpm 从根本上杜绝了它。

### 21.3 内容寻址存储（Content-Addressable Storage）

pnpm 的全局 store（`~/.pnpm-store`）以文件内容的 hash 作为文件名存储：

```
~/.pnpm-store/v3/
  files/
    1a/2b3c...hash...   ← react@18.2.0 的 index.js（内容哈希）
    9f/8e7d...hash...   ← 同一个文件即使被 100 个项目引用，也只存一份
```

项目 `node_modules` 里的文件都是这个 store 的**硬链接**（hard link），不占额外磁盘空间。

### 21.4 lock 文件的作用

| 文件                | 包管理器 | 作用                                      |
| ------------------- | -------- | ----------------------------------------- |
| `package-lock.json` | npm      | 锁定整个依赖树的精确版本（包括子依赖）    |
| `yarn.lock`         | yarn     | 同上                                      |
| `pnpm-lock.yaml`    | pnpm     | 同上，但格式更紧凑                        |

**为什么需要 lock 文件？** 因为 `package.json` 中的版本号通常是范围（如 `^1.2.3`），不同时间安装可能得到不同版本。lock 文件把整棵依赖树的版本固化下来，确保"所有人、所有环境安装的依赖完全一致"。

**lock 文件必须提交到 Git。**

### 21.5 实战建议

| 场景                         | 推荐         |
| ---------------------------- | ------------ |
| 个人项目                     | npm（零配置）|
| Monorepo                     | **pnpm**     |
| 团队协作，重视稳定性         | pnpm         |
| 遗留项目（已有 yarn.lock）   | yarn         |
| CI/CD 速度要求高             | pnpm         |

---

## 22. 浏览器缓存策略与前端构建的配合

### 22.1 两种缓存的角色

| 缓存类型   | 控制字段                              | 行为                                       |
| ---------- | ------------------------------------- | ------------------------------------------ |
| 强缓存     | `Cache-Control`、`Expires`            | 不发起请求，直接从浏览器缓存读取（200 from disk） |
| 协商缓存   | `ETag/If-None-Match`、`Last-Modified` | 发起请求，服务器返回 304 告知"没变，用缓存" |

### 22.2 前端构建产物命名策略

构建工具的**内容哈希（Content Hash）** 是实现缓存策略的基石：

```
dist/
  index.html                   ← 不缓存（或协商缓存）
  assets/
    index-a3f8b2.js            ← 强缓存（一年）
    vendor-7c1d9e.js           ← 强缓存（一年）
    logo-4b2e1f.png            ← 强缓存（一年）
```

**核心原则**：

```
文件内容不变 → 文件名（hash）不变 → 浏览器命中缓存 → 不需要下载
文件内容变了 → 文件名（hash）变了 → 浏览器视为新文件 → 必须下载
```

### 22.3 Nginx 配置示例

```nginx
# 带 hash 的静态资源：强缓存，长期有效
location /assets/ {
  expires 1y;
  add_header Cache-Control "public, immutable";
}

# index.html：协商缓存，确保更新能及时生效
location / {
  add_header Cache-Control "no-cache";  # 每次都验证，304 返回
}
```

**为什么 `index.html` 不能做强缓存？** 因为每次构建后，HTML 中引用的 JS/CSS 文件名（hash）会变。如果 HTML 被强缓存，浏览器拿到的是旧 HTML，里面引用的还是旧的 hash 文件名——但旧文件可能已经从服务器删除了，导致白屏。

### 22.4 模块的缓存策略

| 文件类型       | 策略                   | Nginx 配置              |
| -------------- | ---------------------- | ----------------------- |
| `index.html`   | 协商缓存（no-cache）   | `Cache-Control: no-cache` |
| `*.js` / `*.css`（带 hash）| 强缓存一年     | `Cache-Control: max-age=31536000, immutable` |
| 静态图片/字体  | 强缓存一年             | 同上                    |
| `robots.txt`   | 短期强缓存             | `Cache-Control: max-age=86400` |

### 22.5 更新的原子性问题

```
情况：用户打开页面 → 此时 HTML 引用 index-a3f8b2.js
      → 你部署了新版本 → HTML 引用 index-9c4b1d.js
      → 用户点击路由跳转 → 懒加载触发 import()
      → 请求动态 chunk 时，可能已经在服务端被替换了

解决方案：
  - 保留最近 N 个版本的构建产物（不立即删除旧文件）
  - Nginx 配置 5 分钟的重试窗口
  - 或者在 HTML 中内联版本检查逻辑
```

---

## 23. 前端性能优化 — 构建层面能做哪些事？

### 23.1 构建优化全景图

```
构建产物优化
├── 代码层面
│   ├── Tree Shaking（摇掉无用代码）
│   ├── 代码分割（按路由/组件懒加载）
│   ├── 压缩混淆（Terser/esbuild）
│   └── 常量替换（DefinePlugin）
├── 资源层面
│   ├── CSS 提取 & 压缩
│   ├── 图片压缩 & WebP 转换
│   ├── 小资源 base64 内联
│   ├── 字体子集化（只保留用到的字符）
│   └── SVG 优化（svgo）
├── 依赖层面
│   ├── 依赖分析（找出大包替代品）
│   ├── external（CDN 外置大型库）
│   └── 按需引入（如 lodash-es → import { debounce }）
└── 加载策略
    ├── preload/prefetch（提前加载关键资源）
    ├── 异步加载（dynamic import）
    └── module/nomodule（差异化构建）
```

### 23.2 代码层面的具体做法

**① Tree Shaking 前置条件**

```js
// ❌ 副作用写法——整个模块不会被摇掉
import './polyfills'   // 无显式导出，有副作用

// ✅ 在 package.json 中声明
{ "sideEffects": ["./src/polyfills.js"] }
```

**② 路由级代码分割（Vue 3 + Vite）**

```js
// router/index.js
const routes = [
  {
    path: '/dashboard',
    component: () => import('@/views/Dashboard.vue')  // 独立 chunk
  },
  {
    path: '/settings',
    component: () => import('@/views/Settings.vue')   // 独立 chunk
  }
]
```

每个路由页面单独打包，首屏只加载首页的代码。

**③ 第三方库的按需引入**

```js
// ❌ 打包整个 lodash（~70KB gzip）
import _ from 'lodash'

// ✅ 只引入用到的函数（~2KB gzip）
import debounce from 'lodash-es/debounce'

// ✅ 或者用 tree-shakable 的替代品
import { debounce } from 'radash'  // 天然支持 tree-shaking
```

### 23.3 依赖分析工具

| 工具                                   | 作用                                     |
| -------------------------------------- | ---------------------------------------- |
| `rollup-plugin-visualizer`（Vite/Rollup）| 生成可视化 treemap，一眼看出哪个包大     |
| `webpack-bundle-analyzer`（Webpack）    | 同上                                     |
| `vite-plugin-inspect`                  | 查看 Vite 的模块转换过程                 |
| `npm why <package>` / `pnpm why`       | 查看某个依赖为什么被安装了               |

### 23.4 关键指标目标

| 指标               | 目标值       | 说明                   |
| ------------------ | ------------ | ---------------------- |
| 首屏 JS 总体积     | < 200KB gzip | 包括框架 + 业务代码    |
| 首屏 CSS           | < 50KB gzip  | 关键 CSS 应内联        |
| 单个 chunk         | < 100KB gzip | 大包考虑拆分           |
| 图片总大小         | < 500KB      | 使用 WebP，懒加载      |
| Time to Interactive| < 3.5s（3G） | 用户可交互时间         |

### 23.5 Vite 中的构建优化配置

```js
// vite.config.js
export default defineConfig({
  build: {
    target: 'es2015',           // 不转译现代语法，减小体积
    cssCodeSplit: true,         // CSS 按 chunk 拆分
    chunkSizeWarningLimit: 500, // 提高 chunk 大小警告阈值
    rollupOptions: {
      output: {
        manualChunks(id) {
          if (id.includes('node_modules')) {
            if (id.includes('vue')) return 'vue-vendor'
            if (id.includes('echarts')) return 'echarts-vendor'
            return 'vendor'
          }
        }
      }
  }
})
```


---

## 24. SSR（服务端渲染）的原理是什么？与 CSR/SSG 有什么区别？

### 24.1 三种渲染模式对比

|          | CSR（客户端渲染）              | SSR（服务端渲染）               | SSG（静态站点生成）              |
| -------- | ----------------------------- | ------------------------------- | ------------------------------- |
| 渲染地点 | 浏览器                        | 服务端                           | 构建时（服务端）                 |
| 首屏速度 | 慢（先下载 JS，再渲染）        | 快（直接返回 HTML）              | **最快**（纯静态 HTML）          |
| SEO      | ❌ 差（爬虫看到空壳）          | ✅ 好（HTML 已包含内容）          | ✅ 最好                         |
| 服务器压力 | 低（只提供静态文件）         | 高（每次请求都要渲染）            | 低（CDN 即可）                   |
| 适用场景 | 后台管理系统、需要登录的 SPA   | 内容型网站、电商、需要 SEO 的 SPA | 博客、文档站、营销页             |
| 代表框架 | 纯 Vue/React                  | Nuxt.js / Next.js                | Next.js / Astro / VitePress      |

### 24.2 SSR 的核心流程

```
浏览器请求 /page
      ↓
服务端收到请求
      ↓
运行 Vue/React 组件 → 生成完整 HTML 字符串
      ↓
返回 HTML（页面内容已包含在内）
      ↓
浏览器渲染 HTML（用户看到内容了！）
      ↓
同时下载 JS bundle
      ↓
Hydration（水合）：Vue/React 接管 DOM，页面变为可交互
```

**Hydration 是什么？** 服务端渲染的 HTML 是"死的"（纯 HTML，没有事件绑定）。浏览器加载 JS 后，Vue/React 需要把这棵静态 DOM 树"激活"——绑定事件、建立响应式系统。这个过程叫 Hydration（水合）。

```js
// Nuxt 3 中一个 SSR 页面的生命周期
// 1. 服务端执行 → 生成 HTML
// 2. 发送到浏览器
// 3. 浏览器执行 Hydration

<script setup>
// 这段代码在服务端和客户端各执行一次
const { data } = await useFetch('/api/posts')  // 服务端 fetch 一次，数据嵌入 HTML
</script>
```

### 24.3 SSR 的工程化挑战

| 挑战               | 说明                                           | 解决方案                              |
| ------------------ | ---------------------------------------------- | ------------------------------------- |
| **服务端无 DOM**    | `window`/`document` 在 Node.js 中不存在        | 用 `import.meta.client` / `process.client` 守卫 |
| **数据同步**       | 服务端获取的数据要传递给客户端，避免重复请求     | Nuxt 的 `useFetch` / Next 的 `getServerSideProps` |
| **内存泄漏**       | 服务端每个请求都创建 Vue 实例，容易泄漏         | 使用工厂函数创建实例，避免单例        |
| **缓存策略**       | 每次请求都渲染太慢                              | 页面级缓存（Redis）、组件级缓存       |
| **部署复杂度**     | 需要 Node.js 服务器，而不是纯静态文件            | Serverless（Vercel/Netlify）、容器化   |

### 24.4 什么时候选哪种模式

```
需要 SEO + 实时数据？  →  SSR（电商、新闻、社区）
需要 SEO + 内容不常变？→  SSG（博客、文档、官网）
不需要 SEO？          →  CSR（后台管理系统、工具型应用）
混合场景？            →  ISR / 混合渲染（部分页面 SSR，部分 SSG）
```

---

## 25. 如何做前端项目的依赖治理？

### 25.1 依赖治理的三个维度

```
依赖治理
├── 安全维度 — 漏洞修复（npm audit）
├── 版本维度 — 升级策略 & 兼容性管理
└── 体积维度 — 依赖瘦身 & 重复检测
```

### 25.2 安全漏洞修复

```bash
# 审计当前项目依赖
npm audit                  # 查看漏洞列表
npm audit fix              # 自动修复（仅 semver 兼容的补丁版本）
npm audit fix --force      # 强制修复（可能包含 breaking change）

# pnpm
pnpm audit
```

**生产环境的漏洞处理流程：**

```
1. npm audit → 发现高危/严重漏洞
2. 查看是否影响运行时（devDependencies 的漏洞可能无需紧急处理）
3. 尝试 npm audit fix（不破坏项目的前提下自动升级）
4. 如果 fix 失败 → 手动升级单个包 → 跑测试 → 部署
5. 建立定期审计机制（CI 中跑 npm audit --audit-level=high）
```

### 25.3 版本升级策略

| 策略       | 做法                                     | 风险 | 适用场景       |
| ---------- | ---------------------------------------- | ---- | -------------- |
| 激进升级   | 经常升级到最新版                         | 高   | 个人项目       |
| 保守升级   | 只在需要新功能/修复时升级                | 低   | 生产项目       |
| 定期批处理 | 每月/每季度集中升级一次                  | 中   | **推荐**       |
| 工具辅助   | Renovate / Dependabot 自动提 PR          | 中   | 团队协作       |

**Renovate 配置示例：**

```json
// renovate.json
{
  "extends": ["config:base"],
  "schedule": ["before 8am on Monday"],  // 每周一早上自动提 PR
  "packageRules": [
    {
      "matchUpdateTypes": ["patch"],
      "automerge": true                    // patch 自动合并
    },
    {
      "matchDepTypes": ["devDependencies"],
      "automerge": true                    // 开发依赖自动合并
    }
  ]
}
```

### 25.4 依赖瘦身

**① 找出重复/冗余依赖**

```bash
npx depcheck                    # 找出来安装但未使用的包
npx npm-dedupe                  # 去重 npm 依赖树
pnpm dedupe                     # pnpm 去重
```

**② 分析依赖体积**

```bash
# 可视化分析
npx vite-bundle-visualizer      # Vite 项目
npx webpack-bundle-analyzer     # Webpack 项目

# 命令行快速查看
npx cost-of-modules             # 每个包的大小
```

**③ 替代重型依赖**

| 重包        | 轻量替代         | 体积差异       |
| ----------- | ---------------- | -------------- |
| `moment`    | `dayjs`          | 72KB → 2KB     |
| `lodash`    | `lodash-es` + 按需引入 | 全量 70KB → 按需 2-3KB |
| `axios`     | `ky` / `ofetch`  | 13KB → 3KB     |
| `antd`      | 按需引入 + tree-shaking | 视情况定       |

### 25.5 CI 中的依赖质量门禁

```yaml
# GitHub Actions 示例
- name: Dependency Check
  run: |
    npm audit --audit-level=high     # 高危漏洞阻断 CI
    npx depcheck --ignores="eslint,prettier"  # 检查未使用依赖
    npx bundlesize                    # 检查产物大小是否超标
```

---

## 26. dev server proxy 的原理是什么？跨域问题有哪些工程化解决方案？

### 26.1 为什么会有跨域问题

浏览器的**同源策略（Same-Origin Policy）**：协议、域名、端口三者必须完全相同才能自由通信。开发时，Vite dev server 跑在 `localhost:5173`，后端 API 跑在 `localhost:3000`——端口不同，跨域了。

```
开发阶段                              生产阶段
localhost:5173   ──跨域──→  api.example.com    前端域名: app.example.com
(前端)                        (后端)           后端域名: api.example.com
                                               不同子域名也跨域！
```

### 26.2 三种工程化方案

**方案一：dev server proxy（开发环境首选）**

```js
// vite.config.js
export default defineConfig({
  server: {
    proxy: {
      '/api': {
        target: 'http://localhost:3000',
        changeOrigin: true,
        rewrite: (path) => path.replace(/^\/api/, '')
      }
    }
  }
})
```

**原理**：浏览器请求 `localhost:5173/api/users` → Vite dev server 收到 → 转发给 `localhost:3000/users` → 拿到响应 → 返回浏览器。整个过程对浏览器透明，浏览器只和同源的 `localhost:5173` 通信，不存在跨域。

**方案二：CORS（服务端配置）**

```js
// 后端 Express 示例
app.use((req, res, next) => {
  res.header('Access-Control-Allow-Origin', 'https://my-app.com')
  res.header('Access-Control-Allow-Methods', 'GET,POST,PUT,DELETE')
  res.header('Access-Control-Allow-Headers', 'Content-Type,Authorization')
  res.header('Access-Control-Allow-Credentials', 'true')
  next()
})
```

- ✅ 标准方案，任何环境都可用
- ⚠️ 需要后端配合，不能配置 `*` 时还要处理携带 cookie 的场景

**方案三：Nginx 反向代理（生产环境推荐）**

```nginx
server {
  listen 80;
  server_name app.example.com;

  # 前端静态文件
  location / {
    root /var/www/dist;
    try_files $uri /index.html;
  }

  # API 代理到后端
  location /api/ {
    proxy_pass http://api-server:3000/;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
  }
}
```

- ✅ 前端和后端在同一个域名下，完全不存在跨域
- ✅ 生产环境的最佳实践

### 26.3 方案选择指南

| 阶段     | 推荐方案          | 原因                           |
| -------- | ----------------- | ------------------------------ |
| 本地开发 | dev server proxy  | 零配置、即时生效、真实模拟     |
| 生产环境 | Nginx 反向代理    | 同域部署，无跨域，性能好       |
| 跨域 API | CORS + 白名单     | 前后端分开部署时的标准方案     |
| 临时调试 | 浏览器插件关掉 CORS | ⚠️ 仅限本地调试，绝不用于生产 |

---

## 27. 微前端有哪些实现方案？Module Federation 解决了什么问题？

### 27.1 什么是微前端

微前端（Micro Frontends）是把一个大型前端应用**拆分为多个独立的小型应用**，每个小型应用可以由不同团队独立开发、测试、部署。

```
┌─────────────────────────────────────────────┐
│              基座应用（Shell）                │
│  ┌──────────┐ ┌──────────┐ ┌──────────────┐ │
│  │ 子应用 A  │ │ 子应用 B  │ │  子应用 C    │ │
│  │ (React)  │ │ (Vue)    │ │  (Angular)   │ │
│  │ 团队 A   │ │ 团队 B   │ │  团队 C      │ │
│  └──────────┘ └──────────┘ └──────────────┘ │
└─────────────────────────────────────────────┘
```

### 27.2 主流方案对比

| 方案                   | 原理                                       | 技术栈限制 | 学习成本 | 适用场景               |
| ---------------------- | ------------------------------------------ | ---------- | -------- | ---------------------- |
| **qiankun**            | 基于 single-spa，JS 沙箱 + CSS 隔离        | 无限制     | 中       | 遗留系统迁移、多技术栈 |
| **micro-app**          | Web Component + Iframe 思想                | 无限制     | 低       | 快速接入、简单场景     |
| **wujie（无界）**       | Web Component + Iframe + 代理              | 无限制     | 低       | 隔离性要求高的场景     |
| **Module Federation**  | Webpack 5 原生，运行时共享模块              | Webpack 5  | 中高     | 新技术栈、同技术栈     |
| **Emp**                | 基于 Module Federation 的微前端框架         | Webpack 5  | 中       | Module Federation 增强 |

### 27.3 Module Federation 的核心原理

Module Federation 是 Webpack 5 内置的微前端方案，核心思想是**运行时共享模块**：

```js
// 子应用 A（remote） — webpack.config.js
new ModuleFederationPlugin({
  name: 'appA',
  filename: 'remoteEntry.js',
  exposes: {
    './Header': './src/components/Header.vue',  // 暴露组件
    './utils': './src/utils/index.ts'           // 暴露工具函数
  },
  shared: ['vue', 'vue-router']                 // 共享依赖，避免重复加载
})

// 基座应用（host） — webpack.config.js
new ModuleFederationPlugin({
  name: 'host',
  remotes: {
    appA: 'appA@http://localhost:3001/remoteEntry.js'  // 声明远程模块
  }
})

// 基座中使用子应用的组件
import Header from 'appA/Header'  // 就像本地模块一样 import！
```

**关键优势**：

| 对比维度     | qiankun 类方案              | Module Federation            |
| ------------ | --------------------------- | ---------------------------- |
| 依赖加载     | 每个子应用打包完整的依赖    | 共享依赖（如 Vue 只加载一次）|
| 组件共享     | 需要额外封装或全局注册      | 原生 import，类型安全        |
| 构建方式     | 子应用独立构建部署          | 可以独立构建，也可以联合构建 |
| 运行时性能   | 子应用加载有一定开销        | 几乎零开销                   |

### 27.4 微前端的工程化挑战

| 挑战             | 说明                                       | 应对                           |
| ---------------- | ------------------------------------------ | ------------------------------ |
| **CSS 冲突**      | 多个子应用的全局样式互相覆盖               | CSS Modules / Shadow DOM / qiankun 沙箱 |
| **JS 全局污染**   | 子应用修改了 `window.xxx`，影响其他子应用  | JS 沙箱（qiankun 的 Proxy 沙箱）|
| **通信机制**      | 子应用之间需要共享数据和事件                | 全局 EventBus / 基座下发的 props |
| **路由管理**      | 多个子应用的路由需要统一分配和调度          | 基座统一管理 / 各自的子路由     |
| **版本管理**      | 基座和子应用版本如何协调                    | 基座保持向后兼容，子应用可独立升级 |

---

## 28. 前端如何搭建性能与错误监控体系？

### 28.1 监控体系全景

```
前端监控体系
├── 性能监控
│   ├── Core Web Vitals（LCP / FID / CLS）
│   ├── 自定义指标（首屏时间、API 响应时间）
│   └── 资源加载（慢资源、资源失败）
├── 错误监控
│   ├── JS 运行时错误（window.onerror）
│   ├── Promise 未捕获异常（unhandledrejection）
│   ├── 框架错误边界（Vue errorHandler / React ErrorBoundary）
│   └── 接口错误（API 超时、5xx、网络异常）
└── 行为监控（辅助排查）
    ├── 用户操作路径（点击、路由跳转）
    └── 录制回放（Sentry Replay / rrweb）
```

### 28.2 JS 错误捕获的三种方式

```js
// ① 全局运行时错误
window.addEventListener('error', (event) => {
  reportToSentry({
    type: 'js-error',
    message: event.message,
    filename: event.filename,
    lineno: event.lineno,
    colno: event.colno,
    stack: event.error?.stack
  })
})

// ② Promise 未捕获异常
window.addEventListener('unhandledrejection', (event) => {
  reportToSentry({
    type: 'promise-rejection',
    reason: event.reason
  })
})

// ③ 框架级错误边界
// Vue 3
app.config.errorHandler = (err, instance, info) => {
  reportToSentry({
    type: 'vue-error',
    message: err.message,
    stack: err.stack,
    component: instance?.$options?.name,
    info
  })
}
```

### 28.3 性能指标采集

```js
// Core Web Vitals 采集
import { onLCP, onFID, onCLS, onINP, onTTFB } from 'web-vitals'

onLCP(metric => reportMetric('LCP', metric.value))   // Largest Contentful Paint
onFID(metric => reportMetric('FID', metric.value))   // First Input Delay
onCLS(metric => reportMetric('CLS', metric.value))   // Cumulative Layout Shift
onINP(metric => reportMetric('INP', metric.value))   // Interaction to Next Paint

// 自定义首屏时间（Vue 项目）
onMounted(() => {
  nextTick(() => {
    const fmp = performance.now()
    reportMetric('FMP', fmp)
  })
})

// 资源加载监控
const observer = new PerformanceObserver((list) => {
  list.getEntries().forEach(entry => {
    if (entry.duration > 3000) {  // 资源加载超过 3 秒
      reportSlowResource({ name: entry.name, duration: entry.duration })
    }
  })
})
observer.observe({ entryTypes: ['resource'] })
```

### 28.4 常见工具对比

| 工具           | 类型     | 优势                               | 适用场景               |
| -------------- | -------- | ---------------------------------- | ---------------------- |
| **Sentry**     | 自建/云  | 错误聚合 + 堆栈解析 + 源码映射     | **标准选择**，错误监控首选 |
| **阿里 ARMS**  | 云服务   | 性能 + 错误一体化，国内用户友好    | 国内业务、阿里云用户   |
| **腾讯 TAM**   | 云服务   | 免费额度大，与小程序集成好          | 微信生态、小程序       |
| **LogRocket**  | 云服务   | 录制回放，可复现用户操作            | 复杂 Bug 排查          |
| **自建方案**   | 自建     | 可定制、数据安全                   | 隐私敏感场景           |

### 28.5 监控的最佳实践

```
① 错误分级
  - fatal：页面白屏、无法交互 → 立即告警
  - error：功能异常但页面可用 → 记录 + 定时汇总
  - warning：非预期但可降级 → 日志留存

② Source Map 管理
  - 生产环境不发 .map 到 CDN
  - .map 只上传到 Sentry 等监控平台
  - Sentry 会自动根据堆栈找到原始源码位置

③ 采样策略
  - 错误监控：100% 上报（错误不应该漏）
  - 性能监控：10-30% 采样（节省成本）
  - 用户行为：视隐私合规要求决定

④ 告警规则
  - 5 分钟内错误数 > 100 → 紧急通知
  - 核心 API 成功率 < 99% → 警告
  - LCP 超过 4s 的比例 > 20% → 性能预警
```

---