第 1 卷
深入解析：npm 安装包及四大包管理工具对比
一、npm 安装包的完整过程
你想了解 npm 安装包的底层流程，其核心是从解析依赖到落地安装的一系列有序操作，具体步骤如下：
- 命令解析与参数处理：npm 首先解析用户输入的命令（如 npm install <package>、
npm i <package> -S/-D/-g），区分局部安装（项目目录）与全局安装（系统全局 node_modules）、生产依赖（dependencies）与开发依赖（devDependencies）。
- 依赖版本解析：
◦ 先检查项目根目录的 package.json 文件，读取目标包的版本约束（如 ^1.2.3、
~4.5.0）；
◦ 结合 package-lock.json（npm 5+ 新增）或 npm-shrinkwrap.json，优先锁定已
确定的版本（保证跨环境安装一致性），若无锁定文件，则去 npm 官方仓库（registry）查询该包的最新符合版本。
- 依赖树构建：递归解析目标包的 package.json，获取其自身的依赖
（dependencies/devDependencies），逐层构建完整的依赖树，同时处理依赖冲突（如不同包依赖同一依赖的不同版本，会通过嵌套安装解决）。
- 缓存检查：npm 会先检查本地缓存目录（默认路径：Windows %USERPROFILE%.npm、
Mac/Linux ~/.npm），若缓存中存在对应版本的包，且缓存未过期，直接复用缓存，跳过下载步骤；若缓存不存在或已过期，执行下一步。
- 包下载：从配置的 registry 地址（默认 https://registry.npmjs.org/）下载对应包的压缩包（.tgz 格
式），同时将下载的包缓存到本地缓存目录，方便后续复用。
- 包解压与安装：将下载/缓存的包解压到项目的 node_modules 目录（局部安装）或全局
node_modules 目录（全局安装），并完成文件部署。
- 后续收尾操作：
- 更新 package.json：根据安装参数（-S/-D），将包名与版本添加到对应的依赖字段中；
◦ 更新 package-lock.json：记录本次安装的所有包的精确版本、依赖关系、下载地址等信
息，确保后续 npm install 能复刻相同的依赖结构；
◦ 执行生命周期脚本：若包自身或项目中配置了 preinstall、 install、
postinstall 等脚本，会按顺序执行这些脚本（如部分包需要编译原生模块）。
| 工具 | 核心差异 | 各自优势 |
|---|---|---|
| npm | 官方原生工具，早期采用嵌套 | 1. 官方标配，兼容性最好， |
| 依赖结构（npm 2），后续改 | 无需额外配置，生态支持最完 | |
| 为扁平依赖（npm 3+），无 | 善；2. 稳定性高，迭代成 | |
| 共享存储，缓存机制简单 | 熟，适合绝大多数常规项目； |
- package-lock.json 锁
定版本，保证跨环境一致性；
- 支持丰富的命令与生命周
期脚本，功能全面
| cnpm | 淘宝镜像推出的 npm 替代工 | 1. 下载速度极快（国内镜像 |
|---|---|---|
| 具，核心是修改了 registry 为 | 源，解决 npm 官方源网络卡 | |
| 淘宝镜像 | 顿问题）；2. 使用方式与 | |
| （https://registry.npmmirro | npm 完全兼容，无需额外学 | |
| r.com/），安装机制与早期 | 习成本；3. 针对国内网络环 | |
| npm 类似，依赖嵌套存储 | 境优化，包下载失败率极低 | |
| yarn | Facebook 推出，早期解决 | 1. 安装速度比早期 npm 更 |
| npm 版本不一致问题，采用 | 快，并行安装优化了依赖下载 | |
| 扁平依赖，内置缓存，支持并 | 效率；2. yarn.lock 锁定 | |
| 行安装 | 机制更严谨，版本一致性保障 |
更强；3. 内置离线模式，已缓存的包可离线复用，无需重
新下载；4. 支持工作区（workspaces），对多包管
理（monorepo）支持更友好（早期优于 npm）；5. 安装
时输出更清晰，错误提示更友好
| pnpm | 采用“内容寻址存储”+“硬 | 1. 磁盘空间占用最少（核心 |
|---|---|---|
| 链接/符号链接”机制，依赖 | 优势），相同版本包仅存储一 | |
| 非扁平存储，有独立的共享存 | 份，通过链接复用；2. 安装 | |
| 储目录 | 速度最快（远超 npm、 |
yarn、cnpm），并行安装 +缓存复用+无依赖冗余解
析；3. 依赖隔离性最好，避免“幽灵依赖”（仅能访问
package.json 声明的依
- 兼容 npm 命令与
package.json 格式，迁移成本低
补充核心差异总结：
- 存储机制：npm/yarn/cnpm 为扁平存储（npm 3+），pnpm 为共享存储+链接机制；
• 性能排序（安装速度+磁盘占用）：pnpm > yarn > cnpm > npm（最新版 npm 已优化，差距缩
小，但 pnpm 仍领先）；
• 网络优化：cnpm 依赖国内镜像，npm/yarn/pnpm 可手动配置镜像，pnpm 缓存跨项目复用更
强；
- 依赖隔离：pnpm 完全隔离，无幽灵依赖；npm/yarn/cnpm 存在幽灵依赖问题。
三、pnpm 存储结构减少磁盘占用+提高安装速度的原理
pnpm 之所以能在磁盘占用和安装速度上远超其他工具，核心在于其独特的 “共享存储（contentaddressable store）” + “硬链接（hard link）” + “符号链接（symbolic link）” 组合设计，
具体原理如下：
- 减少磁盘空间使用的核心原理
• 全局共享存储目录：pnpm 会在系统中创建一个全局共享存储目录（默认路径：Windows
%LOCALAPPDATA%\pnpm\store、Mac/Linux ~/.pnpm-store），所有项目安装的包，都会先将包的完整内容按“内容寻址”规则存储到该目录中⸺相同版本的包仅存储一份，无论多少
个项目依赖该包，都不会重复存储，从根源上杜绝了冗余存储。
• 硬链接复用包内容：硬链接是文件系统层面的特性，它不复制文件本身，仅创建一个指向原文件数
据的引用（相当于给同一个文件起了多个“文件名”）。pnpm 在安装时，不会将共享存储中的包复制到项目 node_modules，而是通过硬链接将共享存储中的包文件链接到项目的 pnpm-
store 子目录，硬链接占用的磁盘空间可以忽略不计，实现了包内容的零冗余复用。
• 符号链接组织依赖结构：pnpm 不采用扁平依赖结构，而是通过符号链接在项目
node_modules 中构建“嵌套式”的依赖树（逻辑上嵌套，物理上共享）。对于项目直接依赖的包，会在 node_modules 中创建指向共享存储的符号链接；对于间接依赖（包的依赖），会
在对应包的 node_modules 中创建符号链接，既保证了依赖的正确引用，又无需重复存储间接依赖包。
- 提高安装速度的核心原理
全站分卷索引 · 26 卷
- 1第 1 卷
- 深入解析：npm 安装包及四大包管理工具对比
- 一、npm 安装包的完整过程
- ◦ 先检查项目根目录的 package.json 文件，读取目标包的版本约束（如 ^1.2.3、
- ◦ 结合 package-lock.json（npm 5+ 新增）或 npm-shrinkwrap.json，优先锁定已
- ◦ 更新 package-lock.json：记录本次安装的所有包的精确版本、依赖关系、下载地址等信
- ◦ 执行生命周期脚本：若包自身或项目中配置了 preinstall、 install、
- • 性能排序（安装速度+磁盘占用）：pnpm > yarn > cnpm > npm（最新版 npm 已优化，差距缩
- • 网络优化：cnpm 依赖国内镜像，npm/yarn/pnpm 可手动配置镜像，pnpm 缓存跨项目复用更
- 三、pnpm 存储结构减少磁盘占用+提高安装速度的原理
- • 全局共享存储目录：pnpm 会在系统中创建一个全局共享存储目录（默认路径：Windows
- • 硬链接复用包内容：硬链接是文件系统层面的特性，它不复制文件本身，仅创建一个指向原文件数
- • 符号链接组织依赖结构：pnpm 不采用扁平依赖结构，而是通过符号链接在项目
- 2第 2 卷
- 3第 3 卷
- 4第 4 卷
- • 使用 ESBuild 替代 Babel/Terser（可选）：
- 总结
- 六、loader和plugin的区别及其在Webpack中的作用
- • 定位不同：loader 专注于“模块转换”，解决非 JS/JSON 模块的加载与转译问题；plugin 专注
- • 工作时机不同：loader 仅在“编译阶段”（解析模块时）执行，针对单个模块进行处理；plugin
- • 使用方式不同：loader 配置在 module.rules 中，通过 test 匹配目标文件，指定对应的
- • loader的作用：将非 JS/JSON 模块转换为 Webpack 可识别的模块，以便纳入依赖图谱进行打
- • plugin的作用：扩展 Webpack 的构建能力，覆盖从初始化配置到输出文件的全流程，实现
- 七、如何使用Webpack来处理CSS和Sass
- • 步骤1：安装依赖：
- • 步骤2：Webpack配置：
- • 生产环境（提取为单独 CSS 文件）：
- 5第 5 卷
- 6第 6 卷
- 7第 7 卷
- 8第 8 卷
- • 排除无需处理的文件：通过 exclude 配置排除 node_modules、 dist 等目录，避免
- • 使用 thread-loader 开启多线程构建：将耗时的 loader 任务（如 Babel 转译、Sass 转译）分配到
- • 禁用生产环境相关优化（开发环境）：开发环境无需启用代码压缩（ TerserPlugin）、CSS 提
- 补充总结
- • 依赖静态分析：ES 模块的导入导出是静态的（导入导出语句只能在模块顶层，且不能动态判
- • 删除死代码：在代码压缩阶段（如 TerserPlugin），将标记的死代码删除，最终生成精简的
- • 代码必须使用 ES 模块（ import/export）：避免使用 CommonJS 模块（ require 是动态
- • 指定 mode: 'production'：Webpack 在生产环境下会自动启用 Tree Shaking（内置
- • 优化 usedExports（标记未使用导出）：显式标记未被使用的导出，增强 TerserPlugin 的删除效
- • 通过 package.json 配置 sideEffects（排除有副作用的模块）：
- 9第 9 卷
- 10第 10 卷
- • HMR 体验：在 React 项目中修改某个组件的样式或逻辑，页面无刷新，组件样式/逻辑实时更新，
- • environment：Webpack 环境准备完成后触发（如 Node.js 环境变量配置），插件可在此阶段获
- • entryOption：在 Webpack 解析入口配置（ entry）后触发，可用于修改入口配置（如动态添
- • afterResolvers：解析器（resolver，用于查找模块路径）初始化完成后触发，可用于自定义模块
- • beforeRun：在 Compiler 开始执行编译前触发（仅在首次构建和 watch 模式下重新构建时触
- • watchRun：仅在 watch 模式下（文件变化触发重新构建）触发，在编译开始前执行，可用于监听
- • compilation：当一个新的 Compilation 实例（负责模块解析、依赖收集、生成 chunk）被创建时
- • normalModuleFactory：普通模块工厂（用于创建普通模块，如 JS 模块）初始化时触发，可用
- • contextModuleFactory：上下文模块工厂（用于创建上下文模块，如
- • moduleAsset：当一个模块生成对应的资源（如图片、CSS 文件）时触发，可用于跟踪模块与资
- • shouldEmit：在输出文件前触发，返回 boolean 值，决定是否输出文件（返回 false 可终止
- • emit：在输出文件到磁盘前触发，是插件修改输出资源的关键钩子（如 TerserPlugin 在此阶
- 11第 11 卷
- 12第 12 卷
- 13第 13 卷
- 14第 14 卷
- • 重复编译未变化模块：开发环境中未启用缓存，每次代码修改后都全量重新编译，而非仅编译变化
- • 资源处理低效：
- • 配置不合理：
- • 项目本身复杂度高：模块数量庞大（千级以上）、依赖链过深、存在大量动态依赖，导致
- • Webpack 内置缓存（Webpack 5+）：配置 cache 选项，将模块缓存到内存或磁盘，重启开发
- • Loader 缓存：为耗时 Loader（如 babel-loader、 sass-loader）启用缓存，避免重复转
- • 预编译第三方依赖（DllPlugin）：第三方依赖（如 React、Vue）极少变化，通过 DllPlugin
- • 排除无需处理的文件：通过 exclude 排除 node_modules、 dist 等目录，减少
- • 开启多线程构建：使用 thread-loader 将耗时的 Loader 任务分配到多个线程并行执行，充分
- 15第 15 卷
- • 优化静态资源处理：
- • 开发环境：禁用生产优化：开发环境核心目标是“快速构建”，无需启用代码压缩、CSS 提取等耗
- • 生产环境：精准优化：生产环境核心目标是“产物优化”，但需避免冗余配置：
- • 移除无用插件：检查插件列表，移除开发环境中不需要的生产插件（如 TerserPlugin、
- • 使用高效插件替代：
- • 拆分大型项目（Monorepo）：对于大型项目，使用 Webpack 工作区（Workspaces）或
- • 减少动态依赖：尽量避免 require(`./${filename}`) 等动态依赖，改用静态导入，减少
- • 按需加载第三方依赖：对于体积大的第三方库（如 lodash），使用按需导入（如 import {
- • 开发体验极致：秒级启动开发服务器，毫秒级热更新，彻底解决大型项目开发时“启动慢、更新
- • 零配置开箱即用：默认支持 React、Vue、TypeScript、CSS 预处理器（Sass/Less）、静态资源等
- • 生产环境产物优化：基于 Rollup 打包，默认开启 Tree Shaking、代码分割、资源压缩等优化，产
- • 原生 ESM 支持：顺应前端模块化发展趋势，直接使用浏览器原生 ESM 能力，减少打包层的性能损
- 16第 16 卷
- • 配置灵活强大：支持深度自定义构建流程，可精准控制每一个环节（如模块解析、代码分割、缓存
- • 兼容性广泛：支持旧浏览器（如 IE 11），可通过 Loader 转译各类非标准模块，适配传统项目迁移
- • 多场景适配：对多页面应用、Monorepo、大型企业级项目的支持更成熟，案例丰富，问题解决方
- • 秒级开发服务器启动：无论项目大小（即使是千级模块的大型项目），开发服务器均可秒级启动，
- • 毫秒级热更新：代码修改后，仅需编译变化的模块，无需处理依赖链，更新速度恒定，不受项目规
- • 零配置开箱即用：默认支持 React、Vue、TypeScript、Sass/Less、CSS 模块、静态资源等主流场
- • 高效的生产构建：基于 Rollup 打包，默认开启 Tree Shaking、代码分割、资源压缩、懒加载等优
- • 丰富的内置功能：内置开发服务器、热更新、PostCSS、CSS 预处理器支持、静态资源处理等功
- • 预构建的原因：第三方依赖通常存在以下问题，影响加载效率：
- • 预构建的流程：
- • 兼容 Rollup 插件：Vite 生产环境基于 Rollup 打包，因此大部分 Rollup 插件可直接在 Vite 中使用
- • 扩展 Vite 特有钩子：在 Rollup 插件接口基础上，新增了针对 Vite 开发环境的特有钩子（如处理
- 17第 17 卷
- 18第 18 卷
- • changeOrigin：可选，默认 false。开启后，代理会修改请求头中的 Origin 字段为
- • rewrite：可选，路径重写函数。用于修改请求路径前缀（如前端用 /api 前缀标识接口请
- • secure：可选，默认 true。若目标服务器是 HTTPS 协议，且证书不被信任（如本地开发环
- • ws：可选，默认 false。开启后支持 WebSocket 代理（如后端有 WebSocket 服务时启
- • 代理仅作用于开发环境：Vite 的 server.proxy 是 Dev Server 的配置，生产环境打包后不生
- • 路径匹配规则：代理规则的键是请求路径的前缀，若多个规则匹配，优先匹配更具体的前缀（如
- • WebSocket 代理：若后端有 WebSocket 服务（如实时消息），需开启 ws: true，示
- 19第 19 卷
- • 模块格式不兼容：多数第三方依赖是 CommonJS 格式（如 lodash、moment），而 Vite 开发环
- • 大量小模块导致网络瀑布：部分依赖（如 React 生态、lodash-es）包含大量小模块（单个功能一
- • 依赖路径复杂：第三方依赖内部的路径引用可能包含别名、条件导入等，直接加载会导致解析失
- • 缓存存储位置：预构建结果缓存到项目根目录的 node_modules/.vite 文件夹中，包含转换
- • 缓存失效条件：仅当以下条件发生变化时，才会重新预构建，否则直接复用缓存：依赖版本变化
- • 必要依赖识别：Vite 会扫描项目的入口模块（如 src/main.js）及其直接/间接依赖，识别出需
- • 自定义预构建范围：通过 vite.config.js 的 optimizeDeps.include 和
- • Vite 内部使用 esbuild（基于 Go 语言的构建工具）进行依赖预构建， esbuild 本身支持并
- • 对于多个独立的第三方依赖（如 vue 和 axios），Vite 会并行触发 esbuild 处理，避免串
- • 例如： lodash-es 包含数百个小模块（如 lodash-es/map.js、 lodash-
- • 合并策略：Vite 会根据依赖的内部依赖关系，智能合并关联紧密的模块，避免合并后的包体积过
- • 多格式支持：原生支持 CommonJS → ESM 的转换、JSX 转译、TypeScript 转译等，无需额外配
- 20第 20 卷
- • Tree Shaking：自动移除未被使用的代码（死代码），仅保留被引用的模块和代码片段（基于
- • 代码分割（Code Splitting）：自动拆分第三方依赖（如 vue、 axios）为独立 chunk（如
- • 对动态导入的模块（如 import('./pages/About.vue')），自动拆分为异步 chunk，实现
- • 开发环境：以“原生 ESM 支持”为核心，直接将静态资源作为模块加载，无需打包，确保开发体
- • 生产环境：以“优化输出”为核心，对静态资源进行压缩、哈希命名、按需转换（如小图片转
- • 零配置支持：默认支持常见静态资源类型（ png、 jpg、 gif、 svg、 woff、 mp4
- • 开发环境：直接通过 import 或 url() 加载图片，Vite Dev Server 实时返回图片资源，支持
- • 小图片转 Base64：默认将小于 4KB 的图片转换为 Base64 编码，嵌入到 JS/CSS 中，减少 HTTP
- • SVG 特殊处理：支持直接导入 SVG 作为组件（需配合 @vitejs/plugin-vue 等框架插件），
- • 处理逻辑与图片类似：开发环境直接加载，生产环境自动压缩、哈希命名、输出到
- • 示例： // CSS 中引用字体
- • 开发环境：直接通过 import 或 <audio>/<video> 标签加载，Vite Dev Server 提供资源服
- 21第 21 卷
- 22第 22 卷
- • targets：决定转译的程度，目标环境越旧，转译后的代码兼容性越好，但体积越大。可通过
- • 语法转译插件：负责将 ES6+ 语法转为 ES5（如 @babel/plugin-transform-arrow-
- • 语法提案插件：负责转译尚未成为 ES 标准的语法（如 @babel/plugin-proposal-class-
- • 工具类插件：负责辅助转译过程（如 @babel/plugin-transform-runtime 复用辅助代码，
- • @babel/preset-env：核心预设，用于转译 ES6+ 语法，可根据目标环境按需加载插件（最常
- • @babel/preset-react：用于转译 React 的 JSX 语法，包含 @babel/plugin-
- • @babel/preset-es2015（已废弃）：早期用于转译 ES2015 语法，现被
- • 预设按配置顺序从右到左执行（与插件相反）。例如上述配置中，先执行 @babel/preset-
- • 原因：预设是“插件集合”，右侧预设（如 TypeScript 转译）的输出可能需要左侧预设（如 ES6+
- 23第 23 卷
- • runtime: "automatic"（React 17+ 推荐）：自动导入 react/jsx-runtime 模块中的 jsx
- • runtime: "classic"（旧版 React 16-）：转译为 React.createElement 函数调用，需手动
- • 属性名转换：JSX 中的 className 转译为 className（避免与 JavaScript 关键字 class
- • 事件名转换：JSX 中的驼峰式事件名（如 onClick）保持不变，转译为函数调用的属性（如
- • 子节点处理：JSX 中的子元素（文本、其他 JSX 元素）会作为 children 参数传入 jsx 或
- • Fragment 处理：空标签 <></>（React Fragment）会转译为 jsx(React.Fragment,
- 24第 24 卷
- 25第 25 卷
- 26第 26 卷