Web 前端技术演进全景 · 框架版本史与横向对比

从 1990 年第一个网页到 2026 年的信号（Signals）与服务端组件时代——本文档系统梳理前端三十余年的范式变迁、八大主流框架逐版本演进时间轴、各自模块生态详解，以及一份可用于技术选型的横向对比矩阵。

• 36 年 — 1990 — 2026
• 8 大时代 — 范式分期
• 12 个框架 — 逐版本时间轴
• 150+ — 关键版本节点
• 2026-09 — 数据核实时点

阅读约定：时间标注为「稳定版首次发布（GA）」时间；标注 预览 表示 Developer Preview / Beta；EOL 表示官方已停止支持。正文中出现的字面 HTML 标签均已转义，可安全阅读源码。

1 全景时间轴：1990 — 2026

一条主线：把运行时该做的事，尽量挪到编译时和服务端去做。三十余年前端史，就是这条主线不断推进的历史——从拼字符串、到操作 DOM、到虚拟 DOM、到绕过虚拟 DOM、再到把组件直接放到服务端执行。

1.1 一图看懂三十六年

1.2 关键节点速查表

前端史上 40 个关键节点（按时间排序，标 ★ 为范式级转折点）

时间	事件	类别	为什么重要
1990.12	首个网页与浏览器诞生（Tim Berners-Lee）	基础	HTML + HTTP + URL 三件套确立
1993—1996	HTML 1.0 → CSS1 → 早期 DOM	标准	结构、表现、行为开始分离
1995.05	★ JavaScript 发布（Brendan Eich，10 天写成）	语言	浏览器终于有了可编程能力
1996	CSS1 成为 W3C 推荐标准	标准	样式独立成层
1998	DOM Level 1 标准化	标准	JS 操作文档有了统一模型
1999	XMLHttpRequest 随 IE5 引入	能力	异步通信的物理基础
2001	JSON 提出（Douglas Crockford）	数据	取代 XML 成为主流传输格式
2004	Gmail / Google Maps 发布	产品	证明了「浏览器可以做桌面应用」
2005.02	★ AJAX 一词被 Jesse James Garrett 命名	范式	Web 2.0 元年，局部刷新成为常态
2006.08	★ jQuery 发布（John Resig）	库	终结浏览器兼容地狱，统治近十年
2006	Sass 发布	样式	CSS 开始具备编程能力
2008.12	Google Chrome + V8 引擎发布	引擎	JS 性能提升一个数量级，催生 Node
2009.03	★ Node.js 发布（Ryan Dahl）	运行时	JS 走出浏览器，前端工程化成为可能
2010	npm 发布	基建	包管理成为生态分发中枢
2010.07—10	Knockout、Backbone、AngularJS 相继发布	框架	MV* 时代开启，前端有了架构
2011	Bootstrap、Ember.js 发布；Browserify 出现	生态	UI 组件化与模块化打包起步
2012.10	TypeScript 发布（Microsoft）	语言	大型前端项目的类型化基础
2012—2013	★ Grunt / Gulp / Webpack 出现	工程	构建从「手工拼接」变为「依赖图打包」
2013.05	★ React 开源（JSConf US）	框架	虚拟 DOM + 单向数据流 + 组件化
2014.02	Vue.js 首次公开	框架	渐进式框架的起点
2015	ES6 / ES2015 定稿；Redux 发布；React Native 开源	标准+生态	现代 JS 语法基础 + 状态管理 + 跨端
2015	Rollup 发布（Tree Shaking / Scope Hoisting）	工程	库打包进入 ESM 时代
2016.09—10	Angular 2 正式发布；Vue 2.0 发布；Next.js 发布	框架	三大框架格局形成，元框架登场
2017.09	React 16（Fiber 架构）	框架	可中断渲染，并发特性的地基
2018	Vue CLI 3；Angular 6/7；Flutter 1.0	生态	脚手架标准化，跨端竞争加剧
2019.02	React 16.8 Hooks 稳定	框架	函数组件成为主流，类组件退场
2019.05	Angular 8 引入 Ivy 预览；Tailwind CSS 发布	框架+样式	渲染引擎换代 + 原子化 CSS 兴起
2020.09	★ Vue 3.0（Proxy 响应式 + Composition API）	框架	响应式系统与逻辑复用范式重构
2020	★ Vite 发布；esbuild / Snowpack 兴起	工程	开发态不再打包，原生 ESM 直出
2021	Pinia 成为 Vue 官方推荐；SvelteKit 发布	生态	状态管理换代，编译型框架补齐元框架
2022.03	React 18（并发渲染 + Suspense SSR）	框架	并发特性正式落地
2022—2023	Signals 复兴：Solid、Preact Signals、Angular 16 Signals 预览	范式	细粒度响应式成为跨框架共识
2023.11	Angular 17（独立组件默认 + 内置控制流）	框架	Angular 现代化的转折点
2024.09—12	Vue 3.5、Svelte 5 GA（Runes）、★ React 19（Actions + RSC）	框架	服务端组件与显式响应式同时到来
2025.05—11	Angular 20/21（Zoneless 默认）、Next.js 16（Turbopack + Cache Components）、Qwik 2	框架	去 Zone.js、去 Babel、可恢复性落地
2025.12	React2Shell 漏洞（CVE-2025-55182，CVSS 10.0）	安全	RSC 时代的安全面扩大，推动框架安全流程化
2026.02	★ React Foundation 成立（隶属 Linux 基金会）	治理	React 脱离 Meta 单一治理
2026.03—06	Vite 8（Rolldown 统一内核）、Rspack 2.0、Angular 22	工程+框架	Rust 工具链成为主流，Signals 全面稳定
2026.07	★ Vue 3.6：Vapor Mode 生产可用，虚拟 DOM 成为可选项	框架	主流框架正式拥抱「编译到原生 DOM」
2026	AI 编码代理成为一等用户：框架内置 MCP / Agent Skills	范式	工具链开始为 AI 而非仅为人设计

一句话总结三十六年：1990s 拼字符串 → 2000s 操作 DOM → 2010s 虚拟 DOM 与组件化 → 2020s 把工作前移到编译期与服务端。每一代都不是被「淘汰」，而是被「下放」到更小的适用场景里。

2 八大时代：每个时代解决了什么，又败在哪里

理解演进的关键不是记住版本号，而是理解每一代技术在什么复杂度下失效。下面按时代拆分，给出「技术特征 → 代表技术 → 致命缺陷 → 继承者」四段式。

时代一 · 静态页面与服务端模板（1990—2004）

技术特征：浏览器只是文档渲染器。服务端用 CGI / ASP / PHP / JSP / Servlet 拼接 HTML 字符串，浏览器整页刷新。JavaScript 只做表单校验、弹窗、跑马灯这类边缘交互。

HTML 1.0→4.01 · CSS 1/2 · DOM Level 1 · PHP 3/4 · ASP / JSP · Perl CGI

致命缺陷：任何一次数据变更都要整页回传；用户体验割裂；服务端承担全部渲染压力；IE 与 Netscape 的 API 差异让 JS 写起来像在猜谜。

继承者：XMLHttpRequest + Gmail 模式（AJAX）。

时代二 · AJAX 与 jQuery 王朝（2005—2012）

技术特征：XMLHttpRequest 让页面可以局部刷新，Web 应用形态诞生。jQuery 用统一的链式 API 抹平浏览器差异，并提供选择器、事件、动画、AJAX 四件套。同期 Prototype、MooTools、YUI、Dojo 竞争，最终 jQuery 胜出。

jQuery 1.0（2006.08） · JSON 普及 · Sass（2006） · Chrome/V8（2008） · Node.js（2009） · npm（2010） · Bootstrap（2011）

致命缺陷：jQuery 只是「DOM 操作的语法糖」，不提供状态与视图的关系模型。应用一大，必然出现「上千个选择器 + 交织的事件回调」——状态散落在 DOM 属性、全局变量、隐藏字段里，改一处要手动同步 N 处，即所谓「面条代码」。

继承者：MV* 框架（Backbone / Knockout / AngularJS）引入数据绑定与结构约定。

时代三 · MV* 群雄割据（2010—2015）

技术特征：前端第一次有了「架构」概念。三种路线并行：Backbone（MVP，最小结构，靠事件手动同步）、Knockout（MVVM，observable + 双向绑定）、AngularJS（MVC + 双向绑定 + 依赖注入 + 指令，最完整也最重）。同期 Ember 走「约定优于配置」。

Backbone 2010.10 · Knockout 2010.07 · AngularJS 2010.10 · Ember 2011 · Meteor 2012 · Marionette

致命缺陷：双向绑定 + 脏检查在大列表下性能塌陷。AngularJS 的 $digest 循环需要反复遍历全部 watcher 直到稳定，watcher 过两千就明显卡顿；调试时不知道「谁改了谁」；SEO 与首屏仍是难题。

继承者：React 的单向数据流 + 虚拟 DOM，以及后来的 Vue。

时代四 · 组件化与虚拟 DOM 革命（2013—2016）

技术特征：React 提出两个核心命题——UI 是状态的函数（UI = f(state)）与虚拟 DOM。开发者只描述「目标 UI 长什么样」，框架负责计算最小 DOM 变更。JSX 让「结构 + 逻辑」同处一文件，组件成为复用单元。Vue 2 引入虚拟 DOM 与单文件组件（SFC），Angular 2 用 TypeScript 彻底重写。

React 0.3（2013.05） · Vue 0.8（2014.01） · Angular 2（2016.09） · Redux（2015） · Vue 2（2016.09） · Next.js（2016.10） · Webpack 1（2014）

里程碑意义：这是现代前端的「范式确立期」。之后十年所有框架的争论（Hooks vs Composition API、类 vs 函数、可变 vs 不可变），都在这个范式内部进行。

遗留问题：虚拟 DOM 需要运行时 diff 开销；SPA 首屏白屏与 SEO；状态管理样板代码爆炸。

时代五 · 工程化大爆发与元框架崛起（2016—2020）

技术特征：框架本身趋于稳定，战场转移到周边工程化。TypeScript 成为默认、Webpack 配置成为一门手艺、Babel 处理语法降级、ESLint/Prettier 统一风格、Jest/Cypress 补齐测试。元框架（Next.js、Nuxt、Gatsby、Sapper）用 SSR/SSG 解决 SPA 的首屏与 SEO。

React 16 Fiber（2017） · Hooks（2019.02） · Angular Ivy（2019 预览 / 2020 默认） · Vue CLI 3（2018） · Nuxt（2016→2.x） · Gatsby 2 · Flutter（2018）

致命缺陷：工具链复杂度失控——一个中台项目动辄 200MB 依赖、冷启动 3 分钟、「配置工程师」成为岗位。开发体验成为新的瓶颈。

继承者：以 Vite 为代表的原生 ESM + Go/Rust 原生工具链。

时代六 · 原生速度工具链与编译型框架（2020—2023）

技术特征：两条并行的「减法」路线。其一是构建提速：esbuild（Go）证明瓶颈在于实现语言而非算法，Vite 干脆在开发态不打包；其二是运行时瘦身：Svelte 把组件编译为命令式 DOM 操作代码，Solid 用细粒度信号直接更新节点，二者都没有虚拟 DOM。

Vite 1/2（2020—2021） · esbuild（2020） · Vue 3（2020.09） · Svelte 3（2019）/ SvelteKit（2021） · Solid 1.0（2021） · Astro（2021） · Qwik（2022） · Vite 4/5

核心命题：既然模板是静态可知的，为什么还要在运行时构造虚拟 DOM 树再 diff？答案是：不需要。这直接催生了 2026 年 Vue 的 Vapor Mode。

时代七 · 服务端优先与 Signals 共识（2023—2025）

技术特征：两股力量合流。Signals（信号）成为跨框架共识——Angular 16 引入 Signals、Preact 推出 Signals、Solid 一直是信号模型、Vue 3.6 用 alien-signals 重写响应式内核、TC39 也在推进 Signals 标准化提案。服务端优先则是另一股力量：React Server Components 让组件默认在服务端执行，只把交互部分下发到客户端。

Angular 16 Signals 预览（2023.05） · Next.js 13→15 App Router · React 19（2024.12） · Svelte 5 Runes（2024.10） · Angular 19/20 Zoneless · Nuxt 3→4 · Astro 5 Server Islands

副作用：服务端边界带来了新的安全面。2025 年 11—12 月，React Server Components 连续曝出 CVE-2025-55182（CVSS 10.0 远程代码执行）、CVE-2025-55184/67779（DoS）与 CVE-2025-55183（源码泄露），修复版本为 19.0.1 / 19.1.2 / 19.2.1 及后续补丁——这是「能力上移服务端」必须支付的代价。

时代八 · AI 原生与工具链 Rust 化收敛（2026—）

技术特征：三个确定性趋势。①构建内核统一到 Rust：Vite 8 以 Rolldown 作为统一打包内核替代「esbuild + Rollup」双引擎，Rolldown 1.0 于 2026 年 5 月稳定，Rspack 2.0 于 2026 年 4 月发布。②框架主动适配 AI 代理：Next.js 将浏览器日志转发到终端、提供 MCP 集成与 Agent DevTools；Angular 22 的 MCP 工具链进入稳定；生态重心正从 MCP 转向 Agent Skills。③去中心化治理：React 于 2026 年 2 月 24 日正式归入 Linux 基金会下的 React Foundation，Qwik 2 从 Builder.io 转向独立社区治理。

Vite 8（2026.03） · Rolldown 1.0（2026.05） · Rspack 2.0（2026.04） · Angular 22（2026.06） · Vue 3.6 Vapor（2026.07） · Next.js 16.3（2026.08） · TS 7.0 Go 编译器

尚未定型：AI 生成代码对框架 API 设计的影响才刚开始；Remix 3 已宣布脱离 React、转向 Web 平台微包 + 命令式 this.update()，主张「为 LLM 时代减负」——这是一个值得关注但尚未验证的方向。

3 框架族谱：三条技术路线的分化

今天所有主流框架都可以归入三条路线。理解了路线差异，版本演进的细节就有了坐标系。

3.1 三条路线的取舍速览

路线对比（2026 年视角）

维度	虚拟 DOM 派	编译型 / 信号派	服务端优先 / 岛屿派
代表	React 19、Vue 3（传统模式）、Preact	Svelte 5、Solid、Vue 3.6 Vapor Mode	RSC / Next.js 16、Astro 5、Qwik 2
更新粒度	组件级重渲染 + diff	DOM 节点级精确更新	取决于岛屿内所用框架
首屏 JS	较大（需下发运行时）	小（无运行时或极薄）	极小（理论接近 0，Qwik 实测 2—4KB）
心智负担	中（需理解 memo / 依赖数组，Compiler 后可省）	低—中（依赖自动追踪，但需理解信号边界）	高（服务端/客户端边界、序列化规则）
生态成熟度	最高	中（Svelte 上升快，Solid 仍小众）	取决于基座框架（Next 高，Qwik 低）
典型适用	复杂交互应用、需要大量现成组件	性能敏感、体积敏感、嵌入式组件	内容站、电商、营销页、SEO 敏感
2026 状态	仍是主流，靠 Compiler 自动优化补足	Vue 官方下场，路线被主流认可	内容站已成默认，应用端仍在探索

重要澄清：三条路线并非互斥。2026 年的现实是「组合使用」——Next.js 16 用 RSC 做服务端、客户端岛屿里跑 React；Astro 5 默认零 JS、岛屿里可以放 Svelte 或 Solid；Vue 3.6 允许同一应用中 Vapor 组件与传统组件混用。路线之争已经从「选哪条」变成「在哪里用哪条」。

4 jQuery 与 MV* 先驱：jQuery / Backbone / Knockout / Ember

这一代已经退出新项目舞台，但它们是理解现代框架的钥匙——Redux 的单向数据流是对 Backbone 事件链的反思，Vue 的响应式是 Knockout observable 的进化，Angular 的依赖注入继承自 AngularJS。

4.1 jQuery：统治近十年的 DOM 抽象层

作者 / 首次发布

John Resig，2006 年 8 月 26 日发布 1.0

核心理念

Write less, do more —— 用选择器选中元素，然后链式调用操作它

历史地位

终结浏览器兼容地狱；贡献了链式调用、事件委托、Deferred/Promise 三大模式

当前状态

维护中但仅安全与兼容修复；新项目不再推荐，存量站点依然海量

版本演进时间轴

• 2006.08 · 1.0 — 首个稳定版。选择器 + 事件 + 动画 + AJAX 四件套确立，链式 API 成型。

• 2007.01 / 09 · 1.1 / 1.2 — 事件系统重写、选择器性能大幅提升，插件生态开始爆发。

• 2009.01 · 1.3 —— Sizzle 引擎 — 引入独立选择器引擎 Sizzle，支持复杂 CSS3 选择器；live() 事件委托登场，为动态列表提供方案。

• 2010.01 · 1.4 — 大量 API 增强与性能改进，jQuery.Deferred 雏形出现，异步编程开始有范式。

• 2011.01 · 1.5 —— Deferred 重写 AJAX — $.ajax() 全面重构为 Deferred 对象，成为后来 Promise 标准化的重要实践来源。

• 2011.11 · 1.7 —— 统一事件 API — on() / off() 取代 bind/live/delegate，成为事件绑定的唯一推荐写法，至今仍是 jQuery 代码的标准形态。

• 2013.04 · 2.0 —— 砍掉旧 IE — 放弃 IE 6/7/8 支持，体积更小、性能更好。1.x 分支继续为旧浏览器提供兼容，形成「1.x 兼容 / 2.x 现代」双线。

• 2013.01 · 1.9 —— 清理包袱 — 移除 $.browser 等废弃 API，引入 $.migrate 插件辅助平滑升级。

• 2016.06 · 3.0 —— Promise/A+ 合规 — Deferred 兼容 Promise/A+ 规范，可与原生 Promise 互操作；动画改用 requestAnimationFrame；$.Deferred 异常行为修正。3.x 统一了 1.x/2.x 双线。

• 2017—2020 · 3.2 / 3.3 / 3.4 / 3.5 — 持续安全加固：3.5 修复 HTML 预加载导致的 XSS 风险；逐步去除对老旧环境的特殊处理。

• 2021—2023 · 3.6 / 3.7 — 当前维护线。3.7（2023.05）聚焦错误修复与浏览器兼容，无新特性，标志 jQuery 进入「长期维护」阶段。

模块组成（jQuery 核心分包）

jQuery 源码按功能模块划分（可用自定义构建裁剪）

模块	职责	代表性 API
Core	核心对象构造、工具入口、版本与冲突处理	jQuery() / $() · noConflict() · each() · extend()
Selector（Sizzle）	独立 CSS 选择器引擎，可被单独抽取复用	find() · filter() · not() · :visible 等伪类
Attributes	属性与 property 的统一读写	attr() · prop() · val() · removeAttr()
CSS	样式读写、类名操作、尺寸计算	css() · addClass() · width() · innerHeight()
Dimensions / Offset	元素与视口的位置计算，处理滚动与盒模型差异	offset() · position() · scrollTop()
Manipulation	DOM 增删改与移动，含 HTML 字符串解析	append() · before() · html() · wrap() · clone()
Traversing	在 DOM 树上下游走	parent() · children() · siblings() · closest()
Events	跨浏览器事件绑定、委托、命名空间与自定义事件	on() · off() · trigger() · one() · proxy()
Effects	动画队列与缓动	animate() · fadeIn() · show() · stop() · queue()
Ajax	封装 XMLHttpRequest，含 JSONP、预过滤器与转换器	$.ajax() · $.get() · $.post() · $.getJSON()
Deferred / Callbacks	异步流程控制，Promise/A+ 兼容（3.0+）	$.Deferred() · $.when() · $.Callbacks()
Data / Queue	把数据挂到元素上（避免内存泄漏）、任务队列	data() · removeData() · queue() · dequeue()
Utilities	通用工具函数	$.trim() · $.isArray() · $.param() · $.parseJSON()
jQuery UI独立项目	交互行为 + 部件（Widget）工厂 + 主题系统	draggable · dialog · datepicker · sortable · Widget Factory
jQuery Mobile已停更	早期移动端 UI 框架，后被响应式 + 原生框架取代	pages · listview · touch events

为什么 jQuery 会被取代：它没有回答「状态变了，界面该怎么跟着变」。开发者必须手动 $('#count').text(count) 同步每一处，一旦状态与 DOM 的映射关系变多，同步逻辑就会失控。现代框架用「声明式渲染」把这件事交给框架，这正是它们存在的理由。

4.2 Backbone.js：最小结构化的第一次尝试

作者 / 首次发布

Jeremy Ashkenas（Underscore/CoffeeScript 作者），2010 年 10 月

核心理念

只提供最小骨架（Model / Collection / View / Router），其余自由发挥

依赖

硬依赖 Underscore.js；可选依赖 jQuery（用于 View 的 DOM 操作与 AJAX）

历史意义

第一次让前端有了「模型—视图—同步」的分层，直接启发了后续所有框架的数据流设计

当前状态

事实停更（1.6.x 之后无实质更新），仅存量项目使用

Backbone 模块构成

模块	职责	说明
Events	自定义事件混入（mixin）	可混入任意对象，提供 on/off/trigger/listenTo；listenTo 解决「忘记解绑」的内存泄漏
Model	数据实体 + 属性变更事件	get/set 强制走访问器（不能直接改属性），变更时触发 change
Collection	有序模型集合	内置排序、过滤、批量操作与集合级事件
View	DOM 与模型的胶水层	约定 el / render() / events 哈希；不含模板引擎与数据绑定，需手动 render
Router + History	基于 hash 或 pushState 的前端路由	SPA 路由的早期标准形态
Sync	RESTful 持久化抽象	把 save/fetch/destroy 映射为 POST/GET/DELETE，可整体替换为 localStorage 适配器

致命短板：View 层完全靠手写 render() 与事件监听，代码量随组件数量线性膨胀，社区因此诞生了 Marionette、Chaplin 等补充框架——这本身就说明 Backbone 抽象不足。

4.3 Knockout.js：MVVM 与 observable 的先行者

作者 / 首次发布

Steve Sanderson（Microsoft），2010 年 7 月

核心理念

MVVM + 声明式绑定 + 依赖自动追踪

关键贡献

ko.observable() / ko.computed() 的自动依赖收集，是今天所有 Signals 实现的直接祖先

当前状态

维护中但基本停止演进（3.5.x），存量企业系统使用

核心模块

• observable：包装原始值为可观察对象，读写都走函数调用
• observableArray：数组版 observable，跟踪增删改
• computed / pureComputed：自动收集依赖并缓存，依赖变更才重算
• Binding Handlers：text / value / foreach / if / visible / click 等 DOM 指令
• Template Binding：内建模板引擎，可做条件与循环渲染
• Components：3.2+ 引入自定义元素与组件化（对标后来的 Web Components）

为什么没赢

• API 繁琐：所有读写都要加括号 count() / count(1)
• 依赖追踪靠运行时黑魔法，调试困难
• 没有组件级别的编译优化，大列表性能一般
• 被 AngularJS 的完整方案与后来 Vue 的优雅 API 双向挤压

4.4 Ember.js：约定优于配置的工程化先驱

起源

源自 SproutCore 2.0，2011 年 12 月更名 Ember.js（Yehuda Katz、Tom Dale 主导）

核心理念

约定优于配置、完整的官方全家桶、向后兼容性承诺极强

关键创新

Glimmer 渲染引擎（2017 起）、稳定的六周发布节奏、Ember CLI 与 Ember Data

现状

小众但稳定；2025 年完成了构建系统向 Vite 的迁移，说明老牌框架仍在现代化

• 2011 · SproutCore 2.0 → Ember.js — 从 Apple 的 SproutCore 分叉，主打「给野心勃勃的 Web 应用」的完整框架。
• 2013.08 · Ember 1.0 — API 冻结，建立著名的「不破坏升级」承诺与 RFC 驱动的演进流程。
• 2015.08 · Ember 2.0 — 移除 Views，全面转向组件化；引入 Glimmer 渲染引擎雏形，性能大幅改善。
• 2017 · Glimmer VM — 引入字节码级别的渲染虚拟机，把模板编译成可增量更新的操作码，是当时最激进的编译优化。
• 2018.02 · Ember 3.0 — 移除大量废弃 API，引入模块化的新 API 命名空间，明确以 Editions（版本集）方式推进。
• 2019.12 · Octane（3.13+） — 现代 Ember 的分水岭：原生类语法、Glimmer 组件、tracked 属性（@tracked 细粒度追踪），开发体验焕然一新。
• 2021—2023 · 4.x / 5.x — 持续精简：移除 jQuery 依赖、默认严格模式、Embroider 新构建体系推进。
• 2024—2025 · 6.x — 构建层完成向 Vite 的迁移，与主流工具链并轨；Ember 成为「老牌框架和平现代化」的样本。

Ember 全家桶模块

模块	职责
Ember CLI	脚手架与构建，现代前端 CLI 的早期范本（ng-cli / vue-cli 都受其影响）
Ember Router	嵌套路由，URL 与组件树严格对应，是其最强设计之一
Ember Data	官方 ORM 式数据层：Model / Adapter / Serializer / Store / Identity Map
Glimmer	渲染引擎与组件模型，模板编译为增量更新的字节码
Ember Octane 语法	@tracked / @glimmer/component / 装饰器体系
Ember Inspector	浏览器调试扩展，组件树与数据检查
Embroider	新一代构建系统，基于 Webpack/Vite 的标准打包模型

Ember 的真正遗产：它证明了「框架提供官方全家桶 + 严格向后兼容 + RFC 驱动演进」这条路可行。今天 Angular 的发布节奏、Vue 的 RFC 流程、Next.js 的渐进式迁移策略，都能看到 Ember 的影子。

5 Angular：从脏检查到无 Zone 的信号时代（2010 — 2026）

Angular 是唯一经历了「彻底重写」的主流框架：2010 年的 AngularJS（JavaScript + 脏检查）与 2016 年的 Angular 2+（TypeScript + 组件）是代码库完全不同、仅共享名字的两个框架。2026 年的 Angular 22 完成了第二次「内部重写」——用 Signals 取代 Zone.js 驱动的变更检测。

5.1 AngularJS（1.x）：成也双向绑定，败也双向绑定

作者

Miško Hevery 与 Adam Abrons；2010 年 10 月发布，后由 Google 接手

核心理念

用 HTML 扩展（指令）描述应用，双向数据绑定 + 依赖注入

EOL

2021 年 12 月 31 日停止支持（商业第三方延长支持服务存在）

AngularJS 1.x 关键版本

版本	时间	要点
1.0.0	2012.06	首个稳定版，双向绑定、指令、依赖注入、路由、表单校验确立
1.2.x	2013.11	引入 ngRepeat 的 track by、动画钩子、控制器 as 语法
1.3.x	2014.10	一次性绑定 :: 缓解 digest 压力；表单 API 增强；移除 IE8 支持
1.4.x	2015.05	路由器重构、动画模块独立、大量内部重构
1.5.x	2016.02	引入 component() 与单向绑定 <，为向 Angular 2 迁移铺路；生命周期钩子
1.6.x	2016.12	默认禁用 $http 的 JSONP 回调检查；继承 ngModelOptions 改进
1.7.x	2018.07	主要为安全修复与升级友好度改进
1.8.x	2020.06	最终主线版本，官方明确「仅作为迁移过渡」

AngularJS 核心模块

• Scope / $digest：双向绑定的心脏，脏检查循环
• Directive：自定义 HTML 标签与属性，指令优先级与 transclude
• 依赖注入：$injector，按参数名推断（后被压缩破坏，需显式注解）
• Service / Factory / Provider：三类不同的可注入定义方式
• Filter：模板内数据格式化
• $http / $resource：HTTP 与 REST 抽象
• ngRoute / ui-router：路由（后者为社区事实标准，支持嵌套视图）
• $q：Promise 实现

为什么必须重写

• 脏检查不可扩展：watcher 数量上千后 digest 循环明显卡顿
• Scope 继承是陷阱：原型链继承导致赋值覆盖问题，催生「always use a dot」教条
• 变更来源不可知：任何异步回调都可能触发全量检查，无法做精确优化
• 不支持服务端渲染与移动端：这套模型无法被静态化或预编译
• TypeScript 浪潮：2015 年后大型项目全面转向类型化，JS 版难以承接

5.2 Angular 2 — 22：十六年、二十一个大版本

Angular 采用严格的时间驱动发布：2016—2025 年间约每 6 个月一个大版本（在 v21 之前），每个大版本提供 18 个月支持（6 个月活跃 + 12 个月 LTS）。自 Angular 22（2026.06.03）起改为 12 个月一个大版本，每个版本获得约 24 个月支持。发布节奏固定、向后兼容、ng update 自动迁移，是 Angular 对企业用户最核心的承诺——但也意味着升级必须逐个大版本依次进行，不可跳版。

Angular 2 — 22 完整版本表（含支持状态，截至 2026 年 9 月）

版本	发布时间	支持状态	标志性变化
Angular 2	2016.09.14	EOL	彻底重写：TypeScript 优先、组件化架构、新渲染管线。因破坏性过大引发巨大争议
Angular 4	2017.03.23	EOL	跳过 v3（版本号对齐路由包）；AOT 编译改进、体积减小；4.3 引入 HttpClient（基于拦截器的现代 HTTP 客户端）
Angular 5	2017.11.01	EOL	Build Optimizer、PWA 支持、Material 改进
Angular 6	2018.05.04	EOL	ng update / ng add 登场，CLI Workspaces 多项目管理；Angular Elements（Web Components）实验
Angular 7	2018.10.18	EOL	CDK 虚拟滚动与拖拽、CLI 交互式提示、Bundle Budget
Angular 8	2019.05.28	EOL	差分加载（differential loading）、路由动态 import 懒加载、Web Worker；Ivy 渲染引擎可选预览
Angular 9	2020.02.06	EOL	Ivy 成为默认编译与渲染引擎：包更小、构建更快、调试更友好
Angular 10	2020.06.24	EOL	生态打磨：Material 日期范围选择器、更严格的 TS 配置
Angular 11	2020.11.11	EOL	Webpack 5 实验支持、HMR 改进、字体自动内联
Angular 12	2021.05.12	EOL	弃用 IE11 支持，为现代浏览器特性让路
Angular 13	2021.11.04	EOL	彻底移除 View Engine 渲染器，Ivy 成为唯一引擎；动态组件创建 API 简化
Angular 14	2022.06.02	EOL	Standalone Components 开发者预览（不再强制 NgModule）、严格类型化表单、CDK 新原语
Angular 15	2022.11.18	EOL	Standalone API 转稳定、Directive Composition API（指令组合）、NgOptimizedImage
Angular 16	2023.05.03	EOL	Signals 开发者预览（signal / computed / effect）、非破坏性 hydration、esbuild 开发构建；移除 ngcc
Angular 17	2023.11.08	EOL	现代化转折点：Standalone 成为 CLI 默认、内置控制流 @if/@for/@switch、@defer 延迟加载、新文档站、@angular/ssr 包
Angular 18	2024.05.22	EOL	实验性 Zoneless 变更检测、SSR 改进、TS 5.4；HttpClientModule 弃用
Angular 19	2024.11.19	EOL 2026.05	指令/组件/管道默认 standalone；linkedSignal 与 resource() 异步 API；增量 hydration
Angular 20	2025.05.28	LTS 至 2026.11.28	effect() / linkedSignal() / toSignal() 转稳定；Zoneless 在 20.2（2025.08.20）转稳定；httpResource()；CLI 默认不再生成组件后缀
Angular 21	2025.11.19	LTS 至 2027.06	新项目默认不带 zone.js；Signal Forms 实验性；Vitest 成为默认测试运行器；Angular Aria 开发者预览（首个 12 个月周期前的大版本）
Angular 22	2026.06.03	Active	Signal Forms、Angular ARIA、异步响应 API（resource() 系列）全部转稳定；OnPush 成为新组件默认；MCP 工具链稳定；新增 @Service 装饰器与异步依赖注入；Webpack 构建器弃用

升级红线：ng update 仅支持一次跨越一个大版本。从 19 升到 22 必须依次执行 19→20→21→22 三次升级，每次验证并提交。Angular 19 及更早版本自 2026 年 5 月起已停止安全补丁，仍停留在这些版本的项目应视为安全义务尽快升级。

5.3 Angular 的响应式模型演进（四代）

• 2010—2016 · 第一代：脏检查（AngularJS） — $digest 循环反复遍历所有 watcher 直至值稳定，最坏情况需要多轮全量遍历。复杂度与 watcher 数量成正比。
• 2016—2022 · 第二代：Zone.js + 自上而下检查 — Zone.js 通过 monkey-patch 全部浏览器异步 API（setTimeout、事件、XHR、Promise）来「感知可能的变更」，然后从根组件向下检查整棵组件树。配合 OnPush 策略可剪枝。问题是：Zone 本身有体积与性能成本，且补丁行为难以预测。
• 2023—2025 · 第三代：Signals 细粒度响应式（v16 预览 → v20 稳定） — signal() 知道哪些模板位置读取了它，更新时只重绘相关绑定，无需遍历组件树。computed() 惰性缓存、effect() 处理副作用、linkedSignal() 处理「可重置的派生状态」。
• 2025—2026 · 第四代：Zoneless（v20.2 稳定 → v21 默认 → v22 全面） — 移除 zone.js 依赖，变更通知变为显式：信号被读/写、输入被设置、事件处理器触发时直接标记脏。收益：包体积下降、错误更可预测、与原生浏览器 API（含 async/await）无冲突代价。

5.4 Angular 模块（Package）全景

Angular 是「开箱即用的平台」而非库——路由、表单、HTTP、测试、CLI 全部官方提供且版本同步，这是它与 React 最本质的区别。

@angular/ 官方包职责详解*

包	定位	核心内容与关键 API
@angular/core	内核（必选）	组件/指令/管道装饰器、依赖注入容器、Signals（signal/computed/effect/linkedSignal/resource）、生命周期钩子、变更检测（ChangeDetectorRef、OnPush）、NgZone、@defer、@Service（v22）
@angular/common	通用能力	HttpClient（common/http，含拦截器）、内置指令与管道（DatePipe、CurrencyPipe 等）、NgOptimizedImage、Location 与国际化基础设施
@angular/forms	表单	响应式表单（FormControl/FormGroup/FormArray + 严格类型）、模板驱动表单（ngModel）、校验器、Signal Forms（v22 稳定）
@angular/router	路由	路由配置与懒加载、守卫（CanActivate 等函数式守卫）、Resolver、路由级代码分割、v22 起集成浏览器 Navigation API
@angular/platform-browser	浏览器平台	应用引导（bootstrapApplication）、DOM 渲染器、hydration 支持
@angular/platform-server / @angular/ssr	服务端渲染	SSR、预渲染（prerender）、增量 hydration、HTTP 传输缓存
@angular/animations	动画	声明式状态转场动画，与 Web Animations API 对接
@angular/cdk	组件开发套件	无样式的行为原语：Overlay、DragDrop、Virtual Scroll、Table、A11y 工具、剪贴板、文本字段
@angular/material	UI 组件库	基于 CDK 的 Material Design 实现，含主题系统；企业级中后台常用
@angular/aria（v22 稳定）	无障碍组件	提供符合 ARIA 规范的无样式组件与指令，把无障碍能力下沉为框架级默认
@angular/cli	命令行与构建	ng new/generate/serve/build/test/update；esbuild + 应用构建器；Schematics 代码生成；v22 起 MCP 工具链稳定（供 AI 编码代理调用）
@angular/elements	互操作	把 Angular 组件打包为原生自定义元素（Web Components）
@angular/localize	国际化	编译期内联 i18n 消息、多语言包
@angular/service-worker	PWA	Service Worker 集成与更新策略
RxJS第三方但深度集成	响应式编程	Observable 贯穿 HTTP、表单、路由；toSignal() / toObservable() 提供与 Signals 的双向桥接

2026 年的 Angular 是什么样：写起来已经很「像 React」——独立组件、内置控制流、Signals 管理状态、Vitest 测试；但它仍保留着框架级强约束：官方路由、官方表单、官方 HTTP、官方 DI、官方 CLI、官方升级路径。这正是它在金融、政企、大型后台等「多人长期维护」场景中的价值所在。

6 React：从虚拟 DOM 到服务端组件（2011 — 2026）

React 的核心命题只有一句：UI 是状态的函数。围绕这句话，它用十三年时间依次解决了「怎么更新 DOM」（虚拟 DOM）、「怎么让更新可中断」（Fiber）、「怎么复用逻辑」（Hooks）、「怎么减少不必要的重渲染」（Compiler）、「怎么少发 JS 到浏览器」（RSC）。

6.1 React 版本演进时间轴

• 2011 · 内部诞生 — Jordan Walke 开发的 FaxJS 原型首先部署在 Facebook News Feed；2012 年用于 Instagram。
• 2013.05.29 · 0.3.0 —— JSConf US 开源 — 在 JSConf US 上首次公开发布。核心概念：虚拟 DOM、JSX、单向数据流。初期因「把 HTML 写进 JS」饱受质疑。
• 2013—2014 · 0.4 — 0.12 快速迭代 — 0.4 支持注释节点与 key prop；0.8 改善内存；0.9 扩充属性与事件支持；0.11 改进 SVG；0.12 引入 spread 运算符 {...props}，取消 @jsx 注解要求，支持 ES6 类写法。
• 2015.03 · 0.13 —— 官方支持 ES6 Class — 组件可写成 class Foo extends React.Component，混入（mixin）开始被淘汰。
• 2015.10 · 0.14 —— react 与 react-dom 拆分 — 渲染层独立为 react-dom，为 React Native 与自定义渲染器（react-reconciler）打开大门。
• 2016.04.07 · 15.0 —— 语义化版本 — 版本号从 0.x 跳到 15 以示生产可用性；改用 document.createElement 渲染，移除多余的 span 包裹，SVG 支持完善。15.3 引入 PureComponent。
• 2017.09.26 · 16.0 —— ★ Fiber 架构重写 — 内部渲染算法彻底重写：把渲染拆成可中断、可恢复、可分优先级的小单元（fiber）。语法不变，但为后来所有并发特性奠定基础。同时引入 Error Boundaries、Portals、Fragment、自定义 DOM 属性。
• 2018.03 · 16.3 —— 新 Context API — 取代实验性的旧 Context；引入 createRef 与 forwardRef；开始弃用 componentWillMount/ReceiveProps/Update（为异步渲染准备）。
• 2018.10 · 16.6 —— Suspense / lazy / memo — 代码分割与「声明式等待」首次亮相；React.memo 提供函数组件的记忆化。
• 2019.02.06 · 16.8 —— ★ Hooks 稳定 — useState / useEffect / useContext / useReducer / useMemo / useCallback / useRef 发布。类组件迅速退场，逻辑复用从 HOC / Render Props 转向自定义 Hook，这是 React 生态最大的一次范式迁移。
• 2020.10.20 · 17.0 —— 「桥接版」 — 官方定位为没有新特性的版本，唯一目的是让升级更平滑：新的 JSX 自动运行时（react/jsx-runtime，不再需要 import React）、事件委托从 document 改到 root 容器，使多版本 React 可共存。
• 2022.03.29 · 18.0 —— ★ 并发渲染 — 并发渲染器正式可用：createRoot、自动批处理（Automatic Batching）、useTransition、useDeferredValue、useId、Suspense 支持流式 SSR。同时放弃 IE 11 支持。18.3（2024.04）只加弃用警告，为 v19 铺路。
• 2024.12.05 · 19.0 —— ★ Actions 与服务端组件 — React 历史上「最大而全」的一次发布：Actions（用异步函数处理状态更新，自动管理 pending / error / 乐观更新）、useActionState、useFormStatus、useOptimistic、新 use() API、React Server Components 稳定、ref 作为普通 prop、支持在组件内渲染文档元数据（title/meta/link）、样式与异步脚本的原生支持。React Compiler 同期进入 Beta。
• 2025.03—10 · 19.1 / 19.2 —— 打磨与并发增强 — 19.1 带来 Owner Stacks（更好的错误溯源）与 Suspense 行为修正；19.2 引入 View Transitions、useEffectEvent()、<Activity> 组件，并随 Next.js 16 一起成为全栈默认配置。
• 2025.10 · Meta 宣布捐赠 React — Meta 宣布将 React、React Native 与 JSX 捐赠给 Linux 基金会下设的 React Foundation。2026 年 2 月 24 日基金会正式成立，React 脱离单一公司治理。
• 2025.11—12 · RSC 安全事件（React2Shell） — 11 月 29 日披露 CVE-2025-55182（CVSS 10.0 远程代码执行）；12 月 11 日追加 CVE-2025-55184/67779（DoS，7.5）与 CVE-2025-55183（源码泄露，5.3）。修复版本为 19.0.1 / 19.1.2 / 19.2.1，后续补丁回移至 19.0.3 / 19.1.4 / 19.2.3。RSC 把执行面搬上服务端，安全边界随之改变——这是所有服务端优先框架的共同课题。
• 2026 · React Compiler 普及 + React 20 Beta — Compiler 从实验走向默认：自动追踪依赖并在编译期完成 useMemo/useCallback 级别的记忆化，开发者不再手写依赖数组。Rust 移植版被上游采纳，Bun 于 2026 年 6 月率先内置到 bun build（--react-compiler），Next.js/Turbopack 使用 SWC 实现，Vite 8 仍走 Babel 插件。React 20 已进入 Beta。

6.2 官方包与运行时模块

React 官方包职责（区分「你直接 import 的」与「工具链用的」）

包 / 模块	类型	职责与关键 API
react	核心（运行时）	组件模型与 Hooks：useState/useEffect/useMemo/useCallback/useRef/useContext/useReducer/useTransition/useDeferredValue/useOptimistic/useActionState/use()；memo、lazy、Suspense、Activity、StrictMode、startTransition、Context
react-dom	DOM 渲染器	react-dom/client 的 createRoot/hydrateRoot；flushSync；事件系统；Portal；react-dom/server 的 renderToPipeableStream/renderToReadableStream（流式 SSR）
react/jsx-runtime	编译产物	v17 引入的自动 JSX 运行时，由编译器自动引入，源码中通常无需手写
react-reconciler	自定义渲染器	Fiber 协调器的通用实现，React Native、react-three-fiber、ink（命令行 UI）等均基于此构建
react-server	RSC 运行时	服务端组件序列化、「飞行协议」（flight protocol）编解码、'use client'/'use server' 指令处理
react-is	工具	判断元素/组件类型，供库作者做类型分派
react-refresh	开发工具	HMR 的 Fast Refresh 运行时，Vite/Turbopack 插件依赖它
react-devtools	调试	组件树、Props/State 检查、Profiler 火焰图
eslint-plugin-react-hooks	静态检查	强制 Hooks 调用规则与依赖项完整性；Compiler 时代转为「规则合规性检查」
babel-plugin-react-compiler工具链	编译器	React Compiler 的官方 Babel 实现；另有 SWC 版（Next.js 用）与 Rust 版（Bun 用）
React Native	跨端	用同一套组件模型渲染原生 iOS/Android 视图；新架构（JSI/Fabric/TurboModules）已稳定

6.3 React 的四次心智模型跃迁

① 类组件 → 函数组件 + Hooks（2019）

从「生命周期时间轴」思维（mount/update/unmount）转向「同步与副作用」思维（渲染 → 提交 → 副作用）。难点在于依赖数组与闭包陷阱。

② 同步渲染 → 并发渲染（2022）

渲染不再是不可打断的原子操作。紧急更新（输入）可打断非紧急更新（列表渲染），useTransition 让「可中断」成为开发者可控制的 API。

③ 手动优化 → 编译器优化（2024—2026）

React Compiler 自动分析组件依赖并插入记忆化，useMemo/useCallback/memo 从「必写」变成「可省」。代价是必须遵守编译器可分析的规则（不可变数据、不在条件中调用 Hook 等）。

④ 客户端渲染 → 服务端组件（2024—2026）

组件默认在服务端执行，可直接访问数据库、不下发 JS；只有标记 'use client' 的部分才进入浏览器包。心智负担最高的一次跃迁，也是争议最大的一次。

6.4 React 生态地图（官方只给核心，其余自取）

React 生态常见选型（2026 年主流组合）

能力	主流选择	说明
元框架	Next.js 16 / React Router 7 / TanStack Start	Next 占主导；React Router 7（Remix 团队）适合需要完全掌控的场景；TanStack Start 主打类型安全路由
路由	React Router 7 / TanStack Router	两者均支持类型安全的路由定义与数据加载
服务端状态	TanStack Query	请求缓存、失效、重试、乐观更新的事实标准
客户端状态	Zustand / Jotai / Redux Toolkit	新项目多倾向 Zustand（轻量）与 Jotai（原子化）；Redux Toolkit 在大型存量项目仍广泛使用
表单	React Hook Form + Zod	非受控 + schema 校验，性能与类型体验俱佳
样式	Tailwind CSS / CSS Modules / Panda CSS	RSC 环境下 CSS-in-JS（styled-components/emotion）受限，编译期方案更受青睐
UI 组件	shadcn/ui + Radix / MUI / Ant Design	shadcn/ui 因「可复制源码」模式成为新宠；国内中后台常用 Ant Design
动画	Framer Motion（motion）	声明式动画与布局过渡
测试	Vitest + Testing Library / Playwright	Angular 转向 Vitest 后，Vitest 已成为前端测试的共同底座

选型提示：React 的最大优势与最大成本同源——它只提供渲染，其余全靠组装。这意味着团队在第一周就要决定路由、状态、数据、表单、样式五件事。对有经验的团队这是自由，对缺乏架构约定的团队这是技术债的起点。

7 Vue：渐进式框架的自我革命（2013 — 2026）

Vue 的独特之处在于它主动推翻了自己两次：2.0 引入虚拟 DOM 重写渲染层，3.0 用 Proxy 重写响应式，3.6 又用 Vapor Mode 让虚拟 DOM 变成可选项。每一次都做到了「尽量不破坏用户代码」——这是 Vue 在中小企业中长期受欢迎的根本原因。

冷知识：Vue 每个大版本都有一个内部代号，取自漫画/动画作品，且首字母按字母表顺序排列——Evangelion（1.0）→ Ghost in the Shell（2.0）→ Hunter × Hunter（2.1）→ One Piece（3.0）→ Pluto（3.1）→ Quintessential Quintuplets（3.2）→ Rurouni Kenshin（3.3）→ Slam Dunk（3.4）→ Tengen Toppa Gurren Lagann（3.5）。

7.1 Vue 版本演进时间轴

• 2013.07 · 源码首提交（代号 Seed） — 尤雨溪（Evan You）在 Google 工作期间参与 AngularJS 项目后，希望「抽出 Angular 中喜欢的部分，做一个真正轻量的东西」。
• 2013.12 · 0.6 —— 更名 VueJS — 0.7（12.24）、0.8（2014.01，首次公开）、0.9 Animatrix（2014.02）、0.10 Blade Runner（2014.03）、0.11 Cowboy Bebop（2014.11）、0.12 Dragon Ball（2015.06）持续完善数据绑定与指令系统。
• 2015.10.27 · 1.0 Evangelion —— 组件体系确立 — 完整的组件复用机制、生命周期、过滤器、过渡动画。无虚拟 DOM，性能有限，适合中小型页面。
• 2016.09.30 · 2.0 Ghost in the Shell —— ★ 虚拟 DOM 时代 — 引入虚拟 DOM、渲染函数、单文件组件（SFC）、服务端渲染支持；响应式基于 Object.defineProperty。配套 Vue Router、Vuex、Vue CLI 陆续成型，中国市场迅速普及。
• 2017—2019 · 2.1 — 2.6 —— 生态爆发 — 2.5 改进 SSR 与 TypeScript 支持；2.6（2019.02）引入 v-slot 统一插槽语法与错误捕获。Element UI、iView、Ant Design Vue 等国内组件库集中涌现；Weex、uni-app 打开跨端路径。
• 2020.09.18 · 3.0 One Piece —— ★ 彻底重构 — 响应式从 defineProperty 换成 Proxy（支持数组与动态属性）；引入 Composition API；源码改为 Monorepo 并支持 Tree-shaking；原生 TypeScript 编写；新增 Fragment / Teleport / Suspense；性能与体积显著改善。
• 2021.06—08 · 3.1 Pluto / 3.2 —— <script setup> 稳定 — 3.2 是 Vue 3 真正走向主流的版本：<script setup> 编译宏转稳定、性能优化、Web Components 支持。同期 2.7（2022.07）把 Composition API 反向移植回 Vue 2，降低迁移成本。
• 2023.05 · 3.3 Rurouni Kenshin —— TypeScript 体验质变 — 改进 SFC 类型推导、支持导入外部类型的 Props 声明、泛型组件、简化 defineProps/defineEmits 语法。
• 2023.12.28 · 3.4 Slam Dunk —— 解析器与响应式双重提速 — 模板解析器完全重写（约 2 倍提速）、响应式系统重构（computed 更精确）、defineModel 转稳定、v-bind 同名简写。
• 2023.12.31 · Vue 2 正式 EOL — Vue 2（含 2.7）停止维护。调查显示 2025 年仍有约 35% 的受访者在过去一年用过 Vue 2.7，迁移是 Vue 生态长期痛点。
• 2024.09.01 · 3.5 —— 响应式 Props 解构 — Reactive Props Destructure（解构 props 不丢响应式）、惰性 hydration、useId()、useTemplateRef()、SSR 改进与内存优化。
• 2026.07 · 3.6 —— ★ Vapor Mode 生产可用 — 两大核心：alien-signals 响应式内核重写（依赖追踪从运行时移到编译期，官方基准称吞吐提升显著、内存占用下降）与 Vapor Mode 编译策略（模板直接编译为 DOM 操作指令，完全跳过虚拟 DOM）。可在组件级通过 <script setup vapor> 启用，与传统组件混用，生态工具零改动。

7.2 Vue 3 Monorepo 模块全景

Vue 3 源码包划分（理解这层结构，才能理解 Vapor Mode 改了哪里）

包	层次	职责
@vue/reactivity	响应式内核	ref / reactive / computed / watch / watchEffect / effectScope；3.6 起底层替换为 alien-signals——把依赖收集从「运行时 Proxy 拦截」改为「编译期静态分析 + 精确信号链路」。可脱离组件独立使用
@vue/runtime-core	与平台无关的运行时	组件实例与生命周期、虚拟 DOM 与渲染器抽象、Props/Emits/Slots、provide/inject、内置组件（Teleport / Suspense / KeepAlive / Transition）、调度器
@vue/runtime-dom	浏览器运行时	DOM 渲染器实现、内置指令（v-model / v-show / v-on 等）、事件与属性补丁
@vue/compiler-core	编译核心	模板 → AST → 渲染函数的通用编译流程，含转换插件体系与静态提升
@vue/compiler-dom	DOM 编译	针对浏览器平台的指令与模块编译（Vapor Mode 的编译优化主要落在这里）
@vue/compiler-sfc	SFC 编译	解析 .vue 单文件、<script setup> 编译宏、v-bind() in CSS、CSS 变量注入、SFC 类型推导
@vue/compiler-ssr	SSR 编译	把模板编译为服务端可执行的字符串拼接函数
@vue/server-renderer	SSR 运行时	流式 SSR、hydration 匹配与失配处理、惰性 hydration（3.5+）
vue	整合入口	把运行时与编译器打包为完整构建（vue/dist/vue.esm-bundler.js 等），日常使用的就是这个包
vue-router	官方路由	4.x 支持组合式 API、动态路由、路由守卫、数据加载器；Nuxt 4.4 起内部已切换到 Vue Router v5
pinia	官方状态管理	Vuex 的继任者：无 mutations、天然 TS 友好、按 store 拆分、devtools 集成
vuex	上一代状态管理	自 2023 年起进入维护模式，新项目官方推荐 Pinia
@vitejs/plugin-vue	构建集成	Vite 的 Vue SFC 插件；Vue 3.6 + Vite 8 需搭配 plugin-vue 6.x
Vue DevTools	调试	v6 起支持 Vue 3；3.6 版本加入了 AI 代码审查，可检测 Composition API 误用

7.3 Vapor Mode：Vue 对「虚拟 DOM 是否必要」的官方回答

传统模式（虚拟 DOM）

模板 → 渲染函数 → 每次更新构造新的 VNode 树 → 与旧树 diff → 计算 patch → 应用 DOM 变更。

开销：VNode 对象创建（内存分配 + GC 压力）、递归 diff（CPU）、patch 计算。在高频更新场景（大表格、实时面板、复杂图表）尤为明显。

Vapor Mode（编译到 DOM）

模板在编译期被分析，直接生成形如 effect(() => { p.textContent = count.value }) 的 DOM 操作代码。运行时没有 VNode 树、没有 diff、没有 patch。

收益：官方基准显示首次渲染、内存占用、包体积均有明显改善（社区报道分别在 15—50%、约 20%、15—40% 区间，取决于场景）。

Vapor Mode 采用建议

场景	建议	理由
1000+ 行的大型列表 / 表格	优先启用	跳过 VDOM 收益最大，diff 成本与行数正相关
高频更新的实时数据面板	优先启用	每秒多次更新时，VNode 创建与调度开销被放大
普通表单 / 内容页	可启用	收益一般但基本无副作用
动态组件 / 复杂插槽	暂缓	动态性越强，编译期静态分析收益越低
依赖 VDOM 特有写法的组件	需改造	部分依赖渲染函数 / VNode 操作的代码需要迁移，官方提供兼容性检查工具

Vue 3.6 的战略意义：它是主流框架中第一个「官方把虚拟 DOM 变为可选项」的。这等于承认了 Svelte 与 Solid 路线的正确性，同时保留了渐进式迁移——老项目升级版本号即可获得响应式性能提升，无需改任何代码。

7.4 Vue 生态地图

Vue 生态常见选型

能力	主流选择	说明
元框架 / SSR	Nuxt 4	底层已从 Webpack 切换到 Rspack + Lightning CSS，构建速度较 Nuxt 3 显著提升；Nuxt 5 将随 Nitro v3 稳定而到来
静态站点	VitePress	基于 Vite 的文档站生成器，Vue 官方文档即用此构建
路由 / 状态	vue-router 4 / Pinia	官方套件，版本与 Vue 核心同步
工具函数	VueUse	200+ 组合式函数，事实标准
桌面端 UI	Element Plus / Ant Design Vue / Naive UI / PrimeVue	Element Plus 在国内中后台最常见；Naive UI 的 TS 体验好；Vuetify 走 Material 规范
跨端	uni-app / Taro	一套 Vue 语法编译到 H5、微信/支付宝小程序、iOS/Android
测试	Vitest + @vue/test-utils	与 Vite 共享配置，无需维护独立 Babel/Jest 体系

8 Svelte：把框架编译掉（2016 — 2026）

Svelte 的口号是「框架在构建时消失」——它不做运行时 diff，而是把组件编译成直接操作 DOM 的命令式代码。2024 年的 Svelte 5 用 Runes 把「编译器的魔法」变成「开发者显式声明」，是这一路线最重要的一次转向。

8.1 Svelte 版本演进时间轴

• 2016.11 · Svelte 1 —— 「编译器而非框架」 — Rich Harris（Ractive.js 作者、纽约时报图形记者）发布。核心理念：框架应该是编译产物的一部分，而不是随应用一起发布的运行时。此时语法与 Ractive 类似，用 {{#if}} 等 mustache 风格模板。
• 2018.04 · Svelte 2 —— 语法现代化 — 模板语法向更简洁的方向调整，减少冗余语法糖；但整体仍是小众项目。
• 2019.04.22 · Svelte 3 —— ★ 反应式声明与真正的出圈 — 彻底重写。三件事让它爆红：①反应式声明 $: doubled = count * 2（借用了 JS 标签语句语法）；②store 提供跨组件状态；③零运行时开销 + 极小产物。同年首次进入 State of JS 满意度前列。
• 2020—2021 · Sapper → SvelteKit — 原官方应用框架 Sapper 停止演进，由 SvelteKit 接棒（2021 年进入公开测试），提供文件系统路由、SSR、适配器部署。
• 2022.12 · SvelteKit 1.0 — 正式稳定，标志 Svelte 补齐了「元框架」这块关键拼图，可用于生产级全栈应用。
• 2023.06.22 · Svelte 4 —— 内部现代化 — 定位为「维护版」：产物体积更小（约减少 10—20%）、hydration 更快、内部代码库升级到现代 TS，为 Svelte 5 铺路。用户 API 基本不变。
• 2024.10.19 · Svelte 5 GA —— ★ Runes 响应式 — 自 Svelte 3 以来最大变化：Runes（符文）取代隐式响应式。let count = 0 不再自动响应，必须写 let count = $state(0)。同时引入 Snippets（{#snippet} / {@render}）取代 slots、事件属性语法（onclick 而非 on:click）、函数式 mount() 取代 new Component()。
• 2024.12—2025.05 · 5.5 — 5.29 快速补齐 — 5.5 支持从 <script module> 导出 snippet；5.14 新增 $inspect.trace()；5.25 让 $derived 可写（支持乐观 UI 覆盖）；5.29 将 {@attach} 附件（Actions 的响应式升级版）转稳定。
• 2026.03—05 · 5.5x 与 SvelteKit 2.57 — 编译器选项支持函数式配置（css/runes/customElement）；motion 模块导出 Tween/Spring 类型；SvelteKit 2.57 支持 TypeScript 6.0、新增 field.as(type, value) 表单助手与基于 hydratable 的远程函数传输。SvelteKit 2 要求 Svelte 5，无法降级。
• 2026 · SvelteKit Remote Functions — 服务器专属代码放入 .remote.ts 文件，可被组件直接调用，具备完整类型安全、显式模块边界，并提供 OpenTelemetry 追踪——功能上对齐 Next.js Server Actions，但实现更轻。

8.2 Runes：从「魔法」到「显式」

Svelte 4 → Svelte 5 语法对照

Svelte 4（隐式）	Svelte 5（Runes）	变化的意义
let count = 0	let count = $state(0)	响应式变为显式选择，编译器不再猜测哪些变量需要追踪
$: doubled = count * 2	let doubled = $derived(count * 2)	脱离标签语句 hack，派生值成为可组合的一等公民
$: { console.log(count) }	$effect(() => { console.log(count) })	副作用边界清晰，便于理解执行时机
export let prop	let { prop } = $props()	Props 可自然解构，TypeScript 类型推导大幅改善
svelte/store 的 writable	.svelte.ts / .svelte.js 中的 $state	响应式逻辑可以写在普通 TS 文件里，store 样板消失
<slot> / slot=“x”	{#snippet x()} … {@render x()}	片段可作为参数传递、可导出，比 slot 更灵活
on:click	onclick	回归标准 DOM 属性名，减少心智负担
new Component({ target })	mount(Component, { target })	函数式挂载，符合现代 API 习惯

Runes 全表

Rune	用途	变体与说明
$state(x)	响应式状态	$state.raw（不做深层代理）、$state.snapshot（取纯数据快照）、$state.eager
$derived(expr)	派生值	$derived.by(() => {...}) 用于多行逻辑；5.25+ 可写（支持乐观更新）
$effect(fn)	副作用（仅浏览器）	$effect.pre（DOM 更新前）、$effect.tracking、$effect.root（手动控制生命周期）
$props()	组件入参	$props.id() 生成稳定唯一 ID（SSR 安全）
$bindable(default)	双向绑定参数	配合 bind: 使用
$inspect(…)	调试	仅在开发环境生效；$inspect.trace() 可追踪触发来源
$host()	自定义元素宿主	编译为 Web Component 时访问宿主元素

8.3 Svelte 与 SvelteKit 模块构成

Svelte 官方子模块

模块	内容
svelte（核心）	生命周期（onMount/onDestroy/tick）、Runes、Context（setContext/getContext）、mount/unmount/hydrate、flushSync
svelte/store	writable / readable / derived / readonly / get；Svelte 5 中大部分场景可用 $state 替代，但为兼容保留
svelte/motion	Tween / Spring 补间动画原语（5.55 起导出完整类型）
svelte/transition	fade / fly / slide / scale / blur / draw / crossfade，支持自定义 transition 函数
svelte/animate	flip 动画，配合 animate: 指令做列表重排
svelte/easing	30+ 缓动函数（cubicOut、backIn 等）
svelte/reactivity	响应式内置对象：SvelteMap / SvelteSet / SvelteDate / SvelteURL、MediaQuery 等
svelte/events	on() 事件委托工具，替代部分 svelte/internal 用法
svelte/compiler	编译器 API，供 Vite/Rollup 插件与构建工具调用
svelte/server	render() 服务端渲染
svelte/legacy	迁移兼容层（如 createClassComponent），供存量代码过渡

SvelteKit 核心约定与模块

约定 / 模块	作用
src/routes 文件系统路由	目录即路由，+page.svelte（页面）、+layout.svelte（布局）、+error.svelte（错误边界）
+page.server.ts / +layout.server.ts	仅服务端执行的 load 函数，可直连数据库、读取环境变量
load 函数	统一的数据加载入口（universal 可与 server 版共存），支持流式 SSR
Form Actions	渐进增强的表单提交，无 JS 也能工作
Adapters	adapter-auto / node / static / vercel / netlify / cloudflare——同一份代码部署到不同目标
hooks.server.ts / hooks.client.ts	请求拦截、鉴权、日志、错误处理的中间件层
Remote Functions（2026）	.remote.ts 中定义服务端函数，组件直接调用，带完整类型安全与显式边界

Svelte 的真实处境：State of JS 中「愿意再次使用」比例长期领先（2025 年约 85%），开发者体验是公认优势；短板是生态深度——缺少 React Aria 级别的无头组件库，企业级招人也更难。适合中小团队、性能敏感项目，以及作为 Astro 岛屿中的交互层。

9 其他重要框架：Solid / Qwik / Preact / Lit / Alpine

这些框架的市场份额不大，但它们往往是新范式的试验田——Signals 由 Solid 与 Preact 推动成跨框架共识，可恢复性由 Qwik 独家提出。

9.1 Solid.js：React 的语法 + Svelte 的内核

作者 / 首版

Ryan Carniato；1.0 于 2021 年发布

核心理念

「React 的 API 形状 + 细粒度响应式」——JSX + createSignal，但没有虚拟 DOM，且组件只执行一次

关键特性

JSX 直接编译为真实 DOM 创建代码；状态变化只更新订阅它的那一个 DOM 节点；无依赖数组、无 hooks 规则、无重渲染

2026 状态

SolidStart 1.0 已稳定（2025），成为官方元框架；社区报道其渲染性能显著优于 React、核心库体积极小

Solid 模块构成

模块	内容
solid-js（核心）	响应式原语：createSignal、createEffect、createMemo、createResource、onMount / onCleanup / batch / untrack；流程控制组件 <Show> <For> <Index> <Switch>/<Match> <Suspense> <ErrorBoundary> <Portal> <Dynamic>
solid-js/store	createStore 深度代理状态、produce（immer 风格可变写法）、unwrap
solid-js/web	渲染与 SSR：render / hydrate / renderToString / renderToStream、isServer
@solidjs/router	官方路由，支持嵌套路由、数据加载器（preload）、Actions
@solidjs/start	SolidStart 元框架：文件系统路由、SSR/流式渲染、Server Functions、多适配器部署（基于 Vite/Nitro）

为什么 Solid「组件只执行一次」很重要：在 React 中，状态变化会导致组件函数重新执行并产生新的 VNode；在 Solid 中，组件函数在初始化时执行一次后就「消失」了，留下的是信号与 DOM 之间的订阅关系。这既省掉了 diff，也从根本上消除了「闭包过期」「依赖数组漏写」这类问题。

9.2 Qwik：可恢复性（Resumability）

作者 / 首版

Miško Hevery（AngularJS 之父）与 Builder.io 团队；2022 年推出，2023 年 Qwik 1.0 与元框架 Qwik City 稳定

核心理念

传统 hydration 是「把服务端已经做过的事在客户端重做一遍」——这是纯粹的浪费。Qwik 的答案是可恢复性：服务端把应用状态与事件绑定序列化进 HTML，客户端不执行 hydration，直接从中断处继续运行

关键机制

$ 边界（component$、useTask$、onClick$）把代码切成可懒加载的片段（QRL）；用户点击按钮前，该按钮的处理函数一行 JS 都不会下载

2026 状态

Qwik 2 于 2025 年底发布，并从 Builder.io 主导转为独立社区治理；新增异步组件、Component Resumability API，Signals 转稳定

核心 API 模块

• 响应式：useSignal、useComputed$、useResource$、useStore
• 任务：useTask$（服务端或客户端均可执行）、useVisibleTask$（仅浏览器，进入视口触发）
• 数据：routeLoader$（服务端数据加载）、server$、action$（表单与变更）
• 渲染：component$、Slot、SSRStream、Resource
• Qwik City：目录路由、布局、中间件、静态生成、服务端预渲染

适用与不适用

最适合：大型电商、内容站——页面重但交互也多，处于「Astro 太轻、Next.js hydration 太贵」的中间地带。首屏 JS 实测约 2—4KB，Lighthouse 常接近满分。

暂不适合：$ 边界规则、useTask$ 与 useVisibleTask$ 的区别、错误信息可读性都抬高了学习曲线；缺少 MUI / Chakra 级别的成熟 UI 库。

9.3 Preact：3KB 的 React 替身，与 Signals 的推手

作者 / 首版

Jason Miller；2015 年发布，以 ~3KB gzip 的体积提供与 React 高度兼容的 API

定位

体积敏感场景的 React 替代品（嵌入式组件、小程序、性能预算苛刻的页面）

关键贡献

Preact Signals（2022 年发布）证明了 Signals 可以不依赖框架独立存在，直接推动了 Signals 的跨框架普及与 TC39 标准化提案

Preact 模块与版本要点

模块 / 版本	说明
preact	核心（Component、h/createElement、render、Fragment、Hooks）
preact/hooks	与 React 同名的 Hooks 实现
preact/compat	兼容层：让绝大多数 React 生态库（含 React Router、MUI 等）直接跑在 Preact 上
@preact/signals-core	框架无关的 Signals 内核，可单独用于任何 JS 项目
@preact/signals / signals-react	分别为 Preact 与 React 提供绑定（React 版让组件可订阅 signal 而不触发重渲染）
preact/iso	2023 年推出，用于在 Preact 中实现 Astro 风格的「岛屿架构」与选择性 hydration
Fresh（Deno 生态）	基于 Preact 的元框架，2022 年随 Deno 生态推出；2025 年完成向 Vite 的迁移
版本线	Preact X（即 10.x）自 2019 年起是长期主线，持续小版本演进，未走大版本断裂路线

9.4 Lit 与 Alpine.js：标准导向与极简路线

Lit —— 拥抱 Web Components 标准

• 起源：Google Polymer 团队；Polymer 3（2018）→ lit-element → Lit 2.0（2021） → Lit 3.0（2023）
• 理念：不发明组件模型，直接用浏览器原生的自定义元素 + Shadow DOM
• 模块：lit（整合包）、lit-html（模板）、lit-element（基类）、@lit/reactive-element（响应式基类）、@lit/context、@lit-labs/*（实验特性如 ssr、motion、router）
• 价值：产物是标准自定义元素，可被 React/Vue/Angular 直接引用——是跨框架组件复用的现实方案；适合设计系统、微前端共享组件层
• 局限：Shadow DOM 的表单与样式穿透有历史包袱；生态与开发便利性不如主流框架

Alpine.js —— HTML 里的微型响应式

• 起源：Caleb Porzio（Livewire 作者），2020 年发布
• 理念：为服务端渲染的页面（Laravel、Rails、Django、静态站）加一点交互，不引入构建步骤
• 特点：x-data / x-bind / x-on / x-show / x-if / x-for / x-model 直接在 HTML 属性里写逻辑
• 模块：核心 engine + 官方插件（csp、persist、morph、anchor、collapse、focus、mask）
• 定位：常被称为「Tailwind 时代的 jQuery」——与 htmx 一起构成 2020 年代「反 SPA」路线的重要力量

一个容易被忽略的事实：并不是所有 Web 项目都需要 SPA。Alpine.js、htmx、Astro 的流行提醒我们——如果页面 80% 是内容、20% 是交互，那么「服务端渲染 + 少量交互增强」依然是最简单、最健壮、成本最低的方案。框架选型的第一步永远是确认你真的需要一个框架。

10 元框架时代：Next.js / Nuxt / Astro / Remix / TanStack Start

2020 年之后，前端的主要创新不发生在框架本身，而发生在框架之上的元框架层——路由约定、渲染模式、数据加载、缓存策略、部署适配器。选「框架」实际上是在选「元框架 + 生态」。

10.1 Next.js（Vercel，React 生态）

Next.js 主要版本演进

版本	时间	关键变化
1.0 — 8.0	2016.10 — 2019.02	从「零配置 SSR + 文件系统路由」起步，逐步加入代码分割、CSS 支持、Serverless 部署模式
9.x	2019.07 — 2020	API Routes（前后端一体）、动态路由；9.3 引入 getStaticProps/Paths（SSG）、9.5 引入增量静态再生（ISR）
10.x	2020.10	next/image 图片优化、国际化路由、next/script
11.x	2021.06	Webpack 5 默认、一致性改进、实时协作预览
12.x	2021.10	SWC 编译器（Rust，取代 Babel，编译提速数倍）、Middleware、React 18 支持
13.x	2022.10 — 2023.05	App Router（13.4 稳定）与 React Server Components、next/font、Turbopack alpha。这是 Next.js 最大的一次架构转向，也是争议最大的一次
14.x	2023.10	Server Actions 稳定、Turbopack 开发版稳定、Partial Prerendering 预览
15.x	2024.10 — 2025.08	支持 React 19、请求 API 异步化（params/searchParams 变为 Promise）、缓存默认值调整（fetch 不再默认强缓存）；15.5 中 Turbopack 生产构建进入 Beta，Node.js middleware 稳定
16.0	2025.10.22	Turbopack 成为所有应用的默认打包器（稳定）、Cache Components（整合 use cache / PPR / Dynamic IO 为统一缓存编程模型）、React Compiler 内置支持稳定、Build Adapters API（alpha）、增强路由与预取、React 19.2（View Transitions、useEffectEvent()）
16.1	2025.12.18	Turbopack 文件系统缓存（next dev）稳定、内置 Bundle Analyzer、next dev --inspect
16.2	2026.03.18	Adapter API 稳定（多云部署与 OpenNext 协作）、面向 AI 代理的改进（浏览器日志转发到终端、dev server 锁文件、Agent DevTools）
16.3	2026.08.03	Instant Navigations 工具集（部分预取 + 客户端缓存路由外壳，实现接近 SPA 的跳转响应）、开发期内存占用最多降低 90%、构建与渲染提速；安全发布流程化（月度安全版本）

Next.js 核心概念与模块

概念 / 模块	说明
App Router	基于目录的路由，默认 React Server Components；page.tsx / layout.tsx / loading.tsx / error.tsx / route.ts / template.tsx
Server Components	默认服务端执行，零客户端 JS，可直接访问数据库
Client Components	文件顶部标记 'use client' 才进入浏览器包
Server Actions	标 'use server' 的异步函数，直接在表单/事件中调用，替代手写 API 路由
Cache Components（16+）	统一缓存模型：use cache 指令 + cacheLife / cacheTag + updateTag() / refresh() / revalidateTag()，取代此前分散且难预测的缓存行为
Partial Prerendering	静态外壳 + 动态内容流式填充，同一页面兼具 SSG 速度与 SSR 动态性
next/image	自动尺寸、格式转换、懒加载与 CDN 优化
next/font	自托管字体，消除布局抖动与外部请求
Proxy（原 Middleware）	16 起改名为 proxy，明确它只处理路由决策而非业务逻辑；支持 Node.js 运行时
Turbopack	Rust 增量计算打包器，16 起为默认；具备文件系统缓存与 SRI 支持
Adapters API	16.2 起稳定，允许自建构建适配器，降低对单一部署平台的绑定

10.2 Nuxt（Vue 生态）

• 2016—2018 · Nuxt 1.0 / 2.0 — 为 Vue 2 提供 SSR 与静态生成，模块系统（Nuxt Modules）与目录约定（pages / plugins / middleware / store）成为其标志。
• 2022.11 · Nuxt 3.0 —— Nitro 引擎 — 基于 Vue 3 + Vite 重写，引入 Nitro 服务端引擎（跨平台、可部署到 Node/Serverless/Edge/静态托管）、自动导入、useFetch/useAsyncData、混合渲染。
• 2023—2024 · 3.x 持续迭代 — Nuxt Content（文件型 CMS）、Nuxt Image、Nuxt UI、Nuxt DevTools 陆续补齐；Layers 支持跨项目复用目录结构。
• 2025 · Nuxt 4 —— 构建层换血 — 底层从 Webpack 切换到 Rspack + Lightning CSS，构建速度较 Nuxt 3 显著提升（社区报道约 60%）；目录结构规范化（app/ 目录）。
• 2026.03 · Nuxt 4.4 — 路由切换至 Vue Router v5、支持自定义 useFetch/useAsyncData 工厂函数、带类型校验的布局属性、构建性能分析。
• 2026 · Nitro v3 → Nuxt 5 — Nitro v3 alpha（2025.10）是服务器引擎的彻底重写，并从「引擎」演化为「Vite 插件」。Nuxt 5 将在其稳定后发布，带来大幅 DX 与性能提升；Nuxt 4.2 起已提供可选的 Vite Environment API 支持。

Nuxt 核心模块

模块	作用
Nitro	服务端引擎，负责 SSR、API 路由、缓存与多平台部署输出（Node / Deno / Bun / Serverless / Edge / 静态）
自动导入	组件、组合式函数、工具函数无需 import 即可使用，减少样板代码
useFetch / useAsyncData	SSR 友好的数据获取，自动处理请求去重、缓存与 hydration 状态传递
Nuxt Layers	目录级复用机制，适合多产品共享基础层（设计系统、鉴权、布局）
Nuxt Modules	官方与社区模块生态（Content / Image / UI / Auth / I18n / Sitemap 等）
Nuxt DevTools	内置调试面板，含路由、组件、Pinia 状态与时间线
NuxtHub	Cloudflare 平台上的全栈部署方案（KV / D1 / R2 绑定）

10.3 Astro：零 JavaScript 默认

定位

内容优先的 Web 框架，前提是「大多数网页不需要 JavaScript」

核心机制

Islands 架构：整页静态渲染为 HTML，只有标记为岛屿的交互组件才下发 JS，且可指定加载时机

重大事件

2026 年 1 月被 Cloudflare 收购——基础设施公司把框架视为战略层，是 2025—2026 年最值得注意的产业信号之一

Astro 版本要点

版本	时间	要点
1.0	2022.08	岛屿架构正式稳定，.astro 组件（HTML 模板 + frontmatter 脚本）
2.0	2023.01	Content Collections：Markdown/MDX 的类型安全管理与校验
3.0	2023.08	View Transitions 支持、图片优化改进
4.0	2023.12	开发工具栏、i18n 路由、增量内容缓存
5.0	2024.12	Content Layer API（统一处理 Markdown、Sanity、Contentful、Notion 与本地 YAML，自动生成类型）、Server Islands（静态 HTML 长期驻留 CDN，动态部分单独请求）、View Transitions 稳定
5.x	2025—2026	Live Content Collections（运行时取数，避免频繁重建）；Astro 6 将带来重构的开发体验

客户端指令

client:load（立即）、client:idle（空闲）、client:visible（进入视口）、client:media（媒体查询）、client:only（仅客户端）——精确控制 JS 何时下发。

框架无关

同一页面可以同时放 React、Vue、Svelte、Solid、Preact、Lit 组件，各自独立 hydrate。这使 Astro 成为「框架迁移的缓冲区」。

不适合什么

富交互 SPA：岛屿之间共享状态很麻烦，最终往往还是会全量采用某个框架。经验法则——复杂交互占比超过 20% 就该重新评估。

10.4 Remix / React Router 与 TanStack Start

Remix → React Router 7

• Remix 由 Ryan Florence 与 Michael Jackson 创建，1.0 于 2021 年发布，主打Web 标准优先（Form、Request/Response、渐进增强）
• 2022 年被 Shopify 收购；2024 年 11 月 Remix 品牌合并进 React Router 7，React Router 从此具备完整的数据加载、Actions 与 SSR 能力
• React Router 7.10 起支持 Vite Environment API
• Remix 3 的激进转向（2025 年公布）：脱离 React，改用 Web 平台微包 + 命令式 this.update() 状态管理，主打「为 LLM 时代减负」——方向新颖但尚未得到生产验证

TanStack Start

• TanStack 团队（Tanner Linsley）推出的全栈框架，构建在 Vite Environment API 之上
• 主打类型安全的端到端：TanStack Router 的路由类型推导 + Server Functions
• 框架无关：核心支持 React，并已实验性支持 Vue 与 Solid
• 2025 年从 RC 推进，已移除对 Nitro 的硬依赖，允许用户自选服务端引擎
• 适合：已重度使用 TanStack Query/Router/Table 的团队

10.5 元框架横向速览

2026 年主流元框架对比

维度	Next.js 16	Nuxt 4	Astro 5	SvelteKit 2	SolidStart 1.0	TanStack Start
基座框架	React 19	Vue 3.5/3.6	框架无关	Svelte 5	Solid	React / Vue(实验) / Solid
默认渲染	RSC + SSR	SSR + 混合	SSG（零 JS）	SSR + 流式	SSR + 流式	SSR + Server Fns
打包器	Turbopack	Rspack + Lightning CSS	Vite（Rolldown）	Vite	Vite	Vite（Env API）
类型安全路由	有（typed routes）	有	有	有	有	最强
服务端函数	Server Actions	Server Routes / Actions	Actions（v5+）	Remote Functions	Server Functions	Server Functions
部署绑定	Vercel 最优，16.2 起 Adapter 稳定	无（Nitro 多目标）	无（2026 归 Cloudflare）	无（适配器）	无（适配器）	无
学习曲线	高（RSC 心智模型）	中	低	中	中	中—高
生态规模	最大	大	中	中	小	小（增长快）

11 构建工具链：从手工拼接到 Rust 内核

前端构建史有一个反复出现的规律：每一代工具都是因为上一代的「配置负担」或「速度瓶颈」而被推翻。而 2020 年最关键的一次认知突破是——瓶颈不在算法，而在实现语言。

11.1 五代工具链

第 0 代：script 标签与手工拼接（—2011）

没有模块概念，靠 <script> 顺序手动管理依赖，所有代码挂在 window 全局命名空间。压缩靠在线工具或手写 Node 脚本。YUI、Closure Library 等提供命名空间与依赖注入式的组织方式。

第 1 代：模块化与任务流（2011—2013）

Browserify（2011）第一次让浏览器里能写 Node 风格的 require()，把 CommonJS 模块拼接为单文件。Grunt（2012）用配置文件定义任务流水线（压缩、编译、监听），Gulp（2013）改用 Node Stream 的「代码优于配置」，构建速度更快。但二者都是任务运行器，不理解模块依赖图。

第 2 代：打包器统治（2012—2019）

Webpack（2012 首次发布，2015 随 React 爆发）的核心思想：一切资源都是模块，Loader 把任意文件转入依赖图，Plugin 介入构建流程。它带来了代码分割、HMR、懒加载，统治了近十年，代价是配置复杂度成为一门「手艺」。Rollup（2015）押注 ESM，用静态分析发明 Tree Shaking 与 Scope Hoisting，产出更干净，成为库打包的事实标准。Parcel（2017）主打零配置，催生了后来的 CRA 式「隐藏配置」思路。

第 3 代：原生速度 + 开发态不打包（2020—2023）

esbuild（2020，Go 编写）比同类快 10—100 倍，直接证明瓶颈是实现语言。SWC（Rust）在转译层做了同样的事。Snowpack（2020）提出开发态直接用浏览器原生 ESM。Vite（2020，尤雨溪）把这条路线做成主流：开发态不打包、按需用 esbuild 转换单文件；生产态用 Rollup 打包。冷启动几乎与项目规模无关，HMR 变为毫秒级。Vite 同时催生了 Vitest——它复用 Vite 的同一套转换管线，因此测试配置与构建配置可以共享，无需再维护一套 Jest/Babel 平行宇宙。

第 4 代：Rust 重写与内核收敛（2022—2026）

几乎所有工具都被用 Rust 重写了一遍：Turbopack（Vercel，Webpack 作者 Tobias Koppers 主导）、Rspack（字节跳动，Webpack API 的 Rust 实现）、Rolldown（VoidZero，Rollup 插件 API 的 Rust 实现，明确为成为 Vite 引擎而生）、oxc（高性能 JS 工具链集合）、Oxlint / Biome（Rust 版 Lint/Formatter）。

Vite 8（2026.03）：以 Rolldown 作为统一内核，取代「esbuild + Rollup」双引擎 · Rolldown 1.0（2026.05）：API 锁定在 semver 下 · Rspack 2.0（2026.04）/ 2.1（2026.06，内置 Rust 版 React Compiler） · Turbopack：Next.js 16 生产默认

收敛的含义：2020 年代早期「dev 用 esbuild、build 用 Rollup」的双引擎差异，正是「开发能跑、生产报错」这类问题的主要来源。统一为单一 Rust 内核后，开发态与生产态的行为一致性大幅提升。

11.2 构建工具对比

2026 年主流构建工具选型对照

工具	语言	最擅长	首选场景	取舍
Vite 8	JS + Rust 内核	新项目通用打包	新项目默认	生态最大、框架无关、单内核；几乎所有非 Next 元框架都构建在它之上
Webpack 5	JS	复杂遗留工程	存量大型项目	插件生态最广但速度慢、配置重；新项目已不再首选
Rspack 2.x	Rust	Webpack 兼容替代	从 Webpack 迁移	现有 webpack 配置/插件/loader 可最小化改动复用；Nuxt 4 已采用
Turbopack	Rust	Next.js 构建	Next.js 项目	增量计算优秀，Next 16 起为默认；生态限于 Next 体系
Rollup 4	JS	库打包	发布 npm 包	产物最干净、Tree Shaking 成熟；不适合应用级开发服务器
Rolldown	Rust	统一 Vite 内核	作为 Vite 8 引擎	兼容 Rollup 插件 API；1.0 起 API 稳定
esbuild	Go	极速转译/压缩	嵌入其他工具	最快的基线，但插件生态深度不足，通常作为底层依赖而非直接使用
Parcel 2	JS/Rust	零配置	原型与小型项目	开箱即用，但市场份额已被 Vite 大幅挤压

11.3 周边工具链的代际更替

每一层工具都在被「更快 + 零配置」重写

环节	上一代	当前主流	迁移原因
包管理	npm（2010）→ yarn（2016）	pnpm / Bun / yarn Berry	磁盘占用与安装速度；pnpm 的硬链接机制与严格的依赖隔离解决了「幽灵依赖」
语法转译	Babel（2014）	SWC / oxc / esbuild	纯 Rust/Go 实现，速度提升一个数量级；Babel 退居为「插件生态兼容层」
类型检查	tsc（TypeScript 编译器）	tsc + TS 7.0 Go 编译器（2026 GA）	微软用 Go 重写编译器，类型检查速度大幅提升
代码检查	ESLint（2013）+ Prettier	Oxlint / Biome（Rust）	大型仓库的 lint 耗时从分钟级降到秒级；Biome 把 lint 与格式化合二为一
单元测试	Jest（2014）+ Babel	Vitest	复用 Vite 管线，配置与构建一致；Angular 21 起也把 Vitest 设为默认
E2E 测试	Selenium / Cypress	Playwright	多浏览器内核支持、并行执行与追踪调试体验
Monorepo	Lerna（2016）	Turborepo / Nx / pnpm workspaces	任务编排与远程缓存，避免重复构建
运行时	Node.js	Node 22/24 / Bun / Deno 2	Bun 集运行时、包管理、打包、测试于一体；2026 年 1 月 Bun 被 Anthropic 收购
格式化	JSBeautify / Prettier	Prettier / Biome / oxfmt	性能与一致性；Biome 提供 Prettier 兼容模式

实践建议：不要为了「新」而换工具。判断标准只有两条——①当前工具是否已经成为团队协作的实际瓶颈；②新工具是否能复用现有配置（例如从 Webpack 迁 Rspack，或从 Jest 迁 Vitest 时配置可大幅简化）。满足这两条再动。

12 状态管理：从单一 Store 到「服务端/客户端分离」

状态管理的历史，本质是对「什么状态该放哪里」这个问题的反复回答。2026 年的共识是：先把服务端状态交给数据请求库，剩下的客户端 UI 状态用轻量方案——Redux 不再是默认答案。

12.1 演进时间轴

• 2014 · Flux —— 单向数据流的提出 — Facebook 提出 Action → Dispatcher → Store → View 的单向流动，作为对 MVC 双向数据混乱的回应。它是一套模式而非库。
• 2015.06 · Redux —— 事实标准确立 — Dan Abramov 与 Andrew Clark 把 Flux 简化为单一不可变 Store + 纯函数 Reducer + Action。三大原则（单一数据源、状态只读、纯函数修改）带来可预测性与时间旅行调试，样板代码多但心智模型清晰。
• 2015 · MobX —— 相反的路线 — 基于 observable 与自动依赖追踪，允许可变数据、样板极少。与 Redux 形成「显式不可变 vs 隐式响应式」的两极，这一对立延续至今。
• 2015—2016 · Vuex（Vue 生态） — Redux 的 Vue 移植版：state / mutations / actions / getters 四件套，深度集成 Vue DevTools。
• 2015—2018 · 异步中间件大战 — redux-thunk（函数式 action）→ redux-saga（Generator 编排）→ redux-observable（RxJS）。复杂度一路上升，成为 Redux 被诟病的主因。
• 2019.10 · Redux Toolkit —— 官方自救 — configureStore 内置 thunk 与 DevTools、createSlice 用 Immer 实现「可变写法、不可变结果」、createAsyncThunk 处理异步、RTK Query 处理数据请求。样板代码大幅下降，成为 Redux 的现代形态。
• 2019—2020 · ★ 服务端状态独立出来 — SWR（Vercel）与 React Query（Tanner Linsley，后更名 TanStack Query）提出关键洞察：「服务端数据的缓存」与「客户端 UI 状态」是两种性质完全不同的东西，不该塞进同一个 Store。请求去重、失效重取、乐观更新、分页与无限滚动由此有了专门解法。这是十年来状态管理最有价值的一次认知升级。
• 2019—2021 · 轻量与原子化方案 — Zustand（2019）：极简 API，一个 create() 搞定，无需 Provider。Jotai（2020）：自下而上的原子模型，状态按需组合。Valtio：Proxy 代理式可变状态。共同点是「样板代码趋近于零」。
• 2020 · Recoil（Meta）—— 起落 — 由 Meta 推出的原子化状态库，一度被视为 React 官方方向，但因团队变动与维护停滞，生态迅速转向 Jotai / Zustand。这是一个提醒：选型要看维护活跃度，而不是出品方名气。
• 2021—2022 · Pinia 取代 Vuex — 去掉 mutations、天然 TypeScript 友好、按 store 拆分、体积更小。2022 年成为 Vue 官方推荐，2023 年 Vuex 进入维护模式。调查显示超过 80% 的 Vue 开发者已使用 Pinia。
• 2022—2026 · ★ Signals 跨框架复兴 — Preact Signals（2022）证明信号可脱离框架独立存在；随后 Angular Signals（v16 起）、Solid 信号、Vue 3.6 的 alien-signals、Svelte 5 Runes 全部汇入同一范式。TC39 已有 Signals 标准化提案，信号正在成为 JavaScript 的语言级能力。
• 2024—2026 · 服务端函数削弱客户端状态需求 — Server Actions / Server Functions / Remote Functions 让「变更 → 重新验证 → 自动同步」成为框架内置能力，一部分原本需要客户端状态管理的场景直接消失了。

12.2 主流方案对比

状态管理选型对照（2026）

方案	模型	生态	样板代码	适用与点评
Redux Toolkit	单一 Store + Slice	React（可跨框架）	中	大型团队、需要严格可追溯性与中间件；自带 RTK Query 可一并解决数据请求。新项目占比在下降，存量占比仍极高
Zustand	轻量 Store	React（可跨框架）	极少	新项目最常用：无需 Provider、API 直观、体积小；缺点是缺少强约束，大型团队需自建规范
Jotai	原子（自下而上）	React	极少	状态按需组合、重渲染范围天然最小；适合细粒度状态多的场景
Pinia	多 Store	Vue	极少	Vue 官方推荐，TS 体验优秀，与 DevTools 深度集成
MobX	响应式对象	跨框架	少	复杂领域模型、面向对象风格；隐式追踪带来调试难度
Signals（各框架）	细粒度信号	跨框架 / 语言提案	极少	2026 年的技术共识；依赖自动追踪、更新精确到节点
TanStack Query	服务端状态缓存	跨框架	—	不属于「客户端状态」竞争，而是它的前置层：先把服务端数据交给它，剩下的才考虑上面几个
XState	状态机 / 状态图	跨框架	多	复杂业务流程（多步表单、审批流、播放器）；显式建模非法状态，可视化调试是独特优势

2026 年的标准答案：①服务端数据 → TanStack Query（或框架自带的 loader / Server Functions）；②跨组件共享的 UI 状态 → Zustand / Jotai / Pinia；③组件内部状态 → 框架原生 useState / ref / $state；④复杂流程 → XState。只有在团队已有 Redux 投资或需要严格审计追踪时，才从 Redux Toolkit 起步。

13 样式方案：从全局样式表到原子化与设计令牌

CSS tooling 是整个前端生态中变动最快的品类——过去十年每隔两三年就被颠覆一次。理解它的主线是：如何在不产生全局冲突的前提下复用样式。

13.1 演进时间轴

• 1996—2006 · 原生 CSS 与选择器战争 — 一个全局样式表 + 层层覆盖的选择器。CSS 特异性与 !important 成为主要痛点。
• 2006—2009 · 预处理器：Sass / Less / Stylus — Sass（2006）引入变量、嵌套、mixin、函数与模块化；Less（2009）因 Bootstrap 而普及。它们让 CSS 具备了编程能力，但没有解决全局冲突。
• 2010—2014 · 方法论时代：OOCSS / BEM / SMACSS — BEM（Yandex）用 block__element--modifier 命名约定人为制造作用域，是组件化之前的主流方案。同期 Bootstrap（2011）与 Foundation 提供开箱即用的 UI 套件。
• 2013—2015 · PostCSS 与工程化后处理 — Autoprefixer 自动补前缀、cssnano 压缩；PostCSS 把 CSS 变成可编程的 AST，成为现代构建的基础设施。
• 2015—2017 · ★ CSS Modules —— 真正的局部作用域 — 编译时把类名哈希化（.title_x8f2a），从机制上消灭全局冲突。配合 Webpack/Vite 零成本使用，至今仍是 React 项目最稳妥的默认选项。
• 2016—2019 · CSS-in-JS：styled-components → emotion — 把样式写进 JS，天然支持动态样式、主题与组件共存亡。styled-components（2016）率先流行，emotion（2018）以更好的性能与体积接棒。代价：运行时开销、SSR 配置复杂。
• 2017—2019 · ★ Tailwind CSS —— 范式反转 — 从「语义化类名 + 单独写 CSS」转向「在 HTML 里直接组合原子类」。2019 年 v1 后快速普及，2022 年起在新项目中的采用率超过 CSS-in-JS。核心价值：不用再为命名发愁、不用在文件间跳转、设计约束内置于工具类。
• 2021—2024 · RSC 冲击与编译期方案崛起 — 关键转折：运行时 CSS-in-JS（styled-components / emotion）在 React Server Components 环境下无法工作（它们需要客户端运行时注入样式）。这直接催生了编译期方案：Panda CSS（Chakra 团队，build-time，RSC 友好）、StyleX（Meta，零运行时）、UnoCSS（按需生成的原子化引擎，兼容 Tailwind 语法）。
• 2025—2026 · Tailwind 4 与原生 CSS 反攻 — Tailwind 4 转向 Rust 实现、配置从 JS 文件移到 CSS 内的 @theme，构建更快。同时浏览器原生能力补齐：CSS 嵌套、@layer 级联层、@scope 作用域、容器查询、:has() 父选择器、子网格——社区开始讨论「原生 CSS 是否让部分框架变得不必要」。

13.2 五类方案对比

样式方案选型对照

方案	作用域	运行时开销	RSC 兼容	取舍
原生 CSS + 嵌套/@layer	文件级 / @scope	零	是	2026 年已相当可用；适合设计系统底座与轻交互站点
CSS Modules	编译期哈希	零	是	最稳妥的默认选择；心智负担低，与 Sass 可叠加使用
Tailwind CSS 4	原子类	零	是	开发速度最快、产物最小；反对意见主要是 HTML 可读性
UnoCSS	原子类（按需）	零	是	比 Tailwind 更灵活（自定义规则即写即用），生态较小
Panda CSS	编译期原子化	零	是	保留 CSS-in-JS 的写法体验但产物是静态 CSS；增长最快
StyleX	编译期哈希	零	是	Meta 内部大规模使用，类型安全强；外部采用有限
styled-components / emotion	运行时生成	有	受限	动态样式能力最强，但 RSC 环境下需标 'use client'；新项目采用率持续下滑

13.3 UI 组件库的三代变迁

第一代：完整皮肤

Bootstrap（2011）、Foundation、jQuery UI。提供成品样式与组件，定制需要覆盖 CSS。适合后台与原型。

第二代：企业级组件库

Ant Design（2015，阿里）、Material UI / MUI、Element UI（2016，饿了么）、Vuetify、Naive UI、PrimeVue。组件齐全、主题可配，是中后台主力。代价是包体积与设计同质化。

第三代：无头 + 可复制

Radix UI / Headless UI 提供无样式的行为与无障碍能力；shadcn/ui 采用「把源码复制进你的项目」而非 npm 依赖的模式，彻底解决定制难题。2026 年新项目的热门选择。

设计令牌（Design Tokens）正在成为跨框架的统一层：把颜色、间距、圆角、字号抽象为与平台无关的变量（通常用 JSON/Style Dictionary 管理），再分别编译为 CSS 变量、Tailwind 主题、Figma 变量与原生主题。这样「设计系统」就能同时服务 Web、iOS、Android 与小程序。

14 路由与数据请求：SPA 的两条主动脉

路由决定「URL 如何映射到 UI」，数据请求决定「UI 从哪里拿数据」。这两件事在 2020 年后重新合流——现代路由不仅映射组件，还要负责加载组件所需的数据。

14.1 前端路由的四代形态

路由技术演进

代际	机制	代表	特点与局限
第 0 代	服务端路由	PHP / Rails / Django	每次跳转整页刷新，URL 由服务端解析。SEO 天然友好，体验割裂
第 1 代	hash 路由（#/user）	Backbone Router、angular-route、早期 vue-router	利用 hashchange 不触发页面跳转；兼容性最好，但 URL 不美观，且 hash 不会发给服务端
第 2 代	History API（pushState）	HTML5 History（2011 起普及）	URL 干净、可被服务端解析；代价是刷新子路径时需要服务端回退到 index.html
第 3 代	声明式组件路由	React Router v4（2017）、vue-router 3	路由本身变成组件（<Route>），动态路由替代集中式配置表；灵活但难以做数据预加载与静态分析
第 4 代	数据路由	React Router 6.4（2022）、Remix	路由配置同时声明 loader（读）与 action（写），导航与数据请求并行发起，消除「组件挂载后才开始请求」的瀑布流
第 5 代	类型安全 + 文件系统路由	TanStack Router、Next.js App Router、Nuxt、SvelteKit	路径参数、查询参数、搜索校验全部具备类型推导；文件系统即路由，零配置且天然支持代码分割

14.2 React Router 的版本史（SPA 路由的缩影）

• 2014—2016 · v1 — v3：集中式配置 — 路由以 JS 对象数组（或 JSX 嵌套配置）集中声明，支持嵌套路由与 Index Route。
• 2017.03 · v4：★ 声明式重写（重大断裂） — 取消集中配置，路由变成普通组件，可在任意位置声明。理念先进但引发大量迁移阵痛，社区争议极大。
• 2018 · v5：兼容与稳定 — 在 v4 基础上补回部分能力（如 useHistory），成为长期主流版本。
• 2021.11 · v6：Hooks 化与相对路由 — 全面 Hooks API（useNavigate/useParams/useSearchParams）、<Routes> 取代 <Switch>、路由排名算法改进、相对链接与嵌套布局优化（<Outlet>）。
• 2022.09 · v6.4：数据路由 — 引入 createBrowserRouter 与路由级 loader / action / errorElement、<Form>、useFetcher、乐观更新——本质上是把 Remix 的数据能力注入 React Router。
• 2024.11 · v7：★ 合并 Remix，成为全栈框架 — Remix 品牌并入 React Router，后者获得 SSR、静态生成、Server/Client 双环境编译与 Vite 插件。7.10 起支持 Vite Environment API。React Router 从此不再只是一个路由库。

14.3 数据请求：五波浪潮

① XMLHttpRequest → fetch

fetch（2015 标准化）基于 Promise，取代冗长的 XHR 回调。但原生 fetch 不带超时、拦截、取消（后由 AbortController 补齐）。

② axios

2014 年发布，提供拦截器、请求/响应转换、取消、自动 JSON 解析与浏览器/Node 同构。十余年后仍是「低变动品类」里最稳的选择。

③ GraphQL

2015 年 Facebook 开源，用声明式查询取代 REST 多端点；客户端以 Apollo Client、urql、Relay 为代表。解决了过度获取与接口聚合，但引入了 schema 治理与缓存复杂度。

④ TanStack Query / SWR

把「服务端数据」当作缓存来管理：请求去重、窗口聚焦重取、失效重取、分页/无限滚动、乐观更新、错误重试。这是当前最主流的服务端状态方案。

⑤ 服务端函数（2023— ）

Server Actions（Next.js）、Server Functions（Nuxt/SolidStart）、Remote Functions（SvelteKit）、tRPC——让前端直接调用类型安全的服务端函数，不需要手写 API 层。

类型安全 API 的两条路

tRPC：TypeScript 端到端类型推导，无需 schema 代码生成，适合全栈 TS 项目。GraphQL / OpenAPI codegen：跨语言友好，适合多端多语言的大型组织。

2026 年的选择逻辑：如果前后端都是 TypeScript 且由同一团队维护 → tRPC 或框架自带 Server Functions；如果客户端多元（Web + iOS + Android + 第三方）→ OpenAPI/GraphQL + 代码生成；如果数据源多、需要强缓存与离线 → TanStack Query。多数项目是「TanStack Query + 少量 Server Functions」的混合。

15 跨端路线：一次编写，多处运行（的四十年尝试）

「用 Web 技术写原生应用」是前端领域持续时间最长的诱惑。四十年间它反复成功又反复失败，唯一不变的是没有银弹——每种方案都在「开发效率、性能、原生能力、生态」四者中做出不同取舍。

15.1 四条技术路线

路线一：WebView 套壳（Hybrid）

Cordova / PhoneGap（2009）、Ionic（2013）、Capacitor（2018）。HTML/CSS/JS 跑在内置 WebView 里，通过桥接调用原生能力。

取舍：开发成本最低、Web 技能完全复用；性能与体验受限于 WebView，复杂动画与长列表吃力。适合企业内部工具、内容型应用。

路线二：原生渲染（JS 驱动原生组件）

React Native（2015 开源）、Weex（2016，阿里）。JS 写逻辑，渲染交给原生组件，通过桥接通信。RN 的新架构（JSI / Fabric / TurboModules）已消除传统桥的性能瓶颈。

取舍：接近原生的体验、热更新、Web 团队可直接上手；双端差异仍需原生知识，升级与三方库质量是长期痛点。

路线三：自绘引擎（Skia / Impeller）

Flutter（2017 alpha，2018 年 1.0，Dart 语言）。不用平台原生组件，自己绘制每一个像素，因此跨端一致性最高。

取舍：性能与一致性最好、动画能力强；需学习 Dart，包体积较大，Web 端输出体积偏重。

路线四：编译型多端（小程序生态）

uni-app（2018，DCloud）、Taro（2018，京东）。用 Vue/React 语法写一次，编译到 H5、微信/支付宝/抖音小程序、iOS/Android。

取舍：中国市场的事实标准——没有别的方案能同时覆盖各家小程序；代价是编译目标多、平台差异抹平成本高、调试链路复杂。

15.2 桌面端与 PWA

桌面端方案对比

方案	内核	体积	取舍
Electron（2013）	Chromium + Node	大（80MB+）	成熟稳定、生态巨大（VS Code、Slack、Discord）；内存与体积是主要批评
Tauri（2022，Rust）	系统 WebView	小（数 MB）	复用系统 WebView，包极小、内存低；需要处理不同平台 WebView 差异
PWA（2015 提出）	浏览器	几乎为零	Service Worker + Manifest + 离线缓存；iOS 支持曾长期受限，能力仍弱于原生

15.3 跨端方案选型矩阵

2026 年跨端方案对照

方案	语言	目标平台	性能	最适合
React Native	JS/TS	iOS / Android / Web / 桌面	接近原生	已有 React 团队、需要热更新与原生体验的移动应用
Flutter	Dart	iOS / Android / Web / 桌面 / 嵌入式	接近原生	追求跨端像素级一致、复杂自绘 UI 与动画
uni-app	Vue	H5 / 各家小程序 / App / 鸿蒙	中	国内业务，尤其必须同时覆盖微信/支付宝/抖音小程序
Taro	React/Vue	小程序 / H5 / RN	中	已有 React 技术栈但需要输出小程序
Capacitor / Ionic	Web	iOS / Android / Web	中	把现有 Web 应用打包成 App，成本最低
Tauri	Rust + Web	Windows / macOS / Linux / 移动	高	桌面工具类应用，追求小体积与低内存
Electron	Web + Node	桌面三平台	中	需要完整 Node 能力与成熟生态的桌面应用

选型提醒：跨端方案的真实成本往往不在开发期，而在第 6 个月之后——当业务需要调用一个平台特有能力，或某个三方库停止维护时。选型前应确认：目标平台差异有多大？团队是否具备原生调试能力？遇到平台限制时的兜底方案是什么？

16 TypeScript：从可选到默认

2012 年 TypeScript 发布时，多数人认为它只是给 Java 开发者的安慰剂。2026 年，它已经是所有主流框架的默认语言——Angular 强制、Vue 源码即 TS、React 生态的类型覆盖近乎完整。

TypeScript 关键版本与能力

版本	时间	标志性能力
0.8	2012.10	首次公开发布（微软， Anders Hejlsberg 主导）
1.0	2014.04	首个稳定版，正式进入生产可用
1.5	2015	ES6 模块语法、装饰器（实验性，后被 Angular 大量使用）
2.0	2016	strictNullChecks、never 类型、更精细的控制流类型收窄——TypeScript 从「可选类型标注」变成「真正的类型系统」
3.0	2018	Project References（大型项目增量构建）、元组类型增强、unknown 类型
4.0	2020	可变元组类型、标记元组元素（极大改善函数式 API 的推导）
4.1—4.9	2020—2022	模板字面量类型、递归条件类型、satisfies 运算符（4.9，兼具类型检查与字面量推导）
5.0	2023.03	用 ES Modules 重写编译器（构建与包体积大幅优化）、标准装饰器（与 TC39 提案对齐）、const 类型参数
5.x	2023—2025	using 显式资源管理、推断类型谓词、NoInfer、正则语法检查。Angular 22 要求 TS ≥ 5.9
7.0	2026	Go 原生编译器（tsgo）正式 GA——把类型检查器移植到 Go，编译与检查速度数量级提升，语言服务响应更快

为什么它赢了

• 渐进式采用：.js 可逐文件迁移，allowJs 与 checkJs 提供中间态
• 类型可推导：多数场景不需要手写标注
• 编辑器体验：重构、跳转、自动补全成为刚需
• 生态倒逼：DefinitelyTyped 与库作者自带类型形成正循环

常见代价

• 类型体操：复杂泛型写法难读难维护
• 构建耗时：虽被 Go 编译器大幅缓解，大型仓库仍需增量与缓存策略
• 类型与运行时脱节：类型正确不代表逻辑正确，边界校验（如 Zod）仍必要

2026 实践建议

• 开启 strict: true（含 strictNullChecks）
• 用 Zod / Valibot 做运行时边界校验，与 TS 类型共享 schema
• 大型仓库开启 Project References 或改用 Go 编译器
• 库作者优先保证类型推导，而非手写复杂类型

17 横向对比：八大框架全维度矩阵

下面这张表是本文档的核心产出——把前面所有章节浓缩为可直接用于技术评审的对比依据。

17.1 基础属性对比

八大框架基础属性（截至 2026 年 9 月）

维度	React 19	Vue 3.6	Angular 22	Svelte 5	Solid 1.x	Qwik 2	Preact 10	Astro 5
定位	UI 库	渐进式框架	完整平台	编译器	响应式 UI 库	可恢复框架	轻量 React 替代	内容站框架
首版	2013.05	2014.02	2016.09（AngularJS 2010）	2016.11	2021	2022	2015	2022.08
当前版本	19.2.x（20 已 Beta）	3.6.x	22.0.x	5.5x	1.9x	2.x	10.x	5.x
维护方	React Foundation（Linux 基金会）	Vue 团队 / VoidZero	Google	Vercel（Rich Harris）	社区 / Ryan Carniato	独立社区（原 Builder.io）	社区	Cloudflare（2026 收购）
主语言	JS/TS	TS	TS 强制	TS	TS	TS	JS/TS	TS
模板 / 视图	JSX	SFC 模板（可 JSX）	模板 + 内置控制流	Svelte 模板	JSX	JSX	JSX / HTM	.astro 组件
响应式模型	不可变 + 重渲染（Compiler 优化）	Proxy / alien-signals + Vapor	Signals（Zoneless）	Runes（$state）	Signals	Signals + QRL	Hooks / Signals	岛屿各自独立
虚拟 DOM	有	可选（Vapor 可关）	有（Ivy 增量）	无	无	无	有（极简）	无（静态 HTML）
组件重执行	每次更新重跑	每次更新重跑	按绑定更新	仅初始化一次	仅初始化一次	可恢复，不重跑	每次更新重跑	岛屿按需
官方路由	无（React Router）	vue-router	@angular/router	SvelteKit 内置	@solidjs/router	Qwik City 内置	无	文件系统路由
官方状态	无（Zustand 等）	Pinia	Signals / Service+RxJS	Runes（无需库）	Signals（无需库）	Signals（无需库）	Signals	岛屿内自行选择
官方表单	无（RHF / 原生 Actions）	无（vee-validate）	@angular/forms（Signal Forms）	无	无	无	无	Form Actions
SSR / 元框架	Next.js 16 / React Router 7	Nuxt 4	@angular/ssr	SvelteKit 2	SolidStart 1.0	Qwik City	Fresh	自身即元框架
发布节奏	不定期大版本	约 1—2 年一次大版本	12 个月一个大版本（v22 起）	不定期	小步快跑	社区驱动	长期 10.x	约 1 年
向后兼容	强（有 codemod）	强（渐进迁移）	最强（ng update 自动迁移）	4→5 有断裂（Runes）	稳定	1→2 有断裂	强	强
生态规模	最大	很大（中国尤强）	大（企业向）	中	小	很小	中（复用 React）	中
招人难度	低	低（国内极低）	中	中—高	高	很高	低（React 技能可迁移）	中

17.2 能力维度评分

评分为相对定性判断（5 分制），用于快速定位差异，不代表绝对优劣。

能力维度评分（5 分制，含评分口径说明）

维度	React	Vue	Angular	Svelte	Solid	Qwik	评分口径
上手容易度	3	5	2	4	3	2	新手从零到写出生效页面的难度
运行时性能	3	4（Vapor 5）	4	5	5	5	高频更新场景下的开销
首屏 / TTI	3（RSC 4）	4	3	4	4	5	首屏 JS 体积与可交互时间
开发体验	4	5	4	5	4	2	样板代码量、报错可读性、工具链
TypeScript	4	4	5	4	4	4	类型推导质量与生态类型覆盖
生态丰富度	5	4	4	3	2	1	组件库、工具、教程、第三方集成
大型项目约束	2	3	5	3	3	3	框架本身对架构一致性的强制力
长期维护保障	4（基金会）	4	5（Google + 固定周期）	3（Vercel）	3	2	治理结构与升级路径确定性
SSR / 全栈能力	5（Next 16）	5（Nuxt 4）	4	4	4	4	服务端渲染、数据加载、部署完整度
内容站适配	2	3	2	3	3	4	是否适合博客/文档/营销页（对照 Astro 5 满分）

18 性能与体积：数据怎么看，坑在哪里

前端性能对比是网络上误导最多的领域之一。理解下面的方法论，比记住任何一组数字都重要。

18.1 三类「体积」，别混为一谈

① 框架运行时基线

只算框架自身必须下发的代码，不含业务代码。这是各家宣传数据的主要来源。确定性参考点：Preact 约 3—4KB gzip、Solid 核心约 7KB、Svelte 5 编译后运行时极小。

② Hello World 产物

最小应用打包后的总大小。比基线更接近真实，但仍不含业务逻辑。Astro 静态页与 Qwik 首屏可做到接近 0 到数 KB。

③ 真实应用体积

包含路由、状态、UI 库、图标、日期、图表等。这一项几乎总是由业务依赖而非框架决定——引一个 Ant Design 或 MUI，框架差异就被淹没了。

常见误区：拿「框架运行时基线」的数字去论证真实项目的性能差异。实际项目中，体积的 80% 来自业务代码与第三方依赖，而卡顿的 80% 来自不必要的重渲染、未虚拟化的长列表、未优化的图片与字体。框架选择影响的是上限，工程实践决定的是下限。

18.2 相对体积示意

说明：Angular 未列入此图，因为它通常是「平台整体」而非可拆分的视图层，其体积取决于使用了多少官方模块（路由、表单、动画、Material 等）。

18.3 性能优化的三层杠杆（按收益排序）

投入产出比从高到低

优先级	杠杆	典型手段与收益
P0	资源与网络	图片格式与尺寸（WebP/AVIF、响应式 srcset）、字体子集化与 font-display、CDN、HTTP/2-3、压缩（Brotli）、缓存策略。通常占可优化空间的 50% 以上
P0	渲染策略	把内容页改为 SSG/ISR（Astro、Nuxt、Next）；对交互页启用流式 SSR 与部分预渲染。首屏收益最大的一次结构性选择
P1	减少不必要的渲染	React Compiler / Vue Vapor / Signals；长列表虚拟化（TanStack Virtual）；避免在渲染中做重计算
P1	代码分割	路由级懒加载、组件级 lazy、第三方库按需引入（如 lodash-es、图标按需）
P2	框架层面的微优化	换更小的框架、memo、不可变数据结构。只有当上面四项都做完、仍有明确瓶颈时才值得做

19 选型决策：五个问题定乾坤

技术选型的绝大多数错误，源于先选框架、再套需求。正确顺序是先回答五个问题，答案自然会收敛到一到两个候选。

19.1 决策树

19.2 场景 → 推荐速查

常见业务场景的推荐组合

场景	首选	备选	关键理由
企业官网 / 营销页	Astro 5（静态 + 岛屿）	Next.js 16（SSG）	零 JS 默认，Lighthouse 分数最优
博客 / 文档站 / 知识库	Astro 5 + Content Layer	VitePress / Nuxt Content	Markdown/MDX 类型安全、构建快
中后台管理系统	Vue 3.6 + Element Plus；或 React + Ant Design	Angular 22 + Material	组件库成熟、招人容易、表单与表格需求重
大型金融 / 政企系统	Angular 22	React 19 + 严格规范	强约束、官方全家桶、固定发布周期与长期支持
SaaS 全栈应用	Next.js 16（RSC + Server Actions）	Nuxt 4 / SvelteKit 2	全栈一体、缓存模型完善、部署便利
实时数据看板	Vue 3.6（Vapor）或 Solid	React + 虚拟列表 + Compiler	高频更新，细粒度响应式收益最大
电商前台	Astro 5 / Qwik 2（内容 + 交互混合）	Next.js 16 + PPR	首屏敏感 + 交互不少，需要岛屿或可恢复
小程序 / 多端	uni-app（Vue）或 Taro（React）	原生小程序	国内多平台覆盖没有替代方案
移动端 App	React Native	Flutter	取决于团队语言偏好与一致性要求
桌面工具	Tauri（小体积）	Electron（生态全）	权衡包体积与 Node 能力
嵌入式 / 第三方小组件	Preact 或 Svelte 5	Lit（Web Components）	体积是第一约束；Lit 便于跨框架复用
老系统渐进改造	Vue 3（可 <script> 直接引入）	Alpine.js / htmx	渐进式是 Vue 名字里最强的能力

反模式清单（这些错误在真实项目里反复出现）：①用 SPA 框架做纯内容站，然后花大力气补 SEO；②因为「新技术」在核心业务上采用维护者单一、生态薄弱的框架；③在没有性能预算时，为了 5KB 体积差异付出 3 个月的迁移成本；④让框架决定架构——框架应该是架构的执行者，不是设计者；⑤忽略升级成本：选了需要逐个大版本升级的框架（Angular），却没有安排升级预算。

20 常见迁移路径与成本控制

任何技术文档都不应回避「怎么从旧版本过来」。以下是六条最常见的迁移路径，每条都给出可行策略与主要风险。

迁移路径对照

迁移	难度	策略与要点
Vue 2 → Vue 3	中	先升到 2.7（已内置 Composition API），把新代码写成组合式；再用官方迁移构建版逐个处理废弃项。调查显示超过四分之一的团队在此过程遇到困难，主要来自第三方组件库不兼容——先确认 UI 库是否有 Vue 3 版本，这是最大的阻塞点
AngularJS → Angular	高	不是升级而是重写。可行路径：用 ngUpgrade 让两个框架在同一应用中共存，按模块逐步替换；或保留 AngularJS 并采购第三方延长支持（部分供应商提供到 2030 年）。前者成本高，后者只是延后问题
Angular 19 → 22	中（但不可跳版）	必须 19→20→21→22 依次 ng update，每次验证并提交。重点关注：独立组件默认、内置控制流迁移、Signals 与 Zoneless 的取舍。停留在 19 及以下已无安全补丁，应视为安全义务
React 类组件 → Hooks	低—中	可长期共存，逐个组件替换。先转换无状态与简单有状态组件，生命周期复杂的组件最后处理。React Compiler 要求代码遵守可分析规则，迁移时顺便清理不规范的写法
Next.js Pages → App Router	高	两种路由可并存，支持按路由逐步迁移。主要难点是心智模型：getServerSideProps → 服务端组件直接取数；getStaticProps → generateStaticParams + 缓存；API Routes → Route Handlers 或 Server Actions。建议先在非核心路由试点
Webpack → Vite / Rspack	中	Vite：配置大幅简化，但需处理 CommonJS 依赖与 Node 内置模块 polyfill。Rspack：对 Webpack 配置高度兼容，迁移成本更低，适合大型遗留工程直迁
Jest → Vitest	低	API 高度相似，多数断言可直接使用；主要工作是替换模块 mock 语法与移除 Babel 配置。收益是测试配置与构建配置统一
jQuery → 现代框架	高	不要整体重写。策略：用 Vue 3 的渐进式能力，把页面中的独立交互块逐个替换为组件（可 <script> 直接引入，无需构建）；或先只在新页面使用框架，老页面维持 jQuery 直到自然下线

21 2026 之后的六个确定性趋势

① Signals 走向语言标准

Angular、Vue（alien-signals）、Solid、Svelte（Runes）、Preact 已全部采用信号模型，TC39 的 Signals 提案在推进。含义：未来切换框架时，响应式的心智模型可以复用——这降低了框架锁定的成本。

② 虚拟 DOM 从「必需」降级为「可选」

Vue 3.6 的 Vapor Mode 是标志性事件：最主流的框架之一官方承认 VDOM 可以不要。预计其他框架会跟进提供类似的编译策略开关，形成「传统模式保兼容 + 编译模式追性能」的双模结构。

③ Rust 工具链成为默认

Vite 8（Rolldown）、Rspack 2、Turbopack、oxc、Oxlint/Biome、TypeScript Go 编译器——构建与检查环节正在被系统级语言全面接管。含义：未来「构建慢」将不再是可以接受的借口。

④ AI 编码代理成为一等用户

Next.js 提供浏览器日志转发与 Agent DevTools，Angular 22 的 MCP 工具链稳定，生态重心从 MCP 转向 Agent Skills。框架开始提供机器可读的错误信息与结构化诊断，而不仅仅是给人看的报错页。

⑤ 安全响应流程化

2025 年底的 RSC 系列漏洞（含 CVSS 10.0）之后，Next.js 从 2026 年 7 月起建立月度安全发布机制，Angular 也在 2026 年夏密集发布安全公告。服务端优先架构扩大了攻击面，安全响应正在从「临时补丁」变为「固定流程」。

⑥ Web 平台补齐，框架必要性下降

原生 CSS 嵌套与 @layer/@scope、View Transitions、Navigation API、容器查询、:has()、Web Components 逐渐成熟。含义：轻量场景（内容站、简单交互）将不再需要重型框架——这与 Astro、Alpine、htmx 的流行互相印证。

21.1 值得关注但尚未定型的方向

Remix 3 的激进实验

脱离 React，改用 Web 平台微包 + 命令式 this.update()，主张为 LLM 时代减负。方向新颖，但缺少生产验证。

框架被基础设施公司收购

Cloudflare 收购 Astro（2026.01）、Anthropic 收购 Bun（2026.01）。框架正在成为云与 AI 公司的战略入口，长期看可能改变中立性。

去中心化治理

React 归入 Linux 基金会（2026.02）、Qwik 转为独立社区治理。治理结构正在成为技术选型的新考量维度。

22 术语表与核心参考

语言与运行时

• JavaScript：运行在浏览器与 Node.js 上的动态脚本语言，1995 年由 Brendan Eich 用十天写成，1997 年起成为 ECMAScript 标准的实现。它是前端唯一被所有浏览器原生支持的编程语言——无论框架怎么演进，最终都要编译或运行为 JavaScript，本文所说的「框架战争」，本质上都是在 JavaScript 的表达能力与性能约束下做取舍。注意三个常被混用的概念：JavaScript 是语言，ECMAScript 是它遵循的规范，V8 等引擎是规范的实现。
• ECMAScript（ES / ES6 / ES2015）：JavaScript 的官方语言规范，由 ECMA 国际下属的 TC39 委员会制定，新特性需经过 Stage 0 到 Stage 4 五阶段流程才能入标准。2015 年的 ES6（ES2015）是分水岭：let/const、箭头函数、类、模块（ESM）、Promise、解构、模板字符串等一次性补齐，让 JavaScript 从「写特效的脚本」变成能支撑大型工程的语言。此后 TC39 改为每年发布一版（ES2016、ES2017……），本文多个框架的能力（如 Angular 的装饰器、类的字段语法）都依赖特定 ES 版本。
• TypeScript：微软 2012 年发布的 JavaScript 超集，在 JS 之上增加静态类型系统，编译后类型被擦除、还原为纯 JavaScript。它解决的是大型项目里「改一处崩三处」的问题：类型标注让 IDE 能自动补全与安全重构，编译期就能拦住大量低级错误。2019 年后它几乎成为新项目的默认选择（本文第 16 章专门讲这条演进线），Angular 从 2.0 起就用 TypeScript 写就，Vue 3 与 Svelte 也先后转为 TS 实现。代价是需要维护类型声明（@types 包）与额外的构建配置。
• 类型安全 / 静态类型：通过编译期类型检查，在代码运行前就发现「把字符串当数字用」这类错误的能力。TypeScript 提供的是「渐进类型」——你可以只给部分代码加类型，这也是它能被庞大的 JavaScript 生态接受的关键。需要清醒认识的是：类型安全不等于运行时安全，类型在编译后被完全擦除，来自接口响应、用户输入的数据仍然必须做运行时校验。本文第 16 章讨论的「类型即文档」，是它在团队协作中最被低估的价值。
• 泛型：让函数或类型在使用时才确定具体类型参数的机制，写作 Array<T>、Promise<T> 这样的形式。它让「容器类」代码既能复用又保留类型信息——没有泛型时，要么放弃类型（退化成 any），要么为每种类型复制一份实现。在前端框架中，泛型广泛用于组件 props、Hook 返回值与请求函数的封装，是类型系统从「能用」走向「好用」的分界线。
• 装饰器：一种用 @ 符号给类、方法或属性附加元数据的语法，典型如 Angular 的 @Component、@Injectable。它本质是编译期或运行期的函数包装，常与依赖注入配合使用。值得注意的历史细节：由于 TC39 的装饰器提案长期停留在 Stage 2/3 且多次改版，Angular 选择自己实现一套稳定装饰器；Vue 曾在 2.x 用装饰器写组件、3.x 又退回普通对象写法。这个反复本身就是「标准滞后于实践」的典型案例。
• ESM（ES Modules）：ECMAScript 官方模块系统，用 import/export 语法，随 ES6 引入。它的关键特性是「静态结构」——依赖关系在编译期就能确定，这让 Tree Shaking（摇树优化）与作用域提升成为可能，也是 Vite 开发服务器能按需编译的前提。在此之前社区用 CommonJS（Node）、AMD/UMD（浏览器）各自为政。如今 ESM 已是浏览器与 Node.js 统一的模块标准。
• CommonJS：Node.js 早期采用的模块规范，用 require() 与 module.exports 同步加载模块。它曾是 npm 生态的事实标准，但因为是运行时动态解析依赖，无法做静态的 Tree Shaking。随着 ESM 普及，纯 CommonJS 的包正逐渐成为历史包袱，也是现代构建工具兼容层里最麻烦的一块（Vite 需要靠依赖预构建来转换它们）。
• Babel：2014 年由 Sebastian McKenzie 发布的 JavaScript 编译器，作用是把新语法（ES6+、JSX、TypeScript）转译为旧浏览器能跑的 ES5。它以插件化方式实现，配合 @babel/preset-env 与目标浏览器配置决定要降级多少语法。2015 到 2020 年间它是几乎每个项目的标配；随着 esbuild、SWC 等用 Go/Rust 编写的编译器出现，Babel 因性能问题在构建链路中正被逐步替换，但在复杂语法兼容上仍是最后的兜底方案。
• 转译：把一种高级语言或语法改写为另一种等价形式的过程，典型如 TypeScript 转 JavaScript、JSX 转函数调用、新版 ES 降级为 ES5。它不改变程序语义，只改变表达方式，因此与「编译成机器码」有本质区别。现代前端几乎所有源码都要经过转译才能进浏览器，这条链路的性能直接决定了开发体验的快慢。
• DOM：Document Object Model，浏览器把 HTML 文档解析成的树形对象结构，JavaScript 通过它读写页面内容与结构。DOM 操作是前端性能的经典瓶颈——它比纯 JS 计算慢几个数量级，读写还会触发重排与重绘。因此「减少并批量化 DOM 操作」成为从 jQuery 到虚拟 DOM 所有方案共同的第一原则；本文反复出现的「直接操作 DOM」与「声明式更新」之争，根源都在这里。
• Shadow DOM：Web Components 标准的一部分，为元素创建一棵与主文档隔离的子 DOM 树，内部样式与外部互不影响。它解决了组件化最根本的难题——样式与结构的作用域隔离，且是浏览器原生能力、无需框架。代价是调试困难、外部样式穿透需要 ::part 与 ::slotted 等特殊机制，这也是部分团队对 Web Components 敬而远之的原因之一。
• Web Components：浏览器原生的组件标准，由 Custom Elements（自定义标签）、Shadow DOM（样式隔离）、HTML Templates（模板）三块组成。它最大的优势是「框架无关、浏览器原生」，理论上能终结框架战争；但实践中因为缺少高效的响应式更新机制、服务端渲染支持弱、工具链与生态不足，始终没能成为主流。如今它的现实定位是：作为 Lit 等轻量框架的底座，以及微前端与跨框架组件复用的底层手段。
• Service Worker：浏览器在后台独立运行的脚本，能够拦截网络请求、做离线缓存与消息推送，是 PWA 的技术核心。它让 Web 应用首次具备「离线可用」与「安装到桌面」的能力。由于它缓存资源的能力很强，也常导致「代码已更新但用户仍看到旧版本」的经典问题，必须配合版本化的缓存策略与更新提示来治理。
• Web Worker：让 JavaScript 在后台线程运行的机制，避免长任务阻塞主线程导致页面卡顿（掉帧、点不动）。Worker 与主线程通过消息传递通信，不能直接操作 DOM，也没有 window 对象。典型用法是大数据计算、语法高亮、图片处理等 CPU 密集任务，是「把重活挪出主线程」的标准手段。
• WebView：嵌入在原生 App 内部的浏览器内核组件，用来显示网页内容，是 Hybrid App 与小程序的技术基础。它的能力受系统版本限制（iOS 的 WKWebView、Android 系统 WebView 版本碎片化严重），性能与原生控件存在肉眼可见的差距。这个差距正是本文第 15 章跨端方案四十年反复演进的核心动因。
• Node.js：2009 年由 Ryan Dahl 发布，把 Chrome 的 V8 引擎搬出浏览器，让 JavaScript 能够写服务端与命令行工具。它的历史意义在于统一了前后端语言，并催生了 npm 生态与整套前端工具链——Webpack、Vite、Babel 全都是跑在 Node 上的程序。本文涉及的所有构建工具与元框架都依赖 Node；Deno 与 Bun 是它的后继挑战者。
• Deno：Ryan Dahl 在 2018 年发布的 Node.js「修正版」运行时，针对他本人总结的 Node 十大设计遗憾做了改进：默认安全沙箱（显式授权才能读写文件与网络）、原生支持 TypeScript、内置格式化与测试等工具链、全面采用 ESM。因为与 npm 生态不完全兼容，它始终没能取代 Node，但在边缘计算与脚本场景占据了一席之地。
• Bun：2022 年发布的 JavaScript 运行时，用 Zig 编写，主打极快的启动速度与 All-in-one 的能力——内置包管理器、打包器、测试运行器，目标是同时替代 Node + npm + Jest + Webpack。它兼容大部分 Node API 与 npm 包。值得留意的动向：Bun 在 2026 年 1 月被 Anthropic 收购，引发了社区对其路线中立性的讨论。
• V8：Google 开发的高性能 JavaScript 引擎，用于 Chrome 浏览器与 Node.js，采用 JIT（即时编译）把 JavaScript 编译为机器码执行，并配合分代垃圾回收与隐藏类优化。它的性能直接决定了 JS 能承担多复杂的任务，也间接让「在浏览器里跑完整应用」这件事成为可能。其他主流引擎还有 Firefox 的 SpiderMonkey 与 Safari 的 JavaScriptCore。
• AJAX：Asynchronous JavaScript and XML，2005 年由 Jesse James Garrett 命名，指用 XMLHttpRequest 在不刷新页面的情况下与服务器交换数据。它是 Web 2.0 的起点，让网页从「文档」变成「应用」，也直接催生了 jQuery 的流行与后来的单页应用。严格来说今天大家用的是 JSON 配 fetch，但 AJAX 作为这一范式的名字被保留了下来。

渲染架构

• SPA（单页应用）：Single Page Application：首次只加载一个 HTML 外壳，之后所有页面切换都在客户端由 JavaScript 完成，不再向服务器请求完整页面。它带来了接近原生 App 的切换体验，代价是首屏必须下载并执行全部 JS、SEO 与首屏性能变差，并且路由、数据获取、状态管理都要在客户端重新实现一遍。2010 到 2018 年它是绝对主流，此后被 SSR/SSG 与元框架逐步回补。

• PWA（渐进式 Web 应用）：Progressive Web App：用 Service Worker、Web App Manifest 与 HTTPS，让网页具备离线可用、可安装到桌面、消息推送等原生应用能力。2018 年前后被 Google 大力推广，但因 iOS 支持长期不完整、用户找不到入口（不习惯「添加到主屏幕」），始终没能取代原生 App，最终沉淀为一项「锦上添花」的增强能力而非主流形态。

• SSR（服务端渲染）：在服务器上把组件渲染成 HTML 字符串发给浏览器，用户立刻看到内容，随后再加载 JavaScript 完成水合（hydration）。它解决的是 SPA 首屏白屏与 SEO 问题，代价是服务端有额外渲染成本、需要处理数据预取与状态序列化，并且水合期间页面可能出现「看得见但点不动」的窗口期。Next.js 与 Nuxt 的核心价值，正是把这套流程工程化。

• SSG（静态站点生成）：在构建阶段就把页面渲染成静态 HTML 文件，部署到 CDN 上，用户访问时直接返回文件、无需任何服务端计算。它的性能、安全性与成本都是最优解，但只适合内容不频繁变化的场景（文档、博客、营销页）。内容更新需要重新构建整个站点，这个痛点直接催生了下面的 ISR。

• ISR（增量静态再生）：Incremental Static Regeneration：Next.js 提出的折中方案——页面首次按 SSG 生成静态文件，之后在后台按设定的时间间隔（或按需触发）重新生成，兼顾静态的性能与内容的时效性。它让「静态」不再意味着内容无法更新，是内容型站点在 SSG 与 SSR 之间最实用的一档选择。

• CSR（客户端渲染）：HTML 几乎是一具空壳，全部内容由浏览器下载 JavaScript 后再渲染出来。它是 SPA 的默认形态：开发简单、交互流畅，但首屏性能与 SEO 最差，且首屏时间高度依赖 JS 包体积与设备性能。本文把它与 SSR/SSG/ISR 并列为四种渲染时机与位置的策略。

• Hydration（水合 / 注水）：服务端渲染出来的 HTML 只是一张「静态照片」，需要在客户端重新执行组件代码、建立状态并绑定事件监听，这个激活过程就叫水合。它的尴尬之处在于：为了激活页面，客户端仍然要下载并执行完整的组件 JS，因此 SSR 只改善了首屏观感，并没有减少总 JavaScript 量——这个「水合税」正是 Islands 架构、可恢复性与服务端组件等新方案要集中解决的目标。

• Islands（岛屿架构）：页面默认全部是静态 HTML，只有真正需要交互的小块（购物车、搜索框、评论区）被标记为「岛屿」并单独水合。它把水合成本从「整页」压缩到「几个组件」，是 Astro 的核心主张，也是目前性价比最高的一套性能方案。判断标准很简单：如果页面九成是内容、一成是交互，就不该为那一成交互付出整页水合的代价。

• Resumability（可恢复性）：Qwik 提出的激进方案：彻底不做水合。服务端把组件状态与事件处理器的位置序列化进 HTML，客户端加载时「从中断的地方继续执行」，只下载被真正触发的那段交互代码。理论上无论应用多大，首屏 JS 都接近恒定，直接从根上消灭了水合税。代价是心智模型全新、调试困难、生态极小，因此更适合首屏极度敏感的营销页与电商页。

• RSC（React 服务端组件）：只在服务端执行、代码不会下发到浏览器的 React 组件：它们可以直接读数据库、访问文件系统，把渲染结果（而非组件代码）流式传给客户端。它让「服务端逻辑」与「客户端交互」在同一棵组件树里混合，是 React 自 Hooks 以来最大的架构变化。特别注意：RSC 不等于 SSR——RSC 的产物是组件树描述，SSR 的产物是 HTML，两者通常配合使用。

• PPR（部分预渲染）：Partial Prerendering：把页面拆成静态外壳（构建时生成，立即推送给浏览器）与动态内容（请求时渲染，流式填充）两部分。用户先看到完整骨架，动态数据到位后局部更新。它试图同时拿到 SSG 的首屏速度与 SSR 的动态性，是渲染策略演进中「又要又要」的一次认真尝试。

• 流式渲染：服务端不等所有数据就绪再返回，而是把已就绪的 HTML 分块流式推送给浏览器，配合 Suspense 实现「先到先显示、慢的稍后补」。它显著改善了存在慢数据源场景下的首屏体验，是 React 18+ 与 Next.js App Router 的重要能力，也是把「最慢的接口」从首屏关键路径上摘除的关键手段。

• 同构渲染：同一套组件代码既能在服务端渲染出 HTML、又能在客户端激活交互，也称 Universal。它避免了「一套服务端模板 + 一套客户端 SPA」的重复开发，但要求代码不能依赖浏览器专有 API（或必须做环境判断与降级），这是所有 SSR 方案的基础假设，也是 SSR 项目最常见的踩坑来源。

• 微前端：把大型前端应用拆成多个可独立开发、独立部署的子应用，各子应用甚至可以使用不同框架，由容器应用统一集成与路由。它解决的是「多个团队协作一个巨型应用」的组织问题，而不是技术问题。代价是样式隔离、共享依赖、跨应用通信都变得复杂，且容易造成依赖重复加载，因此只适合确实存在多团队并行的场景。

响应式与状态管理

• 响应式（Reactivity）：当数据变化时，依赖它的界面自动更新，而不需要开发者手动去操作 DOM。这是现代框架区别于 jQuery 的根本特征，也是本文贯穿始终的主线之一。实现路径主要有三条：脏检查（AngularJS）、虚拟 DOM diff（React 与 Vue 2）、细粒度依赖追踪（Vue 3 的 Proxy、Solid 与 Svelte 的 Signals）。理解一个框架属于哪条路径，就能预判它的性能特征与调优方式。
• 双向绑定：视图与数据相互绑定：数据变化驱动界面更新，用户在界面上的输入也自动写回数据（如 ng-model、v-model）。它在表单密集的管理后台里写起来极为爽快，但在大型应用中容易造成「不知道数据究竟在哪个环节被改掉」的调试困境。这正是 React 坚持单向数据流、以及 Vue 在 3.x 中更强调单向传递的重要原因。
• 单向数据流：数据只能从父组件流向子组件——props 向下传、事件向上抛，任何状态变更都必须走明确的入口（如 dispatch 一个 action、调用一次 setState）。它牺牲了一点点书写便利，换来的是可预测性与可调试性：任何一次界面变化都能追溯到某一次明确的状态变更。这是 Flux/Redux 与 React 最核心的设计主张。
• MVC / MVP / MVVM：三种经典的界面分层架构，区别主要在于「谁持有视图逻辑、谁负责更新」。MVVM 用 ViewModel 作为 View 与 Model 之间的桥梁，通过数据绑定自动同步两者，典型实现是 Knockout、AngularJS 与 Vue 2，它把开发者从「手动同步 DOM 与数据」中解放出来，是 2010 到 2015 年的主流范式。随着组件化与单向数据流兴起，这三个词在新项目里已很少被提起，但它们的分层思想仍隐含在每个框架里。
• Flux：Facebook 在 2014 年提出的应用架构思想，核心是「单向数据流 + 集中式 Store」：Action 经 Dispatcher 进入 Store，Store 变更后再驱动 View 更新。它本身不是一个库而是一套约束，Redux 是它最著名的实现，Vuex 也借鉴了同样的思路。它要解决的问题很明确：传统 MVC 在大型应用中数据流双向交织，出问题时根本无法追踪来源。
• Redux：2015 年由 Dan Abramov 与 Andrew Clark 发布的 Flux 实现，用单一 Store、纯函数 reducer、不可变数据这三件套实现可预测的状态管理，配合时间旅行调试一度成为 React 项目的标配。对它的批评集中在样板代码过多——实现一个功能要在 action、reducer、常量三处来回改。如今官方推荐使用 Redux Toolkit 大幅简化写法，而大量场景已被 Zustand、TanStack Query 等更轻的方案取代。
• Vuex：Vue 2 时代的官方状态管理库，基于 Flux 思想，用 state、mutations、actions、getters 组织状态。它长期被诟病的两点是：mutations 与 actions 职责重叠（同步改还是异步改的区分令人困惑），以及 TypeScript 支持很弱。Vue 3 时代官方已明确改用 Pinia 作为继任者。
• Pinia：Vue 3 的官方状态管理库，也是 Vuex 的继任者。它去掉了 mutations，只保留 state、getters、actions，API 更接近普通对象；同时原生支持 TypeScript 类型推断，并且每个 store 独立定义、不再需要嵌套 modules。对于新的 Vue 项目，它应该是默认选择而非可选项。
• Zustand：轻量的 React 状态管理库：用一个 create() 函数创建 store，通过 Hook 订阅，甚至不需要用 Provider 包裹整个应用。它体现了 React 社区近年明显的「去样板化」趋势——把 Redux 的仪式感压缩到几行代码。适合中小规模的全局状态；非常复杂的场景仍需配合其他方案。
• Jotai：原子化的 React 状态管理库：状态被拆成一个个独立的 atom，组件只订阅自己真正用到的 atom，因此更新粒度极细、通常无需手动做重渲染优化。它的模型接近 Signals 与 Recoil，适合需要精确控制更新范围、或状态结构天然分散的场景。
• Recoil：Meta 在 2020 年发布的 React 状态管理实验库，同样采用 atom 与 selector 的原子化模型，支持异步状态与派生状态。它的历史贡献是验证了「细粒度订阅」在 React 中确实可行，为后来的 Signals 浪潮提供了实践依据；但它长期停留在实验状态、维护不活跃，实际项目更常选择 Jotai 或 Zustand。
• MobX：基于「透明响应式」的状态管理库：用 observable 标记数据、computed 定义派生值，框架自动追踪哪些组件用到了哪些数据，并精确更新。它的心智模型是「像操作普通对象一样改状态，界面自己会更新」，与 Redux 的显式不可变更新形成鲜明对比。这一思路在 Vue 生态是绝对主流，在 React 生态则属于少数派。
• Signals（信号）：一种细粒度响应式原语：每个 signal 是一个可读写的容器，读取它的地方自动成为订阅者，写入时只通知真正读过它的订阅者，从而绕过虚拟 DOM diff 直接定位到要更新的 DOM 节点。2023 年之后它几乎成为全行业共识——Vue 3.6 的 alien-signals、Svelte 5 的 Runes、Angular 的 Signals、Solid 与 Qwik 的自研实现，都不约而同走向同一个方向。本文把它视为继虚拟 DOM 之后的下一代响应式范式。
• 依赖收集：响应式系统的关键机制：在数据被读取（get）时记录「谁在读我」，在数据被写入（set）时通知这些订阅者。Vue 2 用 Object.defineProperty 拦截读写，Vue 3 与现代框架改用 Proxy，Solid 与 Svelte 则进一步在编译期就把依赖关系确定下来。它是「自动更新」这件事能够成立的技术基础，也决定了各框架在新增属性、数组索引等边界情况下的表现差异。
• 脏检查：Dirty Checking：AngularJS 的做法——不去追踪具体依赖关系，而是在每次事件后遍历所有 watcher、比较新旧值，反复循环直到数据稳定。它的优点是实现简单、对数据没有侵入；致命缺点是当 watcher 数量上千时性能急剧下降，且循环上限会抛出著名的 digest 迭代错误。这是 AngularJS 被诟病最多的一点，也直接促使 React 与 Vue 用完全不同的方案取而代之。
• 不可变数据：更新时不修改原对象，而是返回一个新对象（如 […list, item]）。它让「数据是否变化」只需比较引用即可判断，极大简化了变更检测——React 的 setState 与 Redux 的 reducer 都依赖这一约定。代价是会产生大量临时对象，因此在深层嵌套结构上需要结构共享（如 Immer 提供的写时复制）来避免深拷贝开销。
• Hooks：React 16.8（2019）引入的能力：useState、useEffect、useMemo 等让函数组件也能持有状态与副作用，从而取代了绝大多数 class 组件的场景。它彻底改变了 React 的写法与整个生态，并直接影响了 Vue 的 Composition API 与 Svelte 的 Runes 设计。代价是引入了闭包陷阱、依赖数组与调用顺序等必须遵守的规则，至今仍是新手最容易踩坑的地方。
• Context：React 内置的跨层级数据传递机制：用 Provider 提供值、useContext 消费，避免逐层透传 props。它非常适合主题、语言、当前登录用户这类低频变化的数据；但对于高频变化的状态，Context 更新会导致所有消费者一起重渲染，性能不如细粒度的状态库。把它当成「轻量版 Redux」来用是最常见的误用。

框架与元框架

• jQuery：2006 年 John Resig 发布的 JavaScript 库，用类似 $(selector) 的统一选择器抹平各浏览器的 DOM 操作差异，并提供链式调用、事件、动画与 AJAX 封装。在浏览器严重碎片化的年代，它让开发者不必再为 IE 写兼容分支，因此统治了将近十年。它的衰落不是因为做得差，而是因为：浏览器标准化之后「抹平差异」的价值消失了，同时 SPA 需要的是状态驱动的声明式更新，而非一步步操作 DOM 的命令式写法。
• Backbone：2010 年 Jeremy Ashkenas 发布的轻量 MVC 库，提供 Model、Collection、View、Router 与事件系统，是最早让前端代码具备结构的方案之一。它的哲学是「只给骨架、不做绑定」——视图更新仍然要开发者手写，因此在 AngularJS 与 React 相继出现后迅速被取代，但它确立的「前端也要有 Model 与 Router」的观念影响深远。
• Knockout：2010 年发布的 MVVM 库，以「声明式绑定 + 依赖追踪的 observable」著称，是最早把数据绑定做扎实的方案。它的 observable 思想深刻影响了后来的 Vue 与 MobX——可以说 Vue 的响应式系统里能看到 Knockout 的影子。因性能模型与生态规模的限制，它未能延续到下一个时代。
• Ember：2011 年发布的「约定优于配置」全栈式框架，由 Rails 核心贡献者 Yehuda Katz 等人创建，内置路由、数据层（Ember Data）、CLI 与极其严格的升级路径。它的强约定让大团队能长期保持一致，代价是学习成本高、灵活性低。它是「元框架」思路最早的完整实践——本文第 10 章讨论的 Next.js 与 Nuxt，许多理念都能追溯到 Ember。
• AngularJS（Angular 1.x）：Angular 1.x 的专有叫法（2010—2016），与 2016 年之后重写的 Angular 2+ 是两个完全不兼容的产品，这也是前端史上最著名的一次断裂式升级。它以双向绑定、依赖注入与指令（directive）著称，是第一个让「用增强的 HTML 写应用」成为主流的框架。2018 年进入长期支持阶段，2022 年正式停止支持。
• Angular（2+）：Google 主导的全能型前端框架，2016 年在 AngularJS 之上彻底重写而来：TypeScript 优先、组件化、依赖注入、RxJS 深度集成。它每 6 个月发布一个大版本，到 2026 年已发布至 22，并改为 12 个月周期；需要注意的是 19 及更早版本已经结束支持，升级必须按 19→20→21→22 逐版本进行，不可跳版。它的优势是「开箱即用的完整方案」与强约定，适合大型企业与长期维护项目；代价是学习曲线陡峭、历史包袱重。
• React：Meta（Facebook）2013 年开源的 UI 库，核心主张是「界面是状态的函数」与单向数据流，用虚拟 DOM 加 diff 把声明式描述转换成最小 DOM 操作。它的四次架构跃迁构成本文第 6 章的主线：Fiber（16）、Hooks（16.8）、并发渲染（18）、服务端组件（19）。React 只解决视图层，路由、状态、数据请求全部交给生态，因此极度灵活但选型成本高。2026 年 2 月 React 归入 Linux 基金会，治理结构发生实质变化。
• Vue：尤雨溪 2014 年发布的渐进式框架，核心主张是「可以只用一部分，也可以全用」——从在老页面里引入一个 script 增强局部交互，到完整 SPA，都不需要推翻重来。它用模板语法加响应式系统显著降低了上手门槛：2.x 采用虚拟 DOM，3.x 改用 Proxy 响应式并引入 Composition API，3.6 起提供可跳过虚拟 DOM 的 Vapor Mode。它在中国与欧洲的中小企业中份额很高，而文档质量是它最被公认的竞争力。
• Svelte：Rich Harris 2016 年提出的「把框架编译掉」的思路：没有运行时虚拟 DOM，组件在构建阶段就被编译成直接操作 DOM 的原生代码，因此包体积极小、运行时开销极低。2024 年 10 月 Svelte 5 正式发布，引入 Runes 作为显式响应式原语，这是一次不兼容的范式升级。配套的 SvelteKit 是它的官方元框架。它的理念深刻影响了后来的 Vue Vapor Mode。
• Solid：Ryan Carniato 创建的细粒度响应式框架：语法神似 React（JSX 加 Hooks 风格写法），底层却完全不同——组件只在初始化时执行一次，之后依靠 Signals 精确更新 DOM，既没有虚拟 DOM 也没有重渲染概念。它在各类性能基准中长期名列前茅，代价是生态规模与工具链成熟度远不及三大框架。
• Qwik：Builder.io 推出的框架，主打可恢复性（Resumability）：不做水合，把状态与事件处理器位置序列化进 HTML，首屏 JavaScript 量接近恒定。它解决的是「应用越大首屏越慢」这一根本矛盾，但心智模型与调试方式都是全新的，且 2025 年末转为独立社区治理。适合对首屏时间极度敏感的营销页与电商页。
• Preact：React 的 3KB 轻量替代品，API 高度兼容——通过 preact/compat 可以直接运行大量 React 生态库，代价是去掉了 React 中较少使用的部分（如合成事件系统）。它适合体积敏感的场景，或需要把组件嵌入第三方页面的情况，也是 Astro 等框架推荐的选项之一。
• Lit：Google 推出的轻量库，构建在 Web Components 标准之上，提供响应式属性与高效的模板更新（基于 tagged template）。它的定位是「浏览器原生的组件层」：产物是标准自定义元素，因此可以被任何框架甚至纯 HTML 页面直接复用，常用于设计系统、微前端集成与嵌入式组件。
• Alpine：极轻量的「HTML 增强」库，让你直接在标签上写 x-data、x-on:click 这类属性来实现交互，完全不需要构建步骤。它被称为「Tailwind 时代的 jQuery」——非常适合给服务端渲染的页面加一点点交互（下拉菜单、弹窗、Tab 切换），但不适合构建复杂 SPA。
• 元框架：Meta-framework：建立在某个 UI 框架之上、补齐路由、数据加载、渲染模式与部署能力的上层框架，例如 React 之上的 Next.js 与 Remix、Vue 之上的 Nuxt、Svelte 之上的 SvelteKit。2020 年之后，前端的主要创新从框架本身转移到了元框架层——「选 React 还是 Vue」的重要性下降，「选哪个元框架」反而成为真正的架构决策。
• Next.js：Vercel 维护的 React 元框架，2016 年发布，是最早把 SSR/SSG 工程化、也是目前最主流的 React 生产方案。它先后引入了文件路由、ISR、App Router（基于 RSC）与 Server Actions。需要留意的风险：2025 年底 RSC 相关实现连续曝出高危漏洞（如 CVE-2025-55182），Next.js 自 2026 年 7 月起改为月度安全发布节奏，使用 RSC 的项目应建立跟进安全公告的流程。
• Nuxt：Vue 生态的元框架，2016 年发布，提供文件路由、SSR/SSG、自动导入与模块生态（Nuxt Modules）。Nuxt 4 进一步强化了目录约定与类型支持，2026 年 3 月的 4.4 版本引入了 Vue Router v5。它是 Vue 项目做服务端渲染时的默认选择，也是 Vue 阵营对抗 Next.js 的主力。
• Remix：由 React Router 团队创建的 React 元框架，主张「拥抱 Web 标准」——用 HTML form 与 HTTP 语义表达数据变更，用 loader 与 action 处理数据读写，因此天然支持渐进增强：即使 JavaScript 尚未加载完成，表单依然可用。Remix v2 之后与 React Router v7 走上合并路线，强调应用的韧性与简单心智模型。
• SvelteKit：Svelte 的官方元框架，基于 Vite 构建，提供文件路由、SSR/SSG、服务端 load 函数与 form actions。它把 Svelte 的编译期优势延伸到全栈场景，产物体积极小，是内容型站点与性能敏感项目的强力选项，也让 Svelte 从「玩具框架」变成可用的生产方案。
• Astro：以「内容优先」为定位的元框架，核心是岛屿架构与默认零 JavaScript——页面默认渲染为静态 HTML，只有显式标记了 client 指令的组件才会下发 JS。它最大的特色是支持在同一页面里混用 React、Vue、Svelte、Solid 的组件。2026 年 1 月被 Cloudflare 收购。它适合博客、文档、营销站等内容型站点，是本文第 19 章在「内容为主」场景下的首推。
• TanStack：一个以「无头（headless）、框架无关、类型安全」著称的工具库家族，包含 TanStack Query（数据请求与缓存）、TanStack Router（类型安全路由）、TanStack Table 与 TanStack Start（全栈框架）等。它的走红反映了一个明确的生态趋势：把逻辑与界面彻底解耦，让同一套能力同时服务 React、Vue、Solid 等多个框架。
• Vapor Mode：Vue 3.6 引入的编译策略：组件可以绕过虚拟 DOM，被直接编译为精确的 DOM 操作指令，性能与内存占用接近 Solid 与 Svelte，同时模板语法完全不变。它的意义在于——虚拟 DOM 首次成为主流框架里的「可选项」，开发者可以按组件粒度决定是否启用。本文把它列为 2026 年最重要的架构信号。
• Runes（符文）：Svelte 5 的显式响应式原语，以 $ 符号开头：state 表示状态、derived 表示派生值、effect 表示副作用、props 表示组件属性等。它取代了 Svelte 4 那种「靠编译器猜测哪个 let 声明是状态」的隐式魔法，让响应式边界显式可控、也更容易被工具分析，代价是升级到 Svelte 5 需要改写组件代码。
• Zoneless（无 Zone）：Angular 移除 zone.js 的现代化方案：不再靠拦截所有异步事件来「猜测何时需要变更检测」，而是用 Signals 显式通知框架哪里发生了变化。它显著减少了无谓的检查次数、降低包体积、改善调试体验，是 Angular 近年最重要的性能改进，也标志着 Angular 在响应式路线上与 Signals 阵营合流。
• Zone.js：Angular 用来实现自动变更检测的库：它给浏览器几乎所有异步 API（setTimeout、事件监听、Promise、XHR）打上补丁，任务结束后通知 Angular 跑一遍变更检测。这个设计让开发者「什么都不用做界面就会更新」，代价是性能不可控、调试调用栈变深、与部分第三方库冲突。它最终被 Zoneless 方案取代。
• 依赖注入（DI）：组件不自己创建所依赖的对象（如 HttpClient），而是声明「我需要什么」，由框架在构造时把依赖注入进来。它让代码与具体实现解耦，便于单元测试（可以注入 mock）与运行时替换。Angular 从 1.x 起就把依赖注入作为核心机制，这也是它与 React、Vue 在设计哲学上最显著的差异之一。
• RxJS：Reactive Extensions for JavaScript：基于 Observable 的响应式编程库，提供 map、switchMap、debounceTime 等上百个操作符来编排异步流。Angular 深度集成它（HttpClient 直接返回 Observable），它非常擅长处理复杂的异步场景，如搜索防抖、请求竞态取消、多数据源合并。但操作符数量庞大、调试困难，也是 Angular 被认为难上手的主要原因之一。
• Observable：表示一个「随时间推移可以产生多个值」的数据流，可以被订阅，并支持变换、过滤与组合。它与 Promise 的关键区别是：Promise 只产生一个结果且创建后立即执行，Observable 可以产生多个值且通常是惰性的（只有被订阅才执行），还能取消。它是 RxJS 的核心抽象。
• 指令（Directive）：在模板中以属性或标签形式出现、用来给元素附加行为的标记。Angular 中指令分为组件指令、结构指令与属性指令（如条件渲染与列表循环）；Vue 中则以 v- 前缀出现（v-if、v-for、v-model）。它是「声明式」思想的具体载体——开发者描述想要什么效果，而不是一步步指挥 DOM 怎么做。
• 管道（Pipe）：在模板中对数据进行格式化展示的机制，Angular 称 Pipe、Vue 中也有同名概念，写法如把价格套上货币格式。它把展示层的格式化逻辑从组件代码中抽离出来，让模板保持简洁。需要注意的原则是：管道只负责展示，不应该承载业务计算，否则会让逻辑散落在模板里难以测试。
• 生命周期：组件从创建、挂载、更新到销毁所经历的各个阶段，框架在每个阶段提供钩子供开发者介入（如 mounted、useEffect、onDestroy）。理解生命周期是排查「内存泄漏、重复请求、拿到 undefined 的 DOM」这类问题的关键。各框架的模型差异很大：Vue 有明确的挂载与更新钩子，React 函数组件则把大部分场景统一收敛到 useEffect。
• 副作用：组件渲染之外的操作：发起网络请求、订阅事件、手动操作 DOM、写本地存储等。声明式框架要求渲染过程是「纯」的（同样的状态必然产出同样的界面），因此副作用必须放在明确的入口（useEffect、watchEffect、onMounted）并且通常需要返回清理函数，否则极易造成内存泄漏或请求竞态。
• 组件化：把界面拆成独立、可复用、自包含（结构加样式加行为）的单元。它是现代前端的基石，解决了「一个页面几千行 jQuery 代码」的维护灾难。真正的难点从来不在拆分，而在组件之间的通信方式、状态的归属划分，以及复用逻辑的抽象——Hooks 与组合式函数就是为了最后一件事而诞生的。
• Fiber：React 16（2017）重写的内部调度架构，把渲染工作拆成一个个可中断、可恢复、可设置优先级的单元（fiber 节点）。它解决的是「庞大的组件树一次性渲染会长时间占用主线程」的问题，为后来的并发渲染、Suspense 与时间切片打下基础。这是一次几乎不改动公开 API 的内部重构，被公认为 React 团队最成功的架构决策。
• Suspense：React 提供的声明式加载边界：组件在等待异步内容（代码或数据）时，由最近的 Suspense 边界显示占位内容，就绪后自动切换。它把「加载状态」从每个组件内部的手写判断，提升为组件树上的一层声明，配合流式服务端渲染与 RSC 使用时效果最佳。
• 并发渲染：React 18 的核心能力：允许渲染过程被中断、恢复、跳过或按优先级重新排序，从而让「响应用户输入」优先于「执行大量计算」。它通过 useTransition 与 useDeferredValue 等 API 暴露给开发者。需要准确理解的是：并发渲染改变的是调度方式，它并不让渲染本身变快，而是让卡顿变得不可见。
• JSX：JavaScript 的语法扩展，允许在 JS 代码中直接书写类 HTML 的标签结构，编译后变成普通的函数调用。它让「结构」与「逻辑」写在同一处，争议一直很大，但确实显著提升了组件的表达能力。Vue 与 Solid 同样支持 JSX，只是它们各自更推荐使用模板语法。
• Portal（传送门）：把组件渲染到 DOM 树的另一个位置（通常是 body 下），但逻辑上它仍然属于原来的组件树，因此事件冒泡与上下文传递照常工作。它解决了弹窗、抽屉、悬浮提示被父级容器的溢出隐藏或层级上下文裁切的经典问题。Vue 中的对应概念叫 Teleport。
• 渐进式：Vue 的核心设计主张：框架可以逐层采用，从在老页面里引入一个 script 增强局部交互，一路用到完整的单页应用，都不需要推翻重来。它大幅降低了采用门槛，是 Vue 能在中小企业快速普及的关键。含义相近但不同的词是「渐进增强」——先保证基础功能可用，再叠加高级能力。
• 声明式：描述「界面应该长什么样」，由框架负责把它变成现实；与之相对的是命令式。声明式是 React、Vue、Svelte 的共同基础，它让界面与状态一一对应，因而可以被推导、测试与优化。代价是开发者失去了对更新时机的精确控制，必须理解框架的重渲染规则才能做性能优化。
• 命令式：直接描述操作步骤——选中这个节点、改它的文本、给它加个类名，jQuery 就是典型代表。它的优势是直观、完全可控、没有框架开销；劣势是当状态变多时，需要手动同步的地方呈指数增长，稍有遗漏就会出现界面与数据不一致。
• 函数式：把计算视为函数的组合，尽量避免共享状态与副作用的编程范式。在前端的具体体现是：纯函数组件、不可变数据、用 Hooks 组合复用逻辑。它提升了代码的可测试性与可推理性，React 那句「界面是状态的函数」正是这一思想的直接产物。
• 约定优于配置：框架预设一套目录结构与命名规则，开发者只要按约定放文件就能自动获得路由、布局等能力，无需编写配置文件。Ember 与 Rails 是早期代表，Next.js 与 Nuxt 的文件路由是现代代表。它大幅提升开发效率，代价是「不按约定就要绕开框架」，灵活性被约束。

构建工具链

• Webpack：2012 年发布、2015 年后成为事实标准的模块打包器，以 loader 与 plugin 机制把 JS、CSS、图片等一切资源都当作模块处理，并提供了代码分割、热更新、Tree Shaking 等关键能力。它的强大与复杂是一体两面：配置文件繁琐、大型项目构建缓慢，而这正是后来 Vite 与 esbuild 能够崛起的直接原因。

• Vite：尤雨溪 2020 年发布的构建工具：开发时利用浏览器原生 ESM 按需编译，不需要先把整个应用打包完，因此冷启动与热更新都极快；生产构建则使用 Rollup。它重新定义了前端的开发体验，并成为 Vue、Svelte、Solid 等框架的默认工具。Vite 8 起改用 Rust 编写的 Rolldown 作为统一内核，消除开发与生产两套引擎的差异。

• Rollup：专注于库打包的构建工具，以输出产物干净、Tree Shaking 效果好著称。它是 Vite 生产构建的默认内核，也是众多开源库的打包选择。它不太适合直接用于应用开发（缺少开发服务器等配套能力），但作为被嵌入的「打包引擎」被广泛使用。

• esbuild：用 Go 编写的极快打包器与转译器，因为直接编译为原生代码且高度并行，速度通常比 Webpack 与 Babel 快一到两个数量级。它的意义在于证明了「换一门语言重写工具链」能带来数量级的性能提升，直接启发了后来的 Rust 系工具（Rspack、Rolldown、Turbopack）。在 Vite 中它常用于依赖预构建与 TypeScript 转译。

• Rspack：字节跳动开源的 Rust 版打包器，高度兼容 Webpack 的配置与插件生态，主打「配置基本不用改、构建速度快 5 到 10 倍」。对于有大量存量 Webpack 配置的大型项目，它是迁移成本最低的提速方案。2026 年已发布 2.x 版本。

• Turbopack：Vercel 用 Rust 编写的打包器，定位为 Webpack 的继任者与 Next.js 的默认构建引擎。它针对增量计算做了深度优化（函数级缓存），目标是让项目无论多大，更新耗时都接近恒定。目前主要在 Next.js 生态内使用。

• Rolldown：用 Rust 编写的 Rollup 兼容打包器，由 Vue/Vite 团队主导，目标是成为 Vite 统一的开发与生产内核，从而消除「开发用 ESM 按需编译、生产用 Rollup 打包」这种双引擎带来的行为差异。Vite 8 已将其设为默认，Rolldown 1.0 于 2026 年 5 月发布。

• Parcel：零配置打包器，主打开箱即用——不需要写配置文件，自动识别并处理各类资源。它在 2018 年前后以极低的上手门槛著称，但在需要深度定制的大型项目中不如 Webpack 灵活；随着 Vite 出现（同样易用但更快、生态更好），它逐渐被边缘化。

• Grunt：2012 年前后的任务运行器，用配置对象描述压缩、合并、编译等一系列任务。它正式开启了前端工程化的序幕，但因为配置冗长、且任务之间靠临时文件传递中间结果（很慢），很快被后来的 Gulp 取代。

• Gulp：基于流（stream）的任务运行器：用代码而非配置描述构建流程，中间结果在内存中传递，因此比 Grunt 明显更快。它在 2014 到 2016 年是主流方案，但随着 Webpack 把「打包」这件事整体接管，单纯的任务编排需求减少，Gulp 逐步退场。

• Browserify：2011 年发布的工具，让 Node.js 风格的 require 语法能在浏览器中直接使用，从而把 npm 生态第一次带进前端。它是前端模块化进程中的关键一步，也是 Webpack 出现之前最主流的打包方案。

• HMR（热模块替换）：Hot Module Replacement：修改代码后不刷新整个页面，只替换发生变化的模块，并尽量保留应用当前状态（已填写的表单、组件内部状态）。它极大提升了开发效率，是现代开发服务器的核心能力，也是开发者体感上最明显的体验差异来源。

• Tree Shaking（摇树优化）：基于 ESM 静态结构的分析，把没有被真正 import 的导出从最终产物中剔除，就像摇动树木把枯叶摇下来。它依赖 ESM（CommonJS 无法静态分析），并且要求库正确声明副作用标记。它是「引入一个库却不会让包体积失控」的技术基础。

• 代码分割：把打包产物按路由或组件拆成多个文件，访问时只加载当前需要的那一部分。它解决了单页应用「首屏必须下载整个应用」的问题，是首屏性能优化最有效的手段之一，通常通过动态 import 语法配合框架级懒加载实现。

• 懒加载：资源（代码、图片、组件）在真正需要时才加载，而不是一开始全部下载。它是代码分割的目的所在，常见用法是路由级懒加载与图片延迟加载。需要注意过度懒加载会造成「点击后要等待」的卡顿感，必须与预取策略一起权衡。

• 冷启动：开发服务器从启动到可用所耗费的时间。传统的打包式工具需要先把整个应用打包完才能启动，项目越大越慢；而 Vite 这类按需编译的工具几乎瞬间启动。冷启动时间直接决定开发者的日常体感，是 Vite 能够迅速取代 Webpack 的关键原因之一。

样式方案

• Sass / SCSS：最成熟的 CSS 预处理器，提供变量、嵌套、mixin、函数与模块化能力，让 CSS 具备基本的编程能力。它曾是大型项目的标配；随着 CSS 原生支持自定义属性（变量）与嵌套语法，以及原子化方案兴起，它的必要性在下降，但在海量存量项目中仍是主流。
• Less：另一个 CSS 预处理器，语法比 Sass 更接近原生 CSS、上手更简单，早期因为被 Bootstrap 采用而广泛流行。随着 Sass 与 PostCSS 的竞争，以及原生 CSS 能力的补强，它在新项目中的使用率持续下降。
• PostCSS：用 JavaScript 插件处理 CSS 的平台：它本身什么也不做，能力完全来自插件，例如自动添加浏览器前缀、语法降级、展开嵌套、支持未来语法。它通常作为 Tailwind 或 Sass 之外的底层处理层，存在于构建链路中被间接使用。
• CSS Modules：一种默认局部作用域的 CSS 方案：构建时把类名编译成唯一哈希值，从根本上避免全局类名冲突。它没有运行时开销、可生成类型定义供 TypeScript 使用，是在「保持原生 CSS 写法」与「获得样式隔离」之间最平衡的折中方案。
• CSS-in-JS：把样式写进 JavaScript 代码里（如 styled-components、Emotion），借助 JS 的能力实现动态样式、主题切换与按需注入。它的优势是样式与组件同生共死、天然无全局污染；代价是存在运行时开销、服务端渲染配置复杂。随着零运行时的编译型方案成熟，它的热度已明显回落。
• Tailwind CSS：原子化 CSS 框架：提供大量单一职责的工具类，直接在标记中组合出需要的样式。它的真正价值并不在于「少写 CSS」，而在于消除命名负担与设计不一致——样式被约束在一套设计令牌之内，团队产出因此天然统一。主要争议是标记层变得冗长、可读性下降。
• UnoCSS：按需生成的原子化 CSS 引擎，比 Tailwind 更灵活（支持完全自定义规则与预设），并且由于是即时生成而非预生成，产物更小、构建更快。它由 Vue 社区的 Anthony Fu 创建，代表原子化思路的进一步演进。
• 原子化 CSS：每个类名只做一件事（一个属性对应一个值），通过组合而非新写规则来得到最终样式。它让 CSS 总体积趋于收敛——因为复用度极高，新增功能几乎不再增加样式体积。代价是标记层变长，需要配套工具与团队规范来约束。
• BEM：Block、Element、Modifier 的缩写，一种 CSS 命名约定，写法如 块__元素–修饰符。它在全局 CSS 时代用命名规范人为制造出作用域与语义关系，曾是大型项目的主流规范。随着 CSS Modules、CSS-in-JS 与原子化方案提供了真正的作用域隔离，BEM 的必要性下降，但它的块层思想仍有价值。
• Design Tokens（设计令牌）：把颜色、间距、字号、圆角、阴影等设计决策抽象为与平台无关的变量（通常是 JSON 描述），再编译输出到 Web、iOS、Android 以及设计工具中。它解决了设计与代码长期不一致的根源问题——设计稿改了主色，各端只需重新编译令牌即可同步。它是设计系统真正落地的技术基础。

路由与数据请求

• 路由（Router）：把 URL 映射到对应界面或组件的机制。前端路由在单页应用中通过 History API 拦截地址变化、不刷新页面地切换视图，并支持嵌套路由、路径参数、导航守卫与数据预加载。它与数据请求并称为单页应用的两条主动脉。
• React Router：React 生态事实上的标准路由库，历经 v4 的「路由即组件」重写、v6 的嵌套路由与 Hooks 化，到 v7 与 Remix 合流、具备数据加载与服务端能力。它的演进本身就是理解 React 单页应用架构变迁的一个缩影。
• Vue Router：Vue 官方路由库，提供嵌套路由、动态路由、导航守卫与路由级懒加载，并与 Vue 的响应式系统深度配合。Nuxt 4.4 起引入 Vue Router v5。它是 Vue 单页应用的标配，也是理解 Vue 生态约定的入口之一。
• REST：一种基于 HTTP 的资源导向接口风格：用 URL 表示资源、用请求方法表示操作、用状态码表示结果。它简单、可缓存、与 Web 基础设施天然契合，至今仍是绝大多数项目的默认选择。主要痛点是接口返回粒度固定，容易出现数据取不足或取过多的情况。
• GraphQL：Facebook 2015 年开源的查询语言：客户端在一个请求里精确声明需要哪些字段，服务端严格按声明返回，从根本上解决过度获取与请求瀑布的问题。它带来强类型 Schema 与自省能力，但也引入了缓存复杂、N+1 查询、权限粒度难控制等新难题，因此更适合多端消费且字段差异大的场景。
• tRPC：让 TypeScript 前后端共享类型定义、客户端直接调用服务端函数而无需手写接口层的方案。它把「API 契约」从运行时约定变成了编译期保证，极大提升了全栈 TypeScript 项目的开发体验，但要求前后端同语言、通常同仓库，适用范围有限。
• 乐观更新：在发起写操作时先假定成功、立即更新界面，待服务端确认失败后再回滚并提示用户。它让界面交互达到「零延迟」的质感，是提升体验的关键技巧，但必须妥善处理失败回滚、并发冲突与重复提交，否则会造成界面与服务端数据长期不一致。

跨端方案

• 跨端：用一套代码覆盖多个端（Web、iOS、Android、桌面、小程序）的目标。过去四十年出现过编译型、桥接型、WebView 型、容器型等多条路线，共同难题始终是三点：性能与原生体验的差距、原生能力的覆盖度，以及「一套代码适配所有端」最终往往演变成「为每个端单独写适配代码」。
• React Native：Meta 2015 年发布的跨端框架：用 React 的写法描述界面，但渲染的是真正的原生组件（而非网页），通过桥接或 JSI 与原生模块通信。它让 Web 开发者能够产出接近原生体验的 App，是「一次学习、多处编写」的代表。代价是深度使用原生能力时仍需编写原生代码，且版本升级的兼容性问题长期突出。
• Flutter：Google 2017 年发布的 UI 工具包，使用 Dart 语言，自带渲染引擎直接绘制界面，不依赖平台原生控件。它的优势是各端表现完全一致、性能接近原生；代价是不使用平台原生组件（观感可能与系统不一致）、产物体积较大，且团队需要学习 Dart。
• Electron：用 Web 技术（Chromium 加 Node.js）构建桌面应用的框架，VS Code、Slack、Discord 都基于它。优势是 Web 开发者几乎零门槛就能产出跨平台桌面应用；代价非常直白——每个应用都打包了一整个 Chromium，内存占用与安装包体积都很大。
• Tauri：Electron 的轻量替代方案：用操作系统自带的 WebView 渲染界面、用 Rust 编写后端逻辑，产物体积与内存占用通常只有 Electron 的十分之一量级。代价是需要引入 Rust 工具链，且不同系统的 WebView 版本差异会带来兼容性问题。
• Capacitor / Ionic：Ionic 是基于 Web 组件的跨端 UI 组件库，Capacitor 是其配套的运行时容器，负责把 Web 应用打包进原生 WebView 并暴露原生 API 给 JavaScript 调用。它们是 WebView 路线的现代形态，适合内容型、表单类、对原生性能要求不高的应用。
• Cordova：早期把 Web 应用打包成原生 App 的开源容器（前身是 PhoneGap），通过插件机制调用摄像头、通讯录等原生能力。它正式开启了混合应用的时代，但因 WebView 的性能与体验差距明显，逐渐被 React Native、Flutter 与小程序取代。
• 小程序：运行于超级 App（微信、支付宝等）内部的轻量应用形态，使用自有的 DSL 与双线程架构（逻辑层与渲染层分离），兼具 Web 的发布效率与接近原生的体验。它在中国市场极端重要，也因此催生了下面这些「一套代码编译到多个小程序平台」的方案。
• uni-app / Taro：国内的「一套代码编译到多端」方案：uni-app 基于 Vue 语法，Taro 早期基于 React 语法，都能输出小程序、H5、App 等多端产物。它们解决的是国内特有的多端碎片化现实问题，代价是必须严格遵循框架约束，且深度依赖编译器做兼容性处理。
• Weex：阿里巴巴开源的跨端方案，用 Vue 语法编写、渲染到原生组件，曾被视为 React Native 的有力竞争者。因后续维护投入不足与生态萎缩，它最终被捐赠给 Apache 并逐渐停止活跃开发，是跨端路线中「投入巨大但未能持续」的典型案例。

工程化与质量

• ESLint：可配置的 JavaScript 与 TypeScript 静态检查工具，通过规则集发现潜在错误、风格问题与不安全写法，并支持自动修复。它是团队代码质量的第一道防线，配合社区共享配置（如 Airbnb 规范）可以在几天内统一全团队的编码风格。
• Prettier：有主见的代码格式化工具：它不讨论「怎样更好看」，只强制推行一种格式，从而彻底终结团队中关于缩进、换行与引号的无休止争论。它与 ESLint 有明确分工——ESLint 管代码对不对，Prettier 管代码好不好看，两者配合时需要配置以避免规则冲突。
• Jest：Meta 出品的测试框架，内置断言、Mock、覆盖率统计与快照测试，曾长期是前端测试的事实标准。它的优势是开箱即用；劣势是在 ESM 与 TypeScript 场景下配置繁琐、执行速度偏慢，因此 Vite 生态中的大量项目已改用 Vitest。
• Vitest：基于 Vite 的测试框架，直接复用 Vite 的转译能力与配置文件，因此启动极快、且与项目构建配置天然一致，同时兼容大部分 Jest 的 API。它是「工具链统一」这一趋势的典型产物，也是当前 Vite 项目的默认测试选择。
• Cypress：端到端测试工具，在真实浏览器中运行测试，提供时间旅行调试与自动等待机制，特别擅长验证「用户真实的完整操作路径」。它的开发体验优秀，但只能在 Chromium 系与 Firefox 上运行，且大规模并行执行的成本较高。
• Playwright：微软推出的端到端测试工具，支持 Chromium、Firefox、WebKit 三大引擎与多语言 API，提供自动等待、网络拦截、移动端模拟，并内置 Trace Viewer 便于定位失败原因。它已成为新项目端到端测试的主流选择。
• Monorepo（单体仓库）：把多个包或多个应用放在同一个代码仓库中统一管理，配合工作区机制实现依赖共享、统一构建与原子化提交。它解决了多仓库协作中「改一个库要发布三次才能验证」的痛苦，代价是需要额外工具（Turborepo、Nx 或 pnpm workspace）以及更精细的持续集成设计。
• 包管理器（npm / yarn / pnpm）：JavaScript 的依赖管理工具三强：npm 是 Node 官方方案与事实标准；yarn 以安装速度与确定性（引入锁文件）起家；pnpm 采用硬链接加符号链接的内容寻址存储，显著节省磁盘空间并天然杜绝幽灵依赖，近年成为新项目与单体仓库的推荐选择。无论选哪个，锁文件都是保证「所有环境装到完全相同版本」的关键，必须提交进仓库。
• 语义化版本（SemVer）：版本号格式为主版本号、次版本号、修订号，约定只有破坏性变更才升主版本号、兼容的新功能升次版本号、问题修复升修订号。它让依赖范围表达式有了明确语义，是整个 npm 生态得以运转的基础契约。现实中 0.x 版本不受此约束，且各库对「什么算破坏性」判断不一，因此锁文件仍然是必需的。
• Serverless：一种云计算执行模型：开发者只写函数代码，平台负责扩缩容与运维，按实际调用量计费。在前端语境下它通常与边缘函数结合，用于服务端渲染、A/B 分流、鉴权等轻量服务端逻辑，让前端团队无需运维即可拥有服务端能力。代价是冷启动延迟与较强的厂商绑定。
• 边缘计算（Edge Computing）：把计算放到离用户最近的 CDN 节点上执行，从而把网络往返从跨洲级别缩短到同城级别。在前端领域它支撑了边缘服务端渲染、边缘中间件与个性化分发，是 Vercel、Cloudflare 等平台竞相提供的能力，也让「前端工程师写一点服务端逻辑」成为常态。
• CDN：内容分发网络：把静态资源缓存到遍布全球的节点上，用户就近获取，从而降低访问延迟、减轻源站压力，并天然具备吸收流量峰值的能力。它是静态站点生成方案能够取得极致性能的物理基础，也是现代前端部署中不可或缺的一层。
• Vercel：Next.js 的母公司，提供面向前端的一体化部署平台——推送代码即部署、自动生成预览环境、全球边缘网络，并深度投入 Turbopack 与 AI 相关工具链。它定义了「前端云平台」这一品类，也是把 React 与 Next.js 生态商业化、并推动其快速迭代的主要力量。
• Cloudflare：全球性的边缘网络与云服务商，提供 CDN、Workers 边缘函数、R2 对象存储等产品。2026 年 1 月它收购了 Astro，这是「基础设施公司向上收购框架」的标志性事件，也让「框架治理是否中立」成为技术选型时一个新增的考量维度。

版本与支持状态查询

• Angular：angular.dev/reference/releases（官方发布与支持矩阵）
• React：react.dev/versions（含 15—19 各版本存档文档与 CHANGELOG）
• Vue：github.com/vuejs/core/releases（CHANGELOG 最权威）
• Next.js：nextjs.org/blog（含安全公告）
• 通用 EOL 查询：endoflife.date
• 安全公告：各项目 GitHub Security Advisories 页

本文档的使用方式

• 技术评审：直接引用第 17 章对比矩阵与第 19 章场景推荐
• 升级决策：对照第 5/6/7/8 章版本表确认当前版本的支持状态
• 新人培训：第 1—3 章的演进脉络可作为前端史通识材料
• 性能优化：第 18 章的三层杠杆按 P0→P2 顺序执行

数据说明：本文档版本与日期基于各框架官方发布日志、官方博客、Wikipedia 版本表及 endoflife 数据交叉核对，核实时点为 2026 年 9 月。前端生态迭代极快，次要/补丁版本请以官方 CHANGELOG 为准。

文档结构：全景时间轴 → 时代分期 → 框架族谱 → 各框架版本史与模块生态 → 工程化生态 → 横向对比 → 选型建议 → 未来趋势。