2026-10-30 修订：收窄“命令永在、运行时必随 nvm 改变”的断言，撤回用
native binary not installed直接推断 Node ABI 不兼容的解释，并更新全局目录与构建脚本的排查方法。
🚀 省流助手（速通结论）
- 固定 pnpm 的全局命令目录，可以减少 nvm 切换带来的入口变化；前提是该目录在当前 shell 的 PATH 中，且没有同名命令遮挡。
- CLI 是否使用当前 Node，要检查它的启动方式：PATH 查找、指定 Node 路径和原生程序，行为并不相同。
native binary not installed只能说明所需程序没有就绪，不能仅凭报错认定 Node 版本或 ABI 不兼容。- 先用
type -a和pnpm bin -g查入口，再检查启动脚本、安装日志及版本要求。
ⓐ 命令能找到，为什么仍然启动失败
type -a node pnpm claude
node --version
pnpm --version
pnpm bin -g
这些输出分别回答：有哪些候选命令、当前 Node 和 pnpm 是哪个版本、这份 pnpm 把全局入口放在哪里。command -v claude 有输出，只证明当前 shell 找到了一个入口。
原文把 Error: claude native binary not installed. 直接解释为切换到 Node 16 后的原生模块不兼容，这个结论缺少依据。安装脚本被拦截、平台包未完整安装、启动占位文件未替换等，都需要结合具体版本和日志核查，不能用同一条报错推导唯一原因。
ⓑ 全局目录固定，也要检查 PATH
pnpm setup 用于设置 pnpm 的用户目录与命令入口。目录布局随版本和配置变化，不应把所有版本都写成 ~/Library/pnpm/bin。setup 说明
需要配置时，在平时使用的交互终端执行：
pnpm setup
按输出提示重新打开终端，再检查：
printf '%s\n' "${PNPM_HOME-}"
pnpm bin -g
pnpm list -g --depth=0
type -a pnpm claude
pnpm 10 与 pnpm 12 的已有安装可能使用不同布局，机器也可能设置了自定义目录。以 pnpm bin -g 返回的有效目录为准。 如果提示目录不在 PATH，先核对当前 shell 是否加载了对应配置。bin 命令说明
nvm 下 npm 的全局包通常按 Node 安装前缀区分；固定目录中的 pnpm 全局入口与它并非“行为完全一致”。两者共存时，同名命令仍受 PATH 顺序影响。nvm 全局包说明
ⓒ 运行时由启动方式决定
| 实际启动方式 | 切换 nvm 后可能发生什么 |
|---|---|
脚本通过 #!/usr/bin/env node 或 exec node 查找 Node | 通常使用启动时 PATH 中的 Node |
| 启动脚本选择邻近或指定路径的 Node | 可能继续使用该 Node，需要读脚本确认 |
| 原生可执行文件，或包装器转交给原生程序 | 原生程序本身未必依赖系统 Node；包装器可能另有要求 |
pnpm 的命令入口不一定直接就是包作者写的 JavaScript 文件，也可能是一层 shell 启动脚本。仅看交互终端的 node --version，不能证明任意 CLI 使用了同一运行时。pnpm 启动脚本实现说明
先确认命令不是别名或函数，再检查文件类型：
type -a claude
command -v claude
file -L "$(command -v claude)"
确认是文本脚本后，再用编辑器查看它最终调用哪个程序。不要直接把原生二进制当文本打印。包的 engines 声明与实际安装方式也需要一起核对。
ⓓ 构建脚本被拦截时怎样处理
如果安装日志明确出现 ignored builds／待批准构建，再检查当前 pnpm 的批准机制：
pnpm help approve-builds
pnpm approve-builds -g
这是审批操作，会允许选中包执行代码。应先确认具体包、版本和脚本用途，只批准需要且可信的项目。支持该命令的版本可据此处理全局包；更旧的版本先查对应文档。approve-builds 说明
原文给出的两种通用“修复”不再保留：
- 拼接
pnpm root -g后直接执行某个install.cjs：包结构和全局目录可能变化，也绕过了包管理器的审批流程。 - 用
--ignore-scripts false当成强制放行：关闭“忽略脚本”不等于跨版本绕过所有构建审批策略。
如果原因是包声明的 Node 要求不满足，才切换到符合要求的已安装 Node，再验证。安装缺失、脚本审批与运行时兼容属于不同问题。
ⓔ 项目内命令的优先级
pnpm exec 会把项目的 node_modules/.bin 加入 PATH，使本地依赖的命令优先可用，但不会保证缺少本地命令时一定报错；后续 PATH 中仍可能存在同名命令。exec 官方说明
因此，“加上 pnpm exec 就强制只用本地版本”的说法不准确。需要确认本地依赖存在，并检查实际命令来源。例如已安装 eslint 的项目可以检查：
pnpm exec which eslint
npx 还可能涉及临时下载，不能将它与 pnpm exec 简化成完全相同的查找过程。
ⓕ 切换测试要分别看入口与结果
下面只在子 shell 中切换已安装的 Node，退出后不会改变当前终端所用版本：
(
for node_version in 22 24; do
nvm use "$node_version" || exit 1
node --version
command -v pnpm
pnpm --version
command -v claude
claude --version
done
)
版本号换成自己的已安装版本。路径不变证明入口稳定；版本命令成功证明程序至少能启动。登录、网络访问或真实业务操作仍需另外验证，不能用 --version 代替。
ⓖ 清理重复安装前先确认归属
列出 npm 与 pnpm 各自管理的全局包，记录版本和入口，再决定保留哪份：
npm prefix -g
npm list -g --depth=0
pnpm list -g --depth=0
type -a claude
确认来自哪个管理器、哪个 Node 前缀后，再在对应环境使用该管理器卸载。某些工具确实需要按 Node 版本分别安装，没有必要把“全局工具只用一种管理器”规定为通用规则。
固定入口解决可发现性，运行时检查解决兼容性；迁移验证需要覆盖这两部分。
