npm、Yarn、pnpm、Bun 和 Deno 在实际使用中有哪些区别？

2026-11-04选型许工

npm、Yarn、pnpm 主要用于安装依赖和管理项目脚本。Bun 和 Deno 可以直接运行 JavaScript、TypeScript，也附带开发工具。Bun 还提供可独立使用的包管理器，兼有这两类工具的功能。

选型时，可以把依赖安装和程序运行分开考虑。更换包管理器通常只影响依赖解析、目录布局和开发流程；把 Node.js 换成 Bun 或 Deno，则需要验证应用行为、原生扩展和部署环境。Bun、Deno 都可以用于生产项目，能否替换某个 Node.js 服务，要看该服务的实际依赖和运行方式。

这些命令分别做什么？

命令	主要作用	是否启动应用
`npm install`	安装项目依赖	否，但可能执行安装脚本
`yarn install`	安装依赖，并建立所配置的依赖布局	否，但可能执行安装脚本
`pnpm install`	安装依赖，并建立包之间的链接	否，但可能执行安装脚本
`bun install`	使用 Bun 的包管理器安装依赖	否，但可能执行获准的安装脚本
`deno run app.ts`	使用 Deno 执行文件，按需解析、获取依赖	是

例如，只更换包管理器时，可以用 Bun 安装依赖，继续用 Node.js 运行程序：

bun install
node app.mjs

要用 Bun 运行应用，则执行：

bun run app.ts

Bun 官方支持在已有 Node.js 项目中单独使用它的包管理器。Bun 安装文档

npm CLI 与 npm registry 也需要区分。使用 Yarn、pnpm 或 Bun，仍然可以从 npm registry 下载同一批包。

npm、Yarn 和 pnpm 的架构差异

三者都能读取 package.json，区别主要在于如何解析依赖、保存包文件，以及让程序找到这些文件。

npm：以传统 `node_modules` 布局为主

npm 默认会尽量把依赖提升到较高层的 node_modules，减少重复安装。遇到版本冲突时，再在相应包的目录下保留嵌套依赖。

这种布局直接配合 Node.js 的模块查找机制，也可能让项目访问到未在自己的 package.json 中声明的包。如果某个传递依赖恰好被提升到顶层，代码就能导入它；依赖树变化后，这种导入可能失效。npm 目录结构说明

npm 适合沿用常见 Node.js 工作流的项目，也支持通过 workspaces 管理多个包。

pnpm：共享文件存储，并用链接组织依赖

pnpm 的典型布局包含两部分：

内容寻址存储，按文件内容复用包文件。
项目内的 node_modules/.pnpm 和符号链接，用来表达依赖关系。

包文件通过硬链接等机制复用，包之间则通过符号链接组织依赖关系。多个项目使用相同内容时，可以减少磁盘空间的重复占用，实际能节省多少取决于文件系统、存储位置和安装配置。pnpm 目录结构说明

这种布局更容易暴露未声明的依赖。例如，应用直接导入 lodash，却只声明了一个间接依赖 lodash 的工具包，迁移后就可能报错。这时需要把 lodash 加入应用自己的依赖声明。

pnpm 适合依赖较多、同时维护多个项目，或需要管理 monorepo 的场景。迁移时，要检查工具链中是否有工具直接扫描 node_modules、假定目录完全扁平化，或无法正确处理符号链接。

Yarn：先区分 Classic 与现代版本

Yarn Classic 通常指 Yarn 1，主要使用传统的 node_modules 布局。现代 Yarn 则支持多种安装模式。

现代 Yarn 默认使用 Plug’n’Play，简称 PnP。它生成 .pnp.cjs 等解析文件，记录包的位置和依赖关系，通常不构建传统的 node_modules 目录树。这种方式可以检查未声明的依赖，编辑器、测试工具和部署入口也需要正确接入 PnP。Yarn PnP 文档

如果工具链要求传统布局，可以在 .yarnrc.yml 中配置：

nodeLinker: node-modules

现代 Yarn 还提供其他 linker，可以按项目需要选择安装模式。Yarn 安装模式

已有 Yarn 项目通常可以继续使用。新项目是否选择 PnP，主要看团队是否需要它的依赖约束，以及编辑器、框架和部署工具是否支持。

Bun 和 Deno 在运行时层面有什么区别？

运行时除了执行 JavaScript，还负责模块加载、文件与网络访问、进程管理等功能。

运行时	JavaScript 引擎	相关架构特点
Node.js	V8	提供 Node.js API、模块系统及配套生态
Bun	JavaScriptCore	实现 Node.js 兼容能力，并提供 `Bun.*` API；集成包管理、转译、打包和测试工具
Deno	V8	提供 Web 标准 API、`Deno.*` API、Node.js 兼容能力，以及默认限制敏感访问的权限系统

Bun 使用 JavaScriptCore，Deno 使用 V8。Deno 与 Node.js 虽然使用相同的引擎，API、模块解析和权限规则仍有区别，运行时行为也不相同。Bun 架构说明、Deno TypeScript 执行说明

Bun 可以先作为包管理器使用

Bun 支持 package.json 和 npm 包，也可以直接执行 TypeScript、运行测试和打包。如果只使用 bun install，生产运行时可以继续使用 Node.js。

Bun 的依赖布局包括 hoisted 和 isolated 等模式，生成的目录树可能与 npm 不同。迁移时，应核对所选版本、项目配置和锁文件采用的安装策略。Bun 安装策略

安装速度和应用运行速度需要分别测量。下载缓存、网络、文件系统和依赖安装脚本会影响安装时间；服务性能则受业务代码、数据库访问和运行时实现影响。安装更快，不能直接说明应用也会运行得更快。

Deno 的区别包括权限和依赖管理方式

Deno 支持 npm 包、package.json 和 CommonJS，也可以根据项目需要使用本地 node_modules。迁移到 Deno 时，不一定需要重写全部依赖声明。Deno 的 Node.js 与 npm 兼容说明

Deno 的权限模型会直接影响启动命令。应用运行时，访问文件、网络、环境变量，以及创建子进程等操作通常需要显式授权。例如，需要监听端口的服务在执行 deno run app.ts 时，还要配置网络权限。

依赖中的代码同样受这些权限约束。模块下载另有规则，因此即使默认限制网络访问，Deno 启动时也可能联网下载模块。Deno 权限文档

实际项目应该怎么选？

项目情况	可考虑的选择	主要权衡
已有 Node.js 项目，安装和部署流程稳定	保留现有包管理器	避免仅因命令形式相近就承担迁移成本
新建常规 Node.js 项目	npm	沿用常见工作流；需要明确锁文件和 CI 安装规则
多项目或大型 monorepo，希望复用依赖文件	pnpm	检查链接布局、未声明依赖和打包部署方式
需要 PnP 的依赖约束，或已有现代 Yarn 配置	Yarn	处理编辑器、工具链及部署入口的 PnP 接入
希望使用 Bun 的安装、测试或打包工具	分别引入对应工具	每一步验证兼容性，运行时可以继续使用 Node.js
新服务或脚本希望使用 Deno 的权限和内置工具	Deno	核对依赖兼容性、权限配置与部署支持

前端项目还需要区分构建环境和浏览器环境。用 pnpm 安装依赖、用 Bun 执行构建命令，浏览器中的应用仍由浏览器执行。SSR、服务端路由和构建插件的运行时要求则需要单独检查。

Bun 或 Deno 能在生产环境替代 Node.js 吗？

可以，前提是具体应用通过验证。主要使用标准 JavaScript、Web API 和目标运行时已支持的 Node.js API 的程序，通常更容易迁移。依赖原生扩展、运行时内部行为、特定加载器或监控探针的服务，需要更多验证。Bun 和 Deno 都提供 Node.js 兼容能力，但具体应用能否直接更换启动命令，仍需逐项检查。Bun 兼容性列表、Deno 兼容性说明

例如，将下面的代码保存为 app.mjs：

import { createServer } from "node:http";

createServer((_req, res) => {
  res.writeHead(200, {
    "content-type": "text/plain; charset=utf-8",
  });
  res.end("ok\n");
}).listen(3000, "127.0.0.1");

选择其中一种方式运行：

node app.mjs

bun run app.mjs

deno run --allow-net=127.0.0.1:3000 app.mjs

这个示例只覆盖基础 HTTP 入口。生产验收还需要验证数据库连接、TLS、流式响应、WebSocket、异常退出和优雅停机，以及日志、追踪和性能分析工具。

性能测试应使用相同的业务逻辑、负载和部署资源，观察吞吐量、延迟、内存与长时间运行表现。如果采用 Bun.serve() 或 Deno.serve() 等专有 API，还要考虑后续迁移时改写代码的成本。

迁移时需要检查哪些兼容性问题？

锁文件与依赖解析

工具	常见锁文件
npm	`package-lock.json`
Yarn	`yarn.lock`
pnpm	`pnpm-lock.yaml`
Bun	`bun.lock`，旧项目可能使用 `bun.lockb`
Deno	`deno.lock`

各工具的锁文件格式和依赖解析规则不同。即使迁移工具支持导入锁文件，也要检查依赖树是否发生变化，尤其留意 peerDependencies、可选依赖、workspace 链接、补丁及版本覆盖配置。

同一安装流程应以一份锁文件为准，并固定工具版本。项目生成并提交对应锁文件后，CI 可以使用相应命令：

# 按项目选择其中一种
npm ci
yarn install --immutable
pnpm install --frozen-lockfile
bun install --frozen-lockfile

这里的 Yarn 命令适用于现代 Yarn。各工具的锁定安装行为有所不同，需要按各自文档配置。npm CI、Yarn install、pnpm install、Bun install

安装脚本与原生扩展

依赖可能通过 postinstall 下载二进制文件或编译原生模块。不同工具和版本采用的脚本执行策略不同，即使安装命令已经结束，也可能缺少运行所需的产物。

例如，Bun 对依赖的生命周期脚本采用信任机制，pnpm 提供构建脚本审批功能，Deno 默认不执行 npm 依赖的安装脚本。迁移时需要检查安装日志和项目配置。Bun 安装脚本规则、pnpm 构建审批、Deno 原生依赖说明

原生扩展还要区分使用 Node-API 的实现，以及直接依赖 V8、Node.js 内部接口的实现。某个 .node 文件能否加载，需要核对具体扩展的兼容性，支持 npm 包并不足以保证这一点。Deno 使用 Node-API 扩展时，需要本地 node_modules 和 --allow-ffi；Bun 的支持范围也要针对具体扩展确认。Bun Node-API 文档、Deno 兼容说明

模块解析、TypeScript 与测试工具

迁移运行时需要检查：

package.json 的 "type"，以及 .mjs、.cjs 的使用。
require() 与 ESM 的互操作行为。
扩展名、路径别名、exports 条件和自定义加载器。
脚本是否通过 shebang、node 命令或子进程继续调用 Node.js。
测试框架的 mock、插件和覆盖率功能是否支持目标运行时。

直接执行 .ts 文件时，仍需确认是否进行了类型检查。Deno 可以单独执行：

deno check app.ts

也可以在启动前检查：

deno run --check app.ts

Bun 项目同样需要把类型检查纳入流程。Node.js 的部分版本也支持直接执行含可擦除类型语法的 TypeScript，其转译能力和配置行为仍需与 Bun、Deno 分别核对。Deno 类型检查、Node.js TypeScript 支持

按步骤迁移，保留可比较的基线

记录现有运行时、包管理器版本和锁文件，确认构建、测试和生产启动均可复现。
单独迁移包管理器，在干净目录安装，检查依赖变化、脚本执行和构建产物。
再验证目标运行时，覆盖真实外部服务、异常路径和部署环境。
完成负载测试与试运行，保留原有启动方式和回滚所需产物。