从一条启动命令说起#

准备运行 Shirone 时，安装步骤中有这样几条命令：

git clone https://github.com/LyraVoid/Shirone.git
cd Shirone
corepack enable
pnpm install
pnpm dev

其中最容易让人困惑的是 corepack enable：系统已经有了 /bin/node 和 /bin/pnpm，为什么还需要启用另一个工具？它会修改哪些文件？遇到权限错误后，是否应该加上 sudo？

这次排查的关键，是分清三件事：系统软件包的归属、命令入口的位置，以及项目要求的 pnpm 版本。

Corepack 负责什么#

Corepack 连接项目与包管理器。项目可以在 package.json 中声明需要的 pnpm 版本，Corepack 据此准备并调用对应版本。

corepack enable 主要负责创建命令代理入口，也就是 shim。它默认在 Corepack 安装位置旁创建入口，也可以通过 --install-directory 指定目录；真正调用包管理器时，才可能触发下载和缓存。Corepack 官方说明

因此，安装 Corepack、启用命令入口和安装项目依赖，是三个不同的步骤。

另外，“Node.js 自带 Corepack”有版本边界：上游从 Node.js 14.19.0 开始附带 Corepack，到 Node.js 25 起不再附带，不能假定所有环境都有它。Corepack 安装说明

已有 pnpm，先确认它来自哪里#

看到 /bin/pnpm，还不足以判断它属于哪个安装方式。可以先检查命令解析结果、链接目标和软件包归属：

type -a node pnpm corepack
ls -l /bin/pnpm /usr/bin/pnpm
pacman -Qo /usr/bin/pnpm

重点看两点：

• 当前终端实际使用哪个 pnpm。
• 对应文件是否由 pacman 软件包管理。

不要直接把“已有 pnpm”理解为“必须卸载”。 如果决定让 Corepack 提供同一个系统路径下的命令入口，就需要先处理文件归属；如果使用用户目录入口，或者显式运行 corepack pnpm，则可以采用不同的配置方式。

Arch 官方 Extra 仓库提供独立的 corepack 软件包，但这并不意味着安装后普通用户就获得了 /usr/bin 的写权限。Arch Linux 软件包页面

实际遇到的权限错误#

原始记录中，执行：

corepack enable

出现了以下错误：

Internal Error: EACCES: permission denied, symlink
'../lib/node_modules/corepack/dist/pnpm.js' -> '/usr/bin/pnpm'

这条日志已经指出失败位置：Corepack 正在尝试创建 /usr/bin/pnpm，而当前用户没有写入权限。

问题发生在创建命令入口阶段，尚不能归因于项目依赖、下载源或 pnpm 版本。

排查过程中，一个需要纠正的判断是：

通过 pacman 安装 Corepack 后，执行 corepack enable 就不会触碰系统目录。

这与日志直接矛盾。安装来源决定软件包如何管理，入口位置决定启用操作需要什么权限，两者不能混为一谈。

三种使用方式#

方式一：直接调用 Corepack

如果只是运行项目，可以先不创建 pnpm 代理入口：

cd Shirone
corepack pnpm --version
corepack pnpm install
corepack pnpm dev

这种方式能明确表达“本次通过 Corepack 调用 pnpm”，也能避免当前 PATH 中已有 pnpm 带来的歧义。Corepack 命令说明

方式二：把入口放到用户目录

希望直接输入 pnpm，又不想修改系统目录，可以指定安装位置：

mkdir -p "$HOME/.local/bin"
corepack enable --install-directory "$HOME/.local/bin" pnpm

随后确保 ~/.local/bin 位于 PATH 中，并排在系统 pnpm 所在目录之前。当前终端可临时设置：

export PATH="$HOME/.local/bin:$PATH"

检查是否解析到预期入口：

type -a pnpm

撤销这些入口时，使用同一目录：

corepack disable --install-directory "$HOME/.local/bin" pnpm

方式三：创建系统级入口

原始对话随后建议执行：

sudo corepack enable pnpm

这能为写入 /usr/bin 提供权限，但应先确认目标路径没有需要保留的 pacman 管理文件。不能仅凭“Corepack 是 pacman 安装的”，就认定覆盖系统入口一定合适。

如果决定移除系统 pnpm，应先检查软件包管理器给出的依赖影响；不要手动删除它管理的文件。系统级入口的撤销同样需要对应权限：

sudo corepack disable pnpm

这里的撤销只负责移除 Corepack 入口，不会自动恢复此前的软件包。

验证时必须进入项目目录#

入口可用之后，还要确认项目实际使用的版本：

cd Shirone
node -p "require('./package.json').packageManager"
corepack pnpm --version

第一条命令检查项目声明，第二条检查 Corepack 的实际选择。

原始对话先后提到了 pnpm@9.14.4 和 pnpm@12.16.1，但没有提供足够证据证明它们就是当时项目声明的版本。本文整理时查询到的 Shirone main 分支声明为 pnpm@11.28.2，后续也可能变化，因此应以本地检出的代码为准。Shirone 的 package.json

在主目录执行 pnpm --version，不能单独证明项目的版本选择正确。完成版本检查后，再安装依赖并启动开发服务器，按终端实际输出验证访问结果。

原始材料没有完整的安装完成日志和页面验证记录，因此这里不把项目成功启动写成已经证实的结果。

经验小结#

版本更新不等于更适合项目。 Corepack 的价值在于按项目选择版本。一个比系统仓库更新的 pnpm，如果与项目要求不符，也不能据此认定更好。

启用入口时使用 sudo，不代表以后都要使用 sudo。 创建系统链接与日常安装依赖是两类操作。后续应以普通用户运行项目命令，也不能仅凭一次 sudo corepack enable 就断言缓存一定落在 root 家目录。

不要把个人配置方案写成整个社区的统一结论。 官方软件包页面能证明 Arch 提供 Corepack；具体选择系统入口、用户入口还是显式调用，仍取决于现有工具链和维护方式。

最终可迁移的判断方法是：先确认命令来自哪里，再看它准备写到哪里，最后进入项目验证版本。这样才能把权限问题、命令冲突和版本选择分别处理清楚。