日日是好日

数组拍平

Thu, 19 Mar 2026 16:15:12 +0800

背景

为什么要写这篇文章？

核心内容

1️⃣ 概念说明

2️⃣ 使用方式

3️⃣ 实际案例

// 示例代码
console.log('Hello Vite');

SSE

Fri, 13 Mar 2026 16:39:13 +0800

SSE（Server-Sent Events）是一种基于 HTTP 的服务器推送技术，浏览器通过 EventSource 建立长连接，服务器可以持续向客户端发送 text/event-stream 数据流。它是单向通信，适合实时推送场景，例如 AI 流式输出、通知系统、日志流等。

特点：

基于 HTTP

单向通信（Server → Client）

浏览器通过 EventSource API 接收服务器不断推送的数据

连接建立后服务器可以持续发送数据流

优点:

简单易用：SSE提供了一种在服务器和客户端之间建立单向连接的直接方法。客户端订阅了SSE端点，然后服务器可以通过此连接将数据推送到客户端，而不需要客户端不断发送请求
减少网络开销：与持续轮询技术（即每隔几秒钟让每个客户端从服务器请求数据）相比，SSE显著减少了网络开销。
标准化协议：SSE基于HTTP协议，使其易于部署并与现有的web基础设施兼容。

为什么SSE适合AI流式输出

因为服务器可以持续push数据

SSE 为什么比 WebSocket 简单

因为SSE基于 HTTP，不需要协议升级

Promise

Fri, 13 Mar 2026 14:47:52 +0800

Promise 定义

Promise 是 JS 提供的异步解决方案。
内部存在三种状态：pending fulfilled rejected。状态一旦改变不可逆。
Promise 内部维护两个回调队列：onFulfilledCallbacks和onRejectedCallbacks。then 会把回调存入队列。当 resolve 或 reject 时，会执行对应回调。
then 返回新的 Promise，因此可以实现链式调用。

Promise 状态

pending 等待 fulfilled 成功 rejected 失败

状态变化 pending → fulfilled pending → rejected

状态一旦改变就不能再变。【原因:避免竞态条件】

Promise 特点

Promise 最大的特点是 then会返回新的Promise。也就是Promise可以进行链式调用，因此可以解决回调地狱

Promise 本质

Promise的本质是状态 + 回调队列

浏览器事件循环

Thu, 12 Mar 2026 21:13:47 +0800

谨记

JavaScript 在浏览器中是单线程执行的。

但需要注意：

JavaScript 本身是单线程执行的，但浏览器运行环境是多线程的。异步任务由浏览器的其他线程处理，完成后通过 事件循环（Event Loop） 回调到 JS 主线程执行。如果需要真正的并行计算，可以通过 Web Worker 创建新的 JS 线程。

浏览器事件循环是什么

JavaScript 在浏览器中是 单线程执行的，但浏览器需要处理很多异步任务，例如：网络请求、定时器、用户交互事件、DOM 事件。

为了在不阻塞主线程的情况下处理这些异步任务，浏览器引入了 事件循环（Event Loop）机制。

🌟 核心流程：

同步代码进入调用栈 Call Stack 执行
异步任务交给浏览器的 Web APIs 处理（如定时器、网络请求）
异步任务完成后，其回调函数进入 任务队列 Task Queue
Event Loop 持续检测调用栈是否为空如果为空，则把任务队列中的任务放入调用栈执行

为什么需要事件循环

由于 JavaScript 是单线程的：同一时间只能执行一段代码，如果没有事件循环，setTimeout就需要等待对应的time才能继续执行，而这会导致：页面卡死。

因此浏览器设计成 = 单线程 JS + 事件循环调度 + 浏览器异步线程。从而实现：非阻塞异步

浏览器运行 JS 的基本结构

同步代码进入调用栈Call Stack 执行
异步任务交给浏览器的 Web APIs（例如定时器、网络请求）
异步任务完成后，其回调函数会进入任务队列Task Queue
Event Loop 会不断检查调用栈是否为空，如果为空，就把任务队列中的任务放入调用栈执行。

任务队列：宏任务与微任务

任务队列中的任务分为两类：Macro Task（宏任务）和 Micro Task（微任务）

宏任务（Macro Task）

定义： 宏任务是由浏览器调度的任务，每次事件循环会执行 一个宏任务。

常见宏任务：

整个 JS 文件（script）
setTimeout
setInterval
DOM 事件
postMessage
MessageChannel

微任务（Micro Task）

微任务会在 当前宏任务执行结束后立即执行。

常见微任务：

Promise的回调[.then、.catch、.finally]
queueMicrotask
MutationObserver
await 后面的代码会进入微任务队列

浏览器事件循环的执行顺序是

🔥 执行一个宏任务 → 执行所有微任务 → 浏览器进行一次渲染 → 再执行下一个宏任务

也就是说：微任务的优先级高于宏任务

浏览器渲染时机

浏览器通常会在宏任务执行完并清空微任务队列后才进行页面渲染，所以如果微任务不断产生，可能会导致页面渲染被延迟。

常见误区

误区一：同步任务是宏任务，异步任务是微任务 ❌

浏览器调度任务分为宏任务和微任务，从浏览器层面而言，没有同步任务和异步任务的说法。在浏览器层面，同步和异步只是执行方式。同步代码只是 当前宏任务中的执行内容。

误区二：Promise 本身是微任务 ❌ / Promise.then是微任务 ❌

Promise 本身不是微任务。Promise executor 是同步执行，Promise的then、catch、finally的回调才是微任务。

误区三：async是微任务 ❌ / await 是微任务 ❌

这个误区其实和 “Promise 是微任务” 的误区本质类似。 async 本身并不是微任务。async 只是 JavaScript 的一个语法糖，它会让函数返回一个 Promise。 await 也是语法糖，await = 暂停当前 async 函数 + 注册一个 Promise.then。await的后面的代码才是微任务。

误区四：浏览器执行 JS 时，并不是每一行代码都是一个任务。 ❌

整个JS代码块是一个宏任务。

实战

async function async1() {
 console.log(1);
 await async2();
 console.log(2);
}

async function async2() {
 console.log(3);
 await Promise.resolve();
 console.log(4);
}

async1();

console.log(5);

最后输出: 1 3 5 4 2

拆解:

进入 script（一个宏任务）执行 async1()
进入 async1()
执行 console.log(1); 此时输出 1。
执行 await async2();
进入 async2()
执行 console.log(3); 此时输出 3。
执行 await Promise.resolve(); 由于 await = 暂停当前 async 函数 + 注册一个 Promise.then。也就是说 console.log(4); 会被注册成一个微任务。
此时 async2() 被暂停，后续代码 console.log(4); 已经进入微任务队列。
async2() 返回一个 pending 的 Promise。
回到 async1() 中的 await async2(); 由于 async2() 返回的 Promise 还没有 resolve，所以 async1() 也会被暂停。
async1() 后面的 console.log(2); 暂时不会执行，也不会进入微任务队列。
async1() 执行结束（暂停状态），回到 script。
执行 console.log(5); 此时输出 5。
当前 script（宏任务）执行完毕。
Event Loop 开始执行微任务队列。
执行微任务 console.log(4); 此时输出 4。
async2() 执行完成，其返回的 Promise resolve。
async1() 中的 await async2(); 得到结果，于是继续执行 async1() 剩余代码。
console.log(2); 被加入微任务队列。
执行该微任务 console.log(2); 此时输出 2。

JS模块化

Sat, 28 Feb 2026 14:26:13 +0800

模块化

模块化（Module）指把代码拆分成独立、可复用、可维护的单元。每个模块能够：1️⃣ 独立作用域 2️⃣ 明确依赖 3️⃣ 对外暴露接口；目的：防止变量污染、提高代码复用、提升可维护性、支持大型工程

JavaScript 模块化发展历史

阶段1：IIFE

IIFE = 立即执行函数

阶段2：CommonJS

CommonJS 是 Node.js 的模块规范。

特点：

同步加载（Node 可以同步读文件。浏览器不行。）
运行时加载
适合服务器环境
值拷贝（CommonJS 导出是值拷贝）

CommonJS 加载过程： const module = require(’./math’);

阶段3：AMD / CMD

AMD`异步模块定义`(Asynchronous Module Definition)

使用 define 定义模块

使用 require 加载模块

CMD `公共模块定义`(Common Module Definition)

在 CMD 规范中，一个模块就是一个文件。 使用 define 定义模块 使用 SeaJs 的 use 加载模块

UMD`通用模块定义`(Universal Module Definition)

UMD 是 AMD 和 CommonJS 的一个糅合。 AMD 是浏览器优先，异步加载； CommonJS 是服务器优先，同步加载。既然要通用，怎么办呢？那就先判断是否支持 node 的模块，支持就使用 node；再判断是否支持 AMD，支持则使用 AMD 的方式加载。这就是所谓的 UMD。

AMD 和 CMD 的区别

对于依赖的模块，AMD 是提前执行，CMD 是延迟就近执行。 AMD是立即执行，CMD是按需执行。

AMD 推崇依赖前置，CMD 推崇依赖就近。

AMD 的 API 默认是一个当多个用，CMD 的 API 严格区分，推崇职责单一。

阶段4：ES Module

ES6 模块的设计思想是尽量的 静态化，即在编译阶段就确定模块的依赖关系，以及输入和输出的变量。

｜ CommonJS 和 AMD 模块，都只能在运行时确定这些东西。

在 ES6 中，我们使用 export 关键字来导出模块，使用 import 关键字来引入模块。

🔥 优点：Tree Shaking 和编译优化

ESM导出的是值引用。

💡ES6 模块与 CommonJS 模块的差异

｜区别

区别	CommonJS	ESM
加载方式	运行时加载	编译时输出接口
加载方式	同步加载	异步加载，有一个独立的模块依赖的解析阶段。
模块输出	值的拷贝	值的引用
语法	require()	import
适用环境	Node	浏览器+Node
Tree Shaking	不能，因为require是动态执行，编译期无法确定依赖	可以，因为依赖关系可以静态分析

🌼 引申

require和import的区别：require()是运行时加载，import是编译时输出接口。
treeShaking是在哪个阶段做的？
Node 为什么最早用 CommonJS？

因为node读取本地文件是同步的，而CJS同步加载没有问题

module.exports 和 exports 的区别？

闭包

Sat, 28 Feb 2026 14:26:13 +0800

闭包

闭包概念：

闭包是函数在创建时形成的词法作用域绑定关系。
本质是函数对象内部持有对其创建时作用域的引用。
当函数在其定义作用域之外执行时，仍然可以访问当时的变量，这种机制就是闭包。

📍形成闭包的必要条件：

内部函数引用了外部变量
内部函数有没有活到外层函数结束之后
这个内部函数在外部仍然存在

📍 闭包什么时候产生？

函数创建时就产生闭包结构，但只有函数逃逸时才会保留环境。

词法作用域：

词法作用域（Lexical Scope）是指：变量的作用域在代码“写出来”的时候就已经确定了。

词法作用域是指变量的作用域在代码定义阶段就已经确定，由函数的书写位置决定，而不是由调用位置决定。
JavaScript 是词法作用域语言，函数在创建时会记录其外部词法环境，变量查找沿着作用域链向外进行。

经典例子：log打印的是1，而不是2。因为foo被定义在全局作用域，而不是定义在bar的作用域。

let a = 1;

function foo() {
 console.log(a);
}

function bar() {
 let a = 2;
 foo();
}

bar();

AbortController

Fri, 27 Feb 2026 17:17:10 +0800

🔥 如何保证页面最终展示的一定是用户最后点击的那一次请求结果？

在前端开发中，我们经常会遇到这样的问题：用户快速点击多个按钮或者输入搜索关键词，发出了多次网络请求，但是由于网络传输、服务器处理、返回时间等原因，导致响应的顺序和请求的顺序不一定一致。

比如说用户点击了三个商品，顺序为ABC，但是响应的顺序为ACB，此时页面最终呈现的就是B商品的详情，但是按照道理来说，此时应该展示的是C商品。这个就是一个典型的竞态问题：即多个请求并发时，返回顺序不可控，可能导致 UI 被旧请求的响应数据覆盖。

1️⃣ AbortController（取消旧请求）

AbortController 是 JavaScript 中的一个全局类，它可以用来终止任何异步操作。

👉 AbortController是一个Web API，它提供了一个信号对象（AbortSignal），该对象可以用来取消与Fetch API相关的操作。当我们创建AbortController实例时，会自动生成一个与之关联的AbortSignal对象。我们可以将这个AbortSignal对象作为参数传递给fetch函数，从而实现对网络请求的取消控制。

基本思路如下：

为每次请求创建一个 AbortController 实例。 const controller = new AbortController();
通过AbortController实例的signal属性，获取到AbortSignal对象，然后在调用fetch函数时，我们将signal对象作为选项对象的signal属性传递进去。const signal = controller.signal;
每次新请求前，取消上一次未完成的请求。 controller.abort();
只处理最后一次请求的响应，旧请求即使返回也不会影响页面显示。

通过这种方式，无论用户点击多快，页面最终展示的总是最后一次点击的商品详情。

💡 小提示：对于搜索框或者频繁触发的请求，还可以结合防抖（debounce）或节流（throttle），进一步优化性能，减少无效请求。

👉 但是 AbortController 存在兼容性问题

2️⃣ 版本号校验（保证正确性）最稳的方案

思路：每次点击生成一个“请求版本号”。只有最后一次请求才允许更新 UI。

📍 为什么 AbortController 不能完全替代版本号？

因为即使你调用：controller.abort()；也可能会出现以下几种情况

请求已经返回，已经完成的请求调用 abort() 没用（因为 signal 只控制未完成的请求）
fetch 响应返回（resolve），abort 不能阻止 resolve 进入微任务队列
then 已经注册回调，abort 不会移除已注册回调，只能 reject fetch promise

所以：UI 仍然可能被旧数据覆盖，这就是为什么真正稳的方案是：AbortController + 版本号校验

Vite总结

Tue, 20 Jan 2026 17:46:16 +0800

vite 本质

开发阶段利用浏览器原生 ESM 做按需编译，生产阶段基于Rollup做高质量打包。

vite配置文件为什么是vite.config.ts

配置本身就是 ESM
可以使用 TS
区分生产环境和开发环境，可以写逻辑（if / env）

vite请求快的原因

Vite

Wed, 07 Jan 2026 11:33:39 +0800

Vite 介绍

Vite 发音 /viːt/
vite官网: https://cn.vitejs.dev/
vite源码: https://github.com/vitejs/vite

Vite是一个由原生ESM驱动的Web开发构建工具。

在开发环境下基于浏览器原生ESimports开发，在生产环境下基于Rollup打包。

vite是vue作者开发的一款意图取代webpack的工具，其实现原理是利用ES6的import会发送请求去加载文件的特性，拦截这些请求，做一些预编译，省去webpack冗长的打包时间。

Vite 组成

vite主要由两部分组成：一个开发服务器 + 一套构建指令。

一个开发服务器，它基于原生 ES 模块提供了丰富的内建功能，如速度快到惊人的模块热更新（HMR）。
一套构建指令，它使用 Rollup 打包代码，并且是预配置的，可输出用于生产环境的高度优化过的静态资源。

理解：Vite 的开发服务器只在开发环境使用。Vite 的构建（build / Rollup）只在生产环境构建时使用。两者职责清晰、阶段完全不同。

Vite 的精髓就是： 开发阶段基于ESM，不打包，速度更快，生产阶段基于Rollup打包，打包到极致

开发服务器

在开发期间，vite就是一个服务器。开发服务器只在开发阶段使用，本质上是“让浏览器直接跑你的源码”。

✔ 提供本地服务 ✔ 利用浏览器原生 ES Modules ✔ 实时转换源码（TS / JSX / Vue） ✔ HMR（模块热替换） ✔ 不做整体打包

你写的源码 ↓ Vite Dev Server（即时转换） ↓ 浏览器按需请求模块（ESM） 💡 特点：

没有 bundle

改一个文件，只重新加载这一个模块

启动速度 ≈ 0（项目再大也快）

构建指令

本质：把源码变成适合线上部署的静态文件

✔ 使用 Rollup ✔ 真正“打包” ✔ 代码分割、Tree-shaking ✔ 文件 hash ✔ 输出静态资源（dist）

🚧 Diff: Vite vs Webpack

开发环境

Webpack 是在“浏览器不会模块化”的时代诞生的正确方案，【浏览器不支持ESModule和import和export】因此他的世界观是先打包再运行，因此开发服务器启动速度慢。

Vite 是在“浏览器已经会模块化”之后，对构建工具的重构，因此他的世界观是先运行再打包，因此开发服务器启动速度极快。

开发环境对比点	Webpack	Vite
是否打包	✅ 是（内存 bundle）	❌ 否
模块加载	bundle	浏览器原生 ESM
启动时	全量构建依赖图	不扫描全量
改一个文件	重新构建 chunk	精确替换模块
HMR	基于 bundle	基于模块
项目越大	越慢	基本不变

｜在开发环境，Vite 和 Webpack 的主要区别在于是否对代码进行打包。

webpack在启动开发服务器时，会将整个项目模块构建一个依赖图，打包为一个bundle.js文件，然后再运行这个文件。

只是这个打包是内存中的打包（in-memory bundle），不是写到磁盘而已。
vite则是利用浏览器的ES Module Imports特性，不进行预打包，只有在真正需要时才编译文件，按需加载模块。

在启动开发服务器时，Webpack 将整个项目所有模块构建一个依赖图，打包为一个bundle.js文件，然后再运行这个文件。对于大型项目，这个过程可能非常耗时，导致开发者需要等待较长时间才能开始调试代码。
Vite：Vite 利用浏览器的ES Module Imports特性，不进行预打包，只有在真正需要时才编译文件，按需加载模块。
- Vite直接启动了一个开发服务器devServer，然后劫持浏览器的HTTP请求，在后端进行相应的处理将项目中使用的文件通过简单的分解与整合，然后再返回给浏览器(整个过程没有对文件进行打包编译)。所以Vite 的开发服务器启动速度非常快，通常可以在几百毫秒内启动。
- （在生产模式下，vite使用Rollup进行打包，提供更好的tree-shaking，代码压缩和性能优化。）

【对比: Webpack 在开发阶段「本质上也要打包」, 只是这个打包是内存中的打包（in-memory bundle），不是写到磁盘而已。】

为什么 Vite 启动这么快？

因为vite是浏览器直接加载 ESM，不做 bundle，而是按需加载模块，只在请求到某个模块时才编译（on-demand）

vite 的工作原理

启动 dev server
浏览器请求 index.html
浏览器通过加载模块
遇到裸模块（vue / react）→ Vite 转成浏览器可识别路径
按需编译、缓存结果

Vite 中如何区分环境？

import.meta.env.MODE import.meta.env.DEV import.meta.env.PROD

只有 VITE_ 开头的环境变量才会注入到客户端

Vite 如何处理 CSS？

原生支持： CSS / Less / Sass

CSS Module：*.module.css

自动拆分 CSS

开发阶段 style 注入

生产阶段提取成文件

防抖和节流

Sat, 15 Nov 2025 16:16:27 +0800

防抖 = 把一段时间内的多次触发，压缩成“最后一次”

节流 = 给事件加一个“时间闸门”，按固定频率放行

requestAnimationFrame 是以帧为单位的节流

防抖是指在事件触发一段时间后才执行，如果期间再次触发会重新计时；节流是在一段时间内只允许函数执行一次，无论事件触发多少次。防抖关注的是“只执行最后一次”，节流关注的是“限制执行频率”，前者压缩事件，后者采样事件。

为什么 scroll 用节流不用防抖？

scroll 过程中需要持续反馈，防抖只在结束后执行一次，会造成卡顿

为什么“防抖会破坏交互，而节流不会”

判断依据是用户是否关心“过程中的状态变化”。

用户如果不关心过程，就可以用防抖。 防抖适合输入框搜索、表单校验、resize；

用户如果关心过程，就需要用节流。节流适合 scroll、mousemove、拖拽、曝光统计。

requestAnimationFrame

基础概念及相关概念

requestAnimationFrame (简称 rAF) 是以浏览器帧率为单位的节流，由浏览器主导的，保证每一帧最多执行一次，并与渲染同步的 JS 执行钩子。
帧：屏幕被“画”一次
rAF的核心
- 一帧只调用一次，每次屏幕刷新前调用
- 自动节流，tab 不可见时几乎不执行
- 与渲染同步，回调发生在浏览器绘制前
- 时间戳稳定，用于计算动画进度

浏览器一帧里发生了什么？

处理输入事件（click、scroll）
执行 JS
- setTimeout
- Promise
- requestAnimationFrame ← 在这里
样式计算（Recalculate Style）
布局（Layout / Reflow）
绘制（Paint）
合成（Composite）

CSR和SSR

Sun, 20 Jul 2025 16:16:27 +0800

CSR（Client-Side Rendering）: 客户端渲染

服务器主要负责提供静态的HTML文件（可能包含一些基本的HTML结构和JavaScript脚本），而真正的页面渲染工作则完全由客户端的浏览器来完成。这意味着页面内容是在用户的浏览器上动态生成的。

优点：

响应速度快：一旦HTML文件加载完成，浏览器就可以开始渲染页面，而不需要等待服务器返回完整的渲染结果。动态性强：由于页面渲染在客户端进行，因此可以方便地实现各种动态交互效果。前端部署简单：只需要一个静态服务即可部署前端代码，降低了部署成本。

缺点：

首屏加载时间长：由于需要加载整个JavaScript包，可能导致首屏加载时间较长，特别是对于复杂的单页应用（SPA）。不利于SEO：搜索引擎爬虫可能无法很好地解析由JavaScript动态生成的页面内容，导致SEO效果较差。白屏时间：在JavaScript代码加载和执行期间，用户可能会看到空白的页面，即所谓的“白屏时间”。

SSR（Server-Side Rendering）: 服务端渲染

SSR 的流程一定要熟：构建 → 请求 → 服务端渲染 → 注水 → 客户端接管

SSR 是一种在服务器端完成页面渲染的技术。
在SSR下，服务器端接收到客户端的请求后，会根据 客户端请求的数据 以及 模板文件 生成完整的HTML页面。然后将这个完整的HTML页面直接发送给客户端。
这样，用户可以直接看到完成的内容，无需等待JavaScript加载和执行。

SSR 模板文件

👉 SSR 本质上是生成一段 HTML 字符串，然后插入到 SSR 模板文件中。

｜模板文件: SSR 模板 = 静态 HTML 容器 (纯HTML字符串) + 插槽占位

SSR 模板文件不会渲染，而是“接收渲染结果”的容器。

优点： 使用SSR模板文件的好处是无需每次构建整个页面，只需要每次将数据插入到slot中，从而渲染插槽即可。

SSR模板文件 不会被服务端构建器编译（build/compile）
- 构建器（如 Vite、Webpack、Rollup）并不会处理这个 index.html 模板（它可能会被拷贝，但不会编译、分析依赖、生成 bundle）。
SSR模板文件 不会被客户端解析模板语法而渲染（render）
- SSR模板文件不会被像 Vue/React/San 这样的框架渲染，因为浏览器只会看到它已经被替换好的 HTML，根本不会看到插槽占位
SSR模版只是在 node 读取模版时，使用JS 将插槽占位替换成服务端解析客户端获得的数据

与slot的区别:

SSR 插槽 = 等待“某个组件渲染结果”的静态 HTML 占位符
组件插槽 = 等待“其他组件传入内容”的动态子组件插入点

SSR 反解 —— Hydration（注水）机制

🌟 既然SSR是在服务端渲染一个HTML的过程，那么客户端是如何接管运行的呢？如何执行页面上的JS逻辑呢？
这就涉及到 SSR反解，即挂载JS的过程。又称 Hydration（注水）。
SSR 注水时的 JS 逻辑，是浏览器从 HTML 中加载 script 脚本文件后执行的，而注水的入口逻辑就是 JS 应用接管 DOM 的起点。

SSR 的“反解”就是客户端的 Hydration（注水）过程，即将 SSR 渲染好的 HTML，挂上 JS 逻辑，变成真正可交互的应用。

🔥 注水机制的本质是在 已有DOM上挂载JS逻辑。

❌ 这里需要区分CSR。 Hydration 是 SSR 独有的步骤，纯 CSR 是没有 Hydration过程的，因为CSR 不会预先接管HTML，而是自己从 JS 渲染 DOM。

React 的 hydrateRoot()、Vue 的 app.mount()、san的 myComponent.attach(el, { ssr: true }) 都是注水入口。
但是有的时候我们也会在 CSR 项目里看到下面这种代码：
```
const app = createApp(App);
app.mount('#app');
```
但这其实不是注水，这里 #app 是空的，App 是从 0 渲染出来的。只是 API 长得像 SSR 的注水 mount()，但它做的是“创建 DOM”，不是“复用已有 DOM”。
SSR 的 HTML 是“服务器生成的”，DOM是在服务端生成的，Hydration 是“接管”，只需要在 DOM上挂载，而无需重新创建DOM；
在CSR中，服务器返回一份空的 HTML， CSR 的 HTML 是“客户端生成的”，需要直接从 0 开始创建DOM，没有可接管的内容。

注水的作用

注水不是重新渲染，而是对比已有 HTML 和虚拟 DOM，找到匹配点，然后 “在已有 DOM 上挂载 JS 逻辑” ；这样可以省掉客户端从 0 渲染，页面加载速度更快。

注水顺序：

【初始化客户端数据】创建响应式状态或 store 状态【还没有对比DOM结构】
- 执行组件的 initData() 或 data: { … }
- 恢复 Vue 的 data()，React 的 useState()、Redux 状态等
- 或读取 window.INITIAL_DATA 来还原服务端数据
【对比DOM】
- 对比客户端 JS 渲染出来的“虚拟 DOM” 和页面中已经由服务端生成并送到客户端的“真实 DOM” （不一致可能会触发警告或 DOM patch）
- 如果不一致，框架会：
  - 报 warning（如 Vue 的 hydration mismatch）
  - 或直接 patch DOM（丢掉 SSR 性能）
- 🔁 这是为了让“JS 状态”与“页面结构”达成一致。
- ⚠️ 特别注意：不是所有属性都“必须对比”
  - 一些如 data-* 属性、非交互性属性，或者某些 aria-* 辅助属性，框架可能会有容忍度。
  - 但关键属性（如：id、class、key、绑定属性、样式、children 顺序）都必须对比且一致，否则注水可能失败。
【挂载事件监听器】

SSR的优缺点

优点：
- 首屏加载速度快：由于服务器已经生成了完整的HTML页面，因此客户端可以直接显示这个页面，无需等待JavaScript加载和执行。
- SEO友好：搜索引擎爬虫可以很好地解析由服务器生成的HTML页面内容，有利于SEO优化。
- 适合复杂页面：对于包含大量数据、需要复杂计算的页面，SSR可以更好地处理并减少客户端的负载。
缺点：
- 服务器压力大：对于每个请求，服务器都需要重新渲染页面，这可能导致服务器压力过大。
- 开发限制：SSR要求开发者在编写Vue组件时，需要考虑到服务器端和客户端环境的差异，不能过度依赖客户端环境。
- 调试困难：SSR的调试过程相对复杂，需要同时考虑到服务器端和客户端的日志和错误信息。

🚧 Diff 注水 vs 挂载 vs 重新渲染

类型	动作	会创建 DOM？	会挂载事件？	用在哪
SSR	服务器渲染HTML	✅	❌	首屏
Hydration注水	接管 HTML	❌	✅	首屏
CSR 挂载	浏览器全量渲染	✅	✅	二次跳转、非首屏