包管理：npm、yarn、pnpm 与 package.json

你写第一个 JS 项目时，可能直接 <script src="jquery.js"> 引一个库。但真实项目要依赖几十上百个包，每个包又依赖别的包——手动下载、管理版本、解决冲突，会逼疯人。于是有了包管理器：它帮你”一键安装、自动记录、锁定版本、解决依赖树”。

这一篇我们讲清 package.json 是什么、^1.2.3 这种版本号怎么读、package-lock.json 为什么不能丢，以及 npm/yarn/pnpm 该怎么选。

为什么需要包管理器

没有它，你的痛点是：

手动下载：想用 axios，得去官网下文件、放进项目、引路径，更新还得重新下。
版本失控：今天装 1.0，同事装 2.0，跑起来表现不一样，互相甩锅。
依赖嵌套：axios 依赖 follower、follower 又依赖 something……你根本不知道有多少层。
无法复现：换台电脑 npm install 装出来的版本可能不同，bug 时有时无。

包管理器一次性解决这些：一条命令装好所有依赖、记录精确版本、保证任何人装出来都一样。

package.json：项目的身份证

每个现代前端项目根目录都有 package.json，它描述”这个项目是谁、依赖什么、有哪些脚本”：

{
  "name": "my-app",
  "version": "1.0.0",
  "scripts": {
    "dev": "vite",
    "build": "vite build"
  },
  "dependencies": {
    "vue": "^3.4.0",
    "axios": "^1.6.0"
  },
  "devDependencies": {
    "vite": "^5.0.0",
    "eslint": "^8.0.0"
  }
}

关键字段：

dependencies：生产环境也需要的依赖（如 Vue、axios）。上线后必须带。
devDependencies：只在开发时用（如 Vite 构建工具、ESLint 规范）。上线打包后不需要。
scripts：自定义命令别名，npm run dev 实际执行 vite。这是团队协作的”统一入口”。
name / version：项目标识。

语义化版本：^ ~ 1.2.3 怎么读

版本号 1.2.3 含义是 主版本.次版本.补丁：主版本大改（不兼容）、次版本加功能（兼容）、补丁修 bug（兼容）。

依赖里写的 ^1.2.3 和 ~1.2.3 是”版本范围”，决定 npm install 能装多新：

^1.2.3：允许次版本和补丁更新，即 >=1.2.3 <2.0.0。最常用，因为次版本通常向后兼容。
~1.2.3：只允许补丁更新，即 >=1.2.3 <1.3.0。更保守。
1.2.3：精确锁定，只装这个版本（不写符号就是精确）。
* / latest：装最新，极不推荐，版本漂移会导致”今天能跑明天崩”。

经验：线上项目用 ^ 拿兼容更新，但必须有 lockfile 锁死实际装了什么（下面讲）。

lockfile：让依赖”可复现”

package.json 里写 ^3.4.0，意思是”装 3.x 里最新的”。但”最新”是会变的——你今天装 3.4.0，同事下周装可能变成 3.9.0，万一 3.9 有个坑，你俩表现就不一样。

lockfile（package-lock.json / yarn.lock / pnpm-lock.yaml）就是解决这个的：它精确记录每一层依赖实际装的具体版本和下载地址。有了它，任何人、任何机器 install 出来的依赖树都完全一致。

铁律：lockfile 必须提交进版本库（git），不能加进 .gitignore。它是”依赖可复现”的保证，也是排查”为什么他那边能跑我这崩了”的第一道线索。

npm / yarn / pnpm 怎么选

三者都是包管理器，命令高度相似，但实现有别：

管理器	特点	适用
npm	Node 自带，最通用，生态默认	新手、不想额外装
yarn	早期为补 npm 慢/不稳定，现差异缩小	老项目、团队习惯
pnpm	硬链接 + 全局仓库，省磁盘、装得快、依赖严格	新项目、monorepo、追求效率

pnpm 的核心优势：npm/yarn 传统做法是”每个项目复制一份 node_modules”，多个项目用的同一个包被复制 N 份，磁盘爆炸。pnpm 用全局内容寻址存储 + 硬链接，所有项目共享同一份真实文件，谁用谁链接，磁盘占用骤降，安装速度也快。而且 pnpm 默认禁止”幽灵依赖”（你没声明却因别人依赖而能 import 的包），依赖关系更干净。

新手建议：新项目直接上 pnpm；接手老项目按它原有的来（看 lockfile 类型判断）。常用命令几乎一样：

npm install          # 装全部依赖
npm install axios    # 加一个生产依赖
npm install -D vite  # 加一个开发依赖
npm run dev          # 跑 scripts 里的 dev

pnpm 把 npm 换成 pnpm 即可：pnpm install、pnpm add axios、pnpm dev。

常见新手坑

把 node_modules 提交进 git：那是装出来的，体积巨大且能重建，必须 gitignore，只提交 lockfile。
丢了 lockfile：别人装出来的版本和你不一致，出现”在我电脑上是好的”经典 bug。
乱用 latest / *：版本漂移，今天能跑明天崩，且难回滚。
dependencies 和 devDependencies 混放：把 Vite 放进 dependencies，上线包无谓变大。
直接手动改 node_modules 调试：重装就没了，应该改源码或提 PR 给上游。
幽灵依赖：没声明却 import 了别人的依赖（npm/yarn 传统模式允许），换 pnpm 或升级就报错。显式声明你要用的每个包。

实战：从零初始化一个项目

用 pnpm 走一遍标准流程：

mkdir my-app && cd my-app
pnpm init            # 生成 package.json
pnpm add vue         # 加生产依赖，自动写进 dependencies
pnpm add -D vite     # 加开发依赖，写进 devDependencies
# 编辑 package.json 加 scripts: { "dev": "vite" }
pnpm install         # 安装，生成 pnpm-lock.yaml
pnpm dev             # 启动开发服务器

完成后目录里：package.json（声明）、pnpm-lock.yaml（锁版本，提交 git）、node_modules/（装的包，gitignore）。这套结构是任何现代前端项目的标准起点。

新手怎么把包管理用熟

包管理是工程化的”地基”，不熟后面全晃。建议动手初始化三个小项目，分别用 npm、yarn、pnpm 各走一遍 init → add → run，对比生成的 lockfile。重点是理解 lockfile 的价值——它不是多余文件，而是”团队依赖一致”的契约。

另一个心法：依赖要”显式且最小”。只装你真正 import 的包，别因为”可能用到”就提前装一堆；删依赖时用 pnpm remove 而不是手动改 json，保证 lockfile 同步。依赖越少，安装越快、漏洞面越小、新人上手越轻松。

还有，定期审依赖安全。npm audit / pnpm audit 能扫出有已知漏洞的包，CI 里跑一遍能挡掉不少风险。依赖不是”装了就忘”，它是你项目的供应链，供应链出问题（如某个包被植入恶意代码）后果很严重，值得花一点精力维护。

小测验：看看你掌握了没

问题一：^1.2.3 和 ~1.2.3 允许装到什么范围？答案：^ 允许 >=1.2.3 <2.0.0（次版本+补丁）；~ 允许 >=1.2.3 <1.3.0（仅补丁）。
问题二：lockfile 为什么必须提交 git？答案：它精确锁定每层依赖的实际版本，保证任何人/机器装出来完全一致，实现依赖可复现。
问题三：pnpm 相比 npm 的主要优势？答案：全局存储+硬链接省磁盘、安装快、默认禁止幽灵依赖，依赖更干净。

这一篇你该记住的

包管理器解决”手动下载/版本失控/依赖嵌套/无法复现”四大痛。
package.json 是身份证：dependencies（生产）、devDependencies（开发）、scripts（命令别名）。
语义化版本 主.次.补丁；^ 兼容次版本更新、~ 仅补丁、* 危险。
lockfile 锁死实际版本，必须提交 git，保证可复现。
npm 通用、yarn 老牌、pnpm 省磁盘快且严格；命令几乎一致。
依赖显式最小、定期 audit；node_modules 不进 git。

下一篇我们讲 构建工具：为什么现代前端要”打包”，Vite 和 Webpack 在做什么，dev server 和热更新怎么提升开发效率。

前端开发