Vue 3.5最大的提升是在SSR渲染上！我认为Vue 3.5最大的提升在于其对SSR渲染的优化。它实现了其他框架尚未做

我认为Vue 3.5最大的提升在于其对SSR渲染的优化。它实现了其他框架尚未做到的Lazy Hydration，并且在开发过程中提供了全面的错误处理。这项工作极其复杂，但Vue 3.5成功地做到了（他自己说的）。

基础概念解释

什么是Hydration？

Hydration是指将已经在服务器端生成并发送到客户端的静态 HTML 页面与客户端的 JavaScript 代码结合起来，使得页面变得可交互。这一步骤通常发生在SSR、SSG页面加载完成后。

Hyration的过程如下：

1. 服务器端渲染：服务器生成 HTML 内容，并将初始状态嵌入到 HTML 中。
2. 发送到客户端：服务器将生成的 HTML 发送到客户端浏览器。
3. 加载 JavaScript：客户端浏览器接收 HTML 并显示页面，同时下载和执行包含应用逻辑的 JavaScript 文件。
4. Hydration：JavaScript 代码运行并将 HTML DOM 转换为可交互的 React/Vue/Angular 组件，保留服务器渲染的内容，而无需重新生成整个页面。

现在三大主流的框架React、Angular、Vue都提供SSR。但是目前（Vue 3.5更新后）出现了第一个Lazy Hydration。（React Lazy Hydration 库不是React官方代码库里的）

为什么要Lazy Hydration？

Lazy Hydration延迟或分阶段执行组件的“水合”过程（将静态HTML转化为动态、可交互的React组件），以减少初始加载时间和资源使用量。

这样操作可以减少javascript的传输体积，并且因为传输到客户端的javascript内容少，很快就能执行完成。

Lazy Hydration 通过延迟javascript操作，减少了初始的 JavaScript 执行量，从而提高了首屏渲染速度。并且通过 Lazy Hydration，可以按需加载和激活组件，避免一次性加载所有的 JavaScript 资源。这有助于减少初始加载时间和带宽消耗。

总的来说，用户在首次访问页面时，不需要等待 JavaScript 的解析和执行，这提高了感知性能。

Hydration的复杂性

Vue在客户端中将HTML和Vue的管理程序结合起来（Hydration过程）的步骤如下：

1. 浏览器渲染HTML，生成真实的DOM
2. javascript程序加载出来，生成Vue管理的VNode。
3. 将Vue的管理逻辑绑定到真实DOM上，即绑定真实DOM和VNode。

VNode（虚拟节点）是虚拟 DOM 的基本单元。虚拟 DOM 是对实际 DOM 的轻量级抽象，用于描述页面结构和状态。

看起来只有三步，实际上Hydration是个十分复杂的过程。（把大象放进冰箱需要几步）

如果你的页面只是一个hello world，那么将javascript的代码和页面DOM结合起来十分的简单。当页面十分复杂，DOM数量很多、组成复杂、操作逻辑复杂的时候就很难将HTML静态页面和Javascript的执行逻辑完美对应起来。

在这个过程中可能出现这个代表Hydration失败的提示：

Error: There was an error while hydrating. Because the error happened outside of a Suspense boundary, the entire root will switch to client rendering.

失败的主要原因是VNode和真实DOM无法对应。导致这种不对应的原因有很多，例如：动态内容（如时间戳、随机数）在服务端和客户端渲染时产生不同结果、使用了客户端特定的逻辑、环境差异等。

当你的页面逻辑足够复杂时这些都是可能导致Hydration失败的。而在正常Hydration都难以控制的基础上，再增加lazy Hydration则更难了。

所以说我认为此次Vue 3.5的SSR渲染进步是巨大的。

Vue 3.5 是如何实现Lazy Hydration的

Vue 3.5中提供的Lazy Hydration接入方式有很多，这里就不再赘述了，感兴趣的可以去看官方文档。

官方团队使用了Intersection Observer来完成lazy的加载。

Intersection Observer根据视口来判定渲染，和传统的API比起来不但性能好，对页面的负担小，有个很大的优点是他不会影响SEO（这是google的爬取说明）。Intersection observer是可以被Google 爬虫所理解的lazy执行方式。

当然在使用的时候还是要注意下兼容性，毕竟是一个比较新的API

在这种情况下保留了SSR在SEO上的优势，同时完成了灵活的lazy Hydration，给用户提供了足够多的策略。

当然官方团队似乎做了失败的兜底，即lazy策略失败返回正常的Hydration，但是正如官方人员所说的，不可能抓取所有的自定义策略的错误，应该是做了常见的失败抓取。

useId()和data-allow-mismatch的引入

useId()是一个 API，可用于生成每个应用程序唯一的 ID，这些 ID 可确保在服务器和客户端渲染过程中保持稳定。

当我看到这个API真的是热泪盈眶，因为我之前的一个项目比较复杂（动态路由+CMS+md转化HTML+SSG页面）总会出现Hydration失败，虽然在生产环境运行没有问题，但是警告逼死强迫症。

而Hydration失败非常难以调试，有时甚至不会影响运行，因此当时并没有深入处理。实际上，我真正需要的是这些用于保持系统稳定性的措施。

因此，在Vue 3.5的开发过程中，开发人员显然考虑到了Hydration失败或问题的情况，并提供了相应的方法来维持系统的稳定性。

除此之外Vue 3.5 中还引入了data-allow-mismatch。

如果客户端值不可避免地与服务器对应值不同（例如日期）我们现在可以使用data-allow-mismatch属性来抑制由此产生的水合不匹配警告

说明Vue的开发团队真的充分考虑到了Hydration的复杂度和种种令人抓狂的问题，提供了多重保险。

为什么说提升是巨大的

以前我在一家大型互联网公司实习的时候，他们的核心前端团队使用的是自研的前端框架，在开发过程中就增加了hydration的优化。

当时这个框架在优化hydration是对组件进行判定，根据组件中是否有交互逻辑来削减代码。对于仅渲染的组件则不进行Hydration的过程，故整体减少了Hydration的量。

自动判定组件是否仅渲染太过于复杂（可能出现组件之间存在交互等多种情况），需要开发人员手动标记是否需要hydration，标记错误会引起功能的异常，心智负担十分的大。

因此，Vue 3.5在SSR优化方面表现得极为强大。此外，它还对各种可能出现的失败情况进行了处理，充分考虑了实际应用中的复杂性和挑战。

希望能够看到个越来越强大的Vue。