npm global 不应该被当成系统级包管理器

npm global 最大的问题，是它看起来像一个系统级包管理器，但实际上只是某个 Node 版本附带的“局部全局”。随着越来越多 AI CLI 工具通过 npm 分发，这个长期被忽视的问题会变得越来越明显。

过去这个问题不太显眼，是因为 npm global 主要用来安装前端开发工具，例如 TypeScript、ESLint、Prettier、Vite 或某些脚手架。即使这些工具随着 Node 版本切换而消失，通常也只是影响某个项目的开发环境，而且很多团队本来就会把它们放进项目的 devDependencies 里。

但现在情况变了。Claude Code、Gemini CLI、Codex CLI、各种 MCP server、agent framework、部署工具和 AI 应用脚手架，越来越多都选择通过 npm 发布。它们不再只是“项目开发依赖”，而是逐渐变成开发者每天使用的个人工作台入口。这个时候，如果继续把 npm global 当成长期稳定的全局 CLI 管理方式，问题就会被放大。

npm global 的“全局”是有条件的

npm install -g 里的 global，很容易让人误以为它等价于 Homebrew、apt、pacman 这类系统级包管理器。但在实际环境里，npm 的 global prefix 往往绑定在当前 Node 安装之下。

如果你使用 nvm、fnm、asdf、mise、Volta 或 Homebrew 管理 Node，不同 Node 版本通常会对应不同的 npm、不同的全局 node_modules 目录，以及不同的 bin 路径。于是一个通过 npm global 安装的 CLI，并不是全局于整个系统，而是全局于“当前这套 Node/npm 环境”。

这就解释了一个常见现象：你切换 Node 版本之后，某些命令突然找不到了；你卸载一个旧 Node 版本之后，一批曾经安装过的 CLI 也跟着消失了；你明明记得装过某个工具，但 which 指向的路径却和预期不一致。

从 npm 的角度看，这并不是 bug。npm 本来就是 Node 生态的包管理器，它的核心职责是管理 JavaScript package，而不是维护操作系统层面的工具清单。global install 更像是历史上为了方便使用 Node CLI 而提供的能力。问题在于，今天 npm 正在被越来越多工具当成通用 CLI 分发渠道使用。

真正的风险不是“丢几个包”，而是工具层失去可控性

如果只是重新安装几个 CLI，这个问题看起来并不严重。但对高频使用的 AI 工具来说，风险不止于此。

第一，工具来源变得不透明。某个命令到底来自哪个 Node 版本、哪个 npm prefix、哪个 bin 目录，未必一眼能看出来。PATH 顺序稍微变化，就可能调用到另一个版本的工具。

第二，环境迁移变得困难。npm list -g --depth=0 只能列出当前 npm 环境下的全局包，不能代表整台机器所有 Node 版本下安装过的工具。等到换电脑、清理 Node、重装系统时，才发现自己的 CLI 工具层没有一份可靠清单。

第三，工具生命周期被错误绑定。一个 AI CLI 可能承载账号登录、模型配置、MCP server 配置、项目索引和本地缓存。它的生命周期应该接近“用户工作环境”，而不是跟着某个 Node 版本一起升级、切换或删除。

这也是为什么我认为，npm global 的问题本质上不是安装方式问题，而是边界问题：它承担了系统级 CLI 管理职责，却没有系统级包管理器应该具备的稳定生命周期、统一清单和环境隔离能力。

更合理的心智模型：把工具按生命周期分层

解决这个问题，不是完全不用 npm，而是不要把所有 CLI 都塞进 npm global。更好的做法，是按照工具的生命周期和使用场景分层管理。

系统级基础工具，例如 git、gh、jq、ripgrep、fd、fzf、tmux、ffmpeg，更适合交给 Homebrew、apt、dnf 或 pacman。它们不应该依赖某个 Node 版本存在。

项目级开发工具，例如 TypeScript、ESLint、Prettier、Vitest、Vite、Tailwind CSS，更适合放进项目的 devDependencies，然后通过 npm scripts、pnpm exec 或 npx 调用。这样项目可复现，团队成员之间也更一致。

一次性脚手架，例如 create-vite、create-next-app、shadcn init 这类命令，则更适合使用 npx、pnpm dlx 或 bunx。它们通常只在创建项目时使用一次，全局安装反而容易留下过期版本。

长期使用的 Node CLI，尤其是 AI CLI，则应该更谨慎。如果官方提供独立二进制、Homebrew tap、mise/asdf 插件或 Volta 支持，优先选择这些方式。只有在没有更好选择时，再把 npm global 当成备选方案。

AI CLI 让这个老问题重新变得重要

AI 工具的特殊性在于，它们不只是命令行程序，更像是本地工作流入口。一个 AI CLI 可能会读写仓库、调用模型、管理上下文、连接 MCP、调度子任务、访问浏览器或文件系统。它越接近日常工作流核心，就越不应该被放在脆弱、隐式、难迁移的全局 npm 环境里。

未来我们可能会安装越来越多 AI 相关 CLI：模型厂商的官方工具、agent runtime、MCP server、prompt 管理工具、RAG 工具、评测工具、部署工具。它们来自不同生态，却都可能因为“npm 发布最方便”而进入 npm global。短期看这很顺手，长期看会让个人开发环境变成一组散落在不同 Node 版本里的隐式状态。

因此，我更倾向于把 npm global 降级为“Node 生态 CLI 的临时安装方式”，而不是“个人工具层的主包管理器”。对于真正长期依赖的工具，应该尽量选择生命周期更稳定、清单更明确、路径更可控的管理方式。