为什么 2026 年我们首选 pnpm？

长期以来，npm 和 yarn 采用的扁平化 node_modules 结构虽然解决了“依赖地狱”问题，但也带来了新的麻烦：磁盘空间浪费和“幽灵依赖”。pnpm 的出现彻底改变了游戏规则。

1. 极致的空间节省（内容寻址存储）

传统的包管理器会在每个项目中完整复制一份依赖。如果你有 10 个项目都用到了 Three.js，你的硬盘就会白白浪费数 GB 空间。

pnpm 做法： 它在全局维护一个 .pnpm-store。所有项目通过硬链接 (Hard Links) 指向同一个文件。这意味着同一个包在你的硬盘上永远只存在一份。

2. 杜绝“幽灵依赖”

在 npm/yarn 中，你可以 import 一个并未在 package.json 中声明的包（只要它是某个依赖的依赖）。这会导致生产环境部署时因依赖缺失而崩溃。

pnpm 做法： 它通过符号链接 (Symlinks) 构建了一个严谨的树状结构。你的代码只能访问到你明确安装的包，极大地增强了代码的稳健性。

3. 极速安装

由于 pnpm 在安装时跳过了大量的 IO 复制操作，且支持高度并发的下载和链接，其安装速度通常是 npm 的 2-3 倍。

在 Next.js 项目中使用 pnpm

Next.js 官方对 pnpm 的支持非常友好。以下是从零开始到部署的完整流程：

第一步：安装 pnpm

如果你还没有安装 pnpm，推荐使用独立脚本或 Node.js 自带的 corepack：

# 使用 corepack 激活 (推荐)
corepack enable
corepack prepare pnpm@latest --activate

第二步：创建 Next.js 项目

使用官方脚手架时，可以直接指定包管理器：

pnpm create next-app@latest my-next-project

在交互式命令行中，确保选择使用 pnpm。

第三步：日常操作对比

你会发现 pnpm 的指令与 npm 非常接近，迁移成本极低：

第四步：Next.js 特有配置（可选）

如果你在 Monorepo 架构（如使用 Turbo 或 pnpm-workspace）中运行 Next.js，你可能需要在 next.config.js 中开启 output: 'standalone' 模式，以确保部署时能够正确提取软链接后的依赖。

// next.config.js
const nextConfig = {
  output: 'standalone', // 推荐：优化部署体积
}
module.exports = nextConfig

避坑指南：pnpm 的常见小问题

虽然 pnpm 很强大，但在使用过程中有两点需要注意：

1. Peerdependencies 警告： pnpm 对“对等依赖”校验非常严格。如果看到警告，可以运行 pnpm config set auto-install-peers true 让它自动处理。

2. 环境变量： 如果你的脚本中依赖了某些被“打平”到全局路径的二进制文件，可能会找不到。这时需要通过 pnpm add -D <tool> 显式安装它们。

结论

使用 pnpm 不仅仅是为了那几秒钟的安装速度，更是为了更合理的磁盘管理和更安全的依赖架构。对于 Next.js 这种依赖繁重的框架，pnpm 是目前的最佳拍档。