名词解释教学工作区 · 课程 0004 · 形态 对比组 · 约 5 分钟 · 前置:0001 · CLI / TUI / GUI · 2026-10-01

Node.js、npm、pnpm:一个负责跑,两个负责取

1 | 定义

这三个词常被并排写进同一个标题,却站在两层:一个是把 JavaScript 跑起来的运行时,另两个是取包的包管理器。各记一行:

• ① Node.js(JavaScript runtime,JavaScript 运行时,平时简称 Node) 让 JavaScript 脱离浏览器、在本机或服务器上执行的运行时:它自带 JS 引擎,能直接执行 .js 文件。 这门语言本来只待在浏览器里,它等于给 JS 配了辆车 —— 在服务器上、在终端里,JS 都能自己跑起来。
• ② npm(Node Package Manager,Node 包管理器) 随 Node.js 一起分发的包管理器:按项目清单去远端仓库取包、装进项目,并把这次装到的确切版本写进锁定文件记账。 像随手机自带的应用商店:项目缺什么现成代码,报个名字它就搬回来,顺手记下装的是哪一版。
• ③ pnpm(performant npm,高性能包管理器) 另一种包管理器:每个包的本体在全机只存一份,项目里用硬链接(hard link)指过去,所以装得多、占磁盘少。 同一个软件全家共用一份安装包:谁要用就在自己屋里开个入口,不必每间屋重装一套。

分工就此定下:运行时管"把代码跑起来",两个包管理器管"把别人的代码搬进来并记账"。三者各有各的版本,分开升级、分开出问题。

2 | 它们解决什么麻烦

三者的麻烦同源:想跑起来的代码,一半是别人写的。这层麻烦分成两半,一半归运行时,一半归包管理器。

• ① 这门语言原来出不了浏览器。JavaScript 出生在网页里,读写页面、发网络请求都要在浏览器环境里才成立;想拿它写后端服务、命令行工具或者构建脚本,先得有一个浏览器之外能执行它的地方 —— 这是 Node.js 要解的。
• ② 项目里一半代码是别人写的,而这件事没人管。要装得动、版本要对得上、换台机器还得装出同一套;靠手动拷文件和口头约定版本做不到 —— 这是包管理器要解的。

第 ② 条再往下拆,还藏着两个包管理器同时存在的原因:同一个包在十个项目里各拷一份,磁盘和等待时间就翻十倍。后来用"在项目里做提升、少装重复版本"缓解,又引出新的麻烦(见第 5 节)。

3 | 特征矩阵

先分清角色,再比两个包管理器的差别。下面每一列都是能直接从项目和命令上看出来的事:

横着读一遍:"它是什么"这一列先把运行时和包管理器分开,剩下的列说明两个包管理器的差别全在包放哪儿、装完长什么样。首次安装的速度与磁盘占用是这两条的直接后果:各装一份,账随项目数一起涨;共用一份,账几乎不随项目数变。

4 | 各自怎么做

• ① Node 用事件循环(event loop)和非阻塞 I/O 同时照看很多件事。node index.js 启动之后,读文件、查数据库、发网络请求这些都要等,等待的时间交给操作系统,主线程转头去处理下一个任务;一条线程就能同时守着成千上万个连接。前端那一整套工具链 —— 打包器、SSG 生成器、测试框架 —— 自己也都跑在 Node 上。
• ② npm 认的是项目清单。package.json 里分两摞:dependencies(程序跑起来要用的)与 devDependencies(只在开发和构建时用的);装完把确切版本与来源写进 package-lock.json。想按锁定文件原样重装、一个版本都不许动,用 npm ci;临时跑某个包里的一条命令,用它自带的 npx。在 IDE 或编辑器里点一下安装按钮,后台跑的就是这条命令。
• ③ pnpm 把"每个包只存一份"做成默认。包按内容寻址存进一个全机仓库(store),项目里那个依赖目录放的是指向仓库的硬链接,同一个版本在二十个项目里合起来也只占一份磁盘。多包仓库(monorepo)里它用 pnpm-workspace.yaml 声明工作区,pnpm -w 让命令作用在整个仓库、而不是某个子包上。
• ④ 两边都靠锁定文件复现安装。持续集成 CI 流水线里不手敲 npm install,而是 npm ci(读 package-lock.json)或 pnpm install --frozen-lockfile(读 pnpm-lock.yaml):锁定文件对不上就直接报错,不会悄悄换一个版本装上。

5 | 各自的代价

• ① Node 的主线程只有一条。事件循环擅长的是等 I/O,不是算数:一段纯计算(压缩、加密、图像处理)会把这条线程占满,这期间所有请求只能排队;要绕开它,得自己把活拆到 worker_threads 或子进程里。
• ② npm 的提升让包"住在不该住的地方"。为了少装重复版本,子依赖尽量被提升到顶层,于是你没在清单里写过的包,也可能在代码里被引用成功 —— 换个包管理器,或者它被别的依赖顺手去掉,代码立刻找不到模块;这类依赖常被叫作幽灵依赖(phantom dependency)。同一个版本被不同依赖分别要求时,也照样可能装出多份。
• ③ pnpm 的严格与共享,偶尔会顶到生态的边界。依赖之间靠符号链接串起来,少数认"真实路径"的工具(打包器插件、某些脚本)会在这里踩空;两套锁定文件也不能混用,换用哪一个就等于全组一起换。

6 | 区分使用场景

它们不抢同一份活:要不要装包,才决定你在两个包管理器里选谁。按手头这件事挑:

• ① 要跑 JS 代码本身(后端服务、命令行工具、各种构建脚本)→ Node.js。一个包都不装,也得先有它;许多后端的 API 就挂在它上面。
• ② 项目要用现成的库,而团队里已经有一套 package-lock.json → npm。它随 Node 自带,最省一步安装。
• ③ 多包仓库、磁盘紧张、依赖装得特别多 → pnpm。省下的是磁盘和等待时间,代价是全组要统一。
• ④ 要按锁定文件原样重装一套(流水线里、换机器复现时)→ npm ci 或 pnpm install --frozen-lockfile,别用会顺手改锁定文件的安装命令。

已经站在一个项目里,最省事的判断是看项目根目录躺着哪个锁定文件:写着 package-lock.json 就跟着用 npm,写着 pnpm-lock.yaml 就跟着用 pnpm。还有一条边界要说清:包管理器只负责"把别人的代码搬进来",它不管"把你的源码做成能发布的产物" —— 后一段是构建工具的活,项目里常用 npm run build 这类脚本把两段串起来,产物再交给部署那一课去发。

7 | 常见误解

• ① 「Node.js 是一门语言。」它是一门语言(JavaScript)的执行环境。这门语言在浏览器里本来就能跑,缺的只是浏览器之外那个执行它的地方。
• ② 「npm 只能装 JavaScript 包。」它是包管理器,分发的是"包 + 版本 + 依赖清单";包里可以装二进制工具(打包器、代码格式化工具),只是这些工具大多也由 JS 写成。
• ③ 「pnpm 就是 npm 换了层皮。」两者的取包规则不同:一个在项目里各装一份并做提升,一个把本体放进全机仓库再用硬链接指过来;写出来的锁定文件也各是一套。
• ④ 「换包管理器随手来,锁定文件混着用没关系。」两套锁定文件记的东西对不上,混用会把"本地装到的版本"和"流水线复现的版本"悄悄拉开,是最难查的那类不一致。

8 | 练习

三题自测,每题只有一个正确选项;同一组词换着问,按题干的动作挑。