刚写前端的时候，总觉得有很多概念不清楚，也不清楚他们之间的关系，例如vue、vite、rollup的关系是什么？在这里把所有的概念梳理一下，方便新入门前端的同学。

nodejs

首先，前端最最核心的一个东西是nodejs。

想象一下，你写了一段js代码，需要运行，如果在chrome浏览器里面，这些代码的运行是交给chrome的V8引擎。在浏览器之外，就可以使用nodejs。

js并非只有在网页上使用这一个唯一的场景，例如也可以写后端。

包管理工具：npm、yarn、pnpm

有了 Node.js，我们就能在电脑里离开浏览器运行 JavaScript。可是光有引擎还不够，前端生态的“依赖包”（比如别人写好的库）要怎么领进来、管理好？这就要用到包管理工具了，就像python有pip，Rust有Cargo，node也有自己的包管理器，而且不仅有还有三个：

1. npm

Node.js 官方自带的包管理工具，也是最传统的选择。优点是绝大多数项目都支持，缺点是很慢。

2. yarn

yarn是Facebook 推出来的包管理器，解决 npm 早期的速度/一致性问题。yarn有多个版本，其中v1用法和 npm 很像，但是速度更快，依赖锁定机制也更好一些。

但是，v1版本用起来和npm很像，也就注定它必然有npm的缺点，例如巨大的粪坑node_modules文件夹。为了解决这个问题，yarn后续版本已经退出了pnp的依赖管理模式，使用一个压缩包而不是node_module文件夹管理依赖。

yarn1已经停止更新，最新的版本停在了1.22.22.截止本文撰写，yarn最新大版本是4，但是经过笔者实际尝试，目前yarn4与现有项目适配较差，尤其是使用vite+vue的项目，报错很多基本无法正常运行。

3. pnpm

一个后来者，优势是更加节省硬盘空间（通过硬链接的方式管理依赖包），在 monorepo 多包项目里尤其有优势。由于笔者本人用的较少，这里就不多说了。

三者都能完成“下载安装第三方库、管理版本、清理依赖”等任务。

构建工具：Vite, Webpack

先把“构建”说清楚：核心是“把源码（TS/ESNext、Vue SFC、JSX、CSS 预处理、图片等）转换成浏览器能高效执行/加载的产物，并在开发期提供快速反馈（热更新/HMR）”。

Vite 和 Webpack 都能负责“开发体验 + 产物输出”，但理念不同：

1. Webpack（老牌全家桶）

• 思路：一切资源皆模块，先分析整张依赖图，再整体打包（bundle）后交给浏览器。
• 优点：生态巨无霸，loader / plugin 唯一性需求几乎都能找到；历史兼容性强；可深度自定义。
• 缺点：初次构建、频繁改动重构建慢；配置项多，新手门槛高。

2. Vite（开发体验优先）

• Dev 阶段不做整包：利用浏览器原生 ESM 按需加载源码，只对“非原生语法”（TS、Vue、JSX）做按需瞬时转换，这个转换用 esbuild（Go 写的，极快）。
• Build 阶段再交由 Rollup 做优化（tree-shaking、代码分割、压缩）。所以 Vite 实际是：Dev Server (esbuild 预处理) + Rollup 打包的组合壳。
• 优点：启动秒开，HMR 快；默认配置即够用；贴合现代语法与框架。
• 缺点：极端或历史复杂场景的深度定制仍不如 Webpack 生态丰富；某些老式脚本处理需额外兼容。

一句话：Webpack 偏“先打好包再服务”；Vite 偏“先服务（原生 ESM）再最终打包”。新项目追求体验 → Vite；遗留/复杂构建链条 → Webpack 仍然稳。

（注意：很多人把 Vite 叫“构建工具”，而把底层的 esbuild/Rollup 叫“打包工具”，下面分开讲。）

打包工具：esbuild, rollup, webpack

“打包”聚焦在：解析依赖图 -> 合并/拆分 -> 优化（摇树/压缩）-> 输出浏览器或 Node 可直接部署的 bundle/chunk。

1. esbuild

• 特点：Go 实现，多线程 + 流式处理，速度极快（数量级差距）。
• 常用场景：开发期预构建、脚手架、内部工具、对最终体积要求一般但追求极致速度的任务。
• 相对不足：高级代码分割策略、生态深度（复杂插件链）不及 Rollup / Webpack。

2. Rollup

• 特长：面向 ESM，tree-shaking 精细，输出干净，适合做“库”（产出 ESM/CJS/UMD 多格式）。
• 缺点：做复杂应用需额外插件拼装，不如 Webpack “一口气全解决”。

3. Webpack

• 既能打包也有 dev server；资源类型覆盖和历史方案兼容能力极强。
• 仍在大型单页、多入口、旧代码迁移中发挥价值。

典型组合：

• Vite (dev) -> Rollup (build)，内部用 esbuild 预构建依赖 / 转换 TS。
• 只用 esbuild：快速产出一个临时或内部工具包。
• 传统：只用 Webpack 贯穿全流程。

速记：esbuild=极速，Rollup=做库/极致 tree-shaking，Webpack=大而全，Vite=体验编排层（调度 esbuild + Rollup）。

UI框架：Vue, React, Angular

都是“写界面”，定位与哲学差异很大：

1. Vue（渐进式）

• 渐进：可以只用视图层，也可加路由、状态、构建工具逐步变“全家桶”。
• 单文件组件（SFC）+ 响应式系统（3.x 用 Proxy 追踪依赖），语法直观，上手快。
• 场景：中小到中大型业务快速开发。

2. React（UI 库）

• 聚焦 state -> UI 映射，其他由生态自由组合（Router、状态、数据请求、构建方案）。
• 函数式 + Hooks，灵活度高；也更容易写出“过度抽象”或性能细节坑。
• 场景：需要高度定制、跨端（React Native/Electron）、基建成熟团队。

3. Angular（企业级框架）

• 自带：依赖注入、路由、表单、HTTP、CLI、严格结构；TypeScript 强绑定。
• 观念/概念多（Module/Component/Service/DI/RxJS），学习成本高，换来架构统一与长期可维护性。
• 场景：大型后台、长期迭代、团队需要统一规范。

一句话：想快上手 → Vue；想灵活按需拼 → React；想自带完整架构 → Angular。

旁支：Svelte / Solid / Qwik 等“新一代”值得关注，但先把主流三件套吃透即可。

模块化规范：ESM, CommonJS, AMD

为什么有这么多规范？历史演进：浏览器最初没有模块机制 -> 社区想方案（AMD）；Node 为服务器端需要（CommonJS）；最终标准委员会推出官方（ESM）。

1. CommonJS (CJS)

• 写法：const a = require('a'); module.exports = ...
• 特点：同步加载（适合服务端文件系统），导出是对象引用（修改导出对象属性可被后续 require 看到）。
• 地位：Node 旧项目大量存在，仍被支持。

2. AMD

• 写法：define(['dep'], function(dep){ ... return api })。
• 目的：浏览器异步加载，解决网络延迟阻塞。代表：RequireJS。现代新项目基本不直接写。

3. ESM (ECMAScript Module)

• 写法：import { x } from './x.js'; export default {...}
• 特点：静态可分析（构建优化/摇树更精准），浏览器原生支持 <script type="module">，live binding（实时绑定）。

补充：

• UMD：打包层面为兼容（CJS + AMD + 全局）包装一层，常见于发布库。
• IIFE：早期用立即执行函数隔离作用域的“伪模块”。
• 互操作：ESM 导入 CJS 得到默认整个模块对象；CJS require ESM 受 Node 版本、package.json 中 type 字段限制；打包工具负责大量兼容“魔法”。
• Node 通过 "type": "module" 或后缀 .mjs / .cjs 区分。

心智图：CJS=Node 老世界；AMD=浏览器历史异步方案；ESM=现在与未来。理解历史后，新代码尽量直接写 ESM。

（打包工具的价值之一：把多种模块来源统一成浏览器高效可加载的最终形式。）

总结：为什么前端看起来这么“杂乱”

不可否认，前端的概念非常多：一个“写页面”的活，怎么冒出包管理器三套、构建工具四五种、框架一堆、模块规范还分好几档？

我自己的理解，可以拆成几个层面：

1. 历史包袱演进叠加

• 浏览器最初几乎不提供工程化支持：没有模块、没有类型、没有打包、没有热更新。社区就“缺啥补啥”。
• 旧方案不能一下子废：项目还在跑，所以新/旧同时存在（CommonJS 与 ESM、Webpack 与 Vite、npm 与 yarn/pnpm）。

2. 运行环境碎片化

• 目标环境不止“最新 Chrome”，还有：旧浏览器、Node、SSR、Edge Runtime、Electron、Hybrid、微信小程序、各种嵌入 WebView。不同环境限制不同 → 工具需要做 polyfill/转译/适配。

3. 语言层“迟到的标准化”

• JS 标准更新节奏比实战需求慢。社区先造（CoffeeScript、Babel、TypeScript、各种模块格式），等标准慢慢吸收（类、ESM、可选链）。过渡阶段一定“并存 + 迁移”。

4. 性能与体验军备竞赛

• 需求：更快首屏、更少体积、更好 DX（开发体验）。
• 不同工具在不同阶段极致：esbuild 拼“速度”，Rollup 拼“输出洁净”，Webpack 拼“全能”，Vite 拼“秒启动”，Snowpack 曾经拼“原生 ESM”概念。竞赛 -> 分化。

5. 生态开放 + 进入门槛低

• JavaScript 进入门槛低，全球开发者多，迭代快；“有人不爽就能起一个新轮子”，再通过 npm 迅速传播。

6. 需求边界在扩张

• 以前只做页面，现在还要：SSR/SSG（Next/Nuxt）、同构渲染、CSR/边缘渲染、实时协作、WebGL/WebGPU、跨端（React Native/Tauri/Flutter Web）、微前端、低代码……每出现一个新场景，就会诞生一批“专用术语 + 新工具”。

7. 商业与社区驱动并存

• 大厂（Meta、Google、阿里、字节、微软）会推出解决自己内部痛点的方案，然后开源推广（React、Angular、Egg、Rspack、Turbopack 等）。它们天然带流量，促使多路线并行。

8. 旧成本 vs 新收益的摇摆

• 工具迁移不是“功能 superset 就换”，还要评估：构建脚本、插件、CI、团队认知、Bug 风险。于是老工具不会立即消亡，形成“代际同住”。

如果用一句模型来概括： “前端是需求极快膨胀 + 标准化相对滞后 + 进入门槛低 + 多运行时并存 + 旧项目庞大存量” 的交叉结果。

怎么在杂乱中不被淹：

1. 先抓“恒定核心”：HTML/CSS/JS 基础、HTTP、浏览器运行机制（事件循环、渲染、缓存、网络）。
2. 再挑“一条主线”：例如 Vue + Vite 或 React + Vite/Next，滚成可交付项目。
3. 碰到陌生名词先分类：它是“语法/标准、运行时、框架、构建层、打包层、部署/交付层、性能优化手段、工程组织模型”中的哪一类。
4. 定期“低频巡检”：每隔 3~6 个月看看生态有没有新的“范式型”变化（例如：Server Components、Edge Functions、WebGPU）。
5. 避免工具驱动学习：带着真实问题选工具，而不是“听说很火先全装一遍”。

最后的心态： 工具会淘汰，但底层原理（模块划分、依赖图、编译/打包、资源加载、渲染与状态管理、缓存策略）迁移性很高。把注意力放在“为什么需要它”而不是“API 细枝末节”，焦虑感就会下降很多。

这篇博客就是想把那些“看似散乱的名词”压扁成几条主线：运行时（浏览器/Node） -> 模块与依赖 -> 打包/构建链 -> 框架（UI 与状态） -> 交付与性能 -> 生态演化。理解链条后，再遇到新术语，只需要定位它处在链条的哪一段。