前阵子有个群友问我“我刚装完 Node.js网上教程都说要改全局安装目录、配置环境变量不然以后装全局包会出问题你怎么看”我回了他一句如果你只是正常开发这两步确实基本是多余的。这个标题其实很有讨论价值因为你在任何搜索引擎搜“npm 全局包目录修改”能搜出来几百篇文章清一色教你先建一个node_global目录、再改 prefix、再配 PATH步骤写得比淮扬菜谱还细。但你有没有想过为什么官方安装包装完就能直接跑npm i -g根本没人逼你改目录为什么很多老手重装系统后从来不碰这些配置全局包照样用得好好的先说观点默认情况下不需要修改全局包的安装目录也不需要手动配置环境变量。网上的教程绝大多数是把简单问题复杂化甚至是在传播一套“历史遗留的重复劳动”。这篇文章把背后的原理说透顺便聊聊哪种极端情况下你才需要考虑动这些配置。希望你看完能少走弯路不再被那些套娃教程牵着鼻子走。1. 先说清楚“全局包”到底被装到哪了很多人一听到“修改全局安装目录”第一反应是“是不是默认装的地方不对”实际上Node.js 官方安装包在 Windows 上默认做配置就是完全够用的。1.1 默认的 npm 全局目录机制npm 的全局安装路径由配置项prefix决定。在 Windows 上官方安装包装完之后装进C:\Program Files\nodejs\这个目录。而npm config get prefix的输出结果通常就是上面那个路径。关键在这里这个路径已经在环境变量 PATH 里了。安装包在装的时候就帮你把nodejs目录加进了系统 PATH。所以全局包装完后二进制文件会直接软链到C:\Program Files\nodejs\下面你打开新的命令行直接用不需要额外操作。用npm root -g看目录也很直观。默认就是C:\Program Files\nodejs\node_modules所有全局安装的包都堆在这里面。这地方有点像是你的系统工具箱所有全局命令都从这里出来。1.2 在 macOS 和 Linux 上是什么情况如果你用 nvm 装的 Node情况更简单。nvm 会把不同版本的 Node 装进~/.nvm/versions/node/vXX这种目录切换版本后全局包路径也会跟着变。这里有个小细节nvm 的模式下每个 Node 版本有自己的全局包目录根本不共享。用系统包管理器装的呢比如 apt 装的 nodejsnpm 的 prefix 常常是/usr/local全局包就放/usr/local/lib/node_modules也不用改。因为系统早就把/usr/local/bin放进 PATH 了。所以默认机制设计得很干净官方已经把“装完就能用”这件事想清楚了装完之后立刻开始用才是正常状态。2. 那为什么网上这么多教程教人改目录这绝非空穴来风这个问题的历史成因和现实原因都要掰开看。2.1 历史原因老版本 Node 和权限坑早年间有些发行版通过包管理器装的 Nodenpm 的全局根目录会被指到系统目录下比如/usr/lib/node_modules普通用户没有写入权限。那时候装全局包需要sudo npm i -g每次提示权限错误体验很糟糕。改目录的教程正是为了解决那个时代的痛点——把全局目录改到用户主目录下绕开权限问题。但放到现在你直接装官方安装包根本没有权限问题C:\Program Files\nodejs安装器已经替你处理好了。网上大量教程讲的是十几年前的老解决方案不知道从哪年开始被疯狂转载越传越像“标准步骤”其实早就不合时宜了。2.2 现实原因教程作者在“用旧地图找新大陆”很多教程的写手并没有真正搞清楚 PATH、prefix、bin 目录之间的依赖关系只是把以前的教程重新包装一遍。有个典型的逻辑错误是改完prefix到D:\node_global之后npm 不会自动把新目录加进 PATH必须手动改环境变量。于是教程里必然跟着出现“配置 PATH”一步这出现得多了看起来就特别像官方标准流程。更搞笑的是改完 prefix、配好 PATH有些教程还会让你把npm cache、npm userconfig也挪走。挪完发现原来的全局包都不见了又让你把原目录里的包重新装一遍。一套组合拳下来目录确实变了但你已经浪费了大半天得到的环境和默认的没本质区别。2.3 改目录的本质治标不治本再往深处说一句。改全局目录也好、配置 PATH 也好解决的不适感到底是什么呢最常见的原因是无非这几个觉得 C 盘空间被占用装全局包报 EACCES 或者 EPERM 错误看教程说“不能装在 C 盘”但真正碰到这些情况首先该排查的是权限设置、磁盘剩余空间、Node 安装包来源是否靠谱而不是上来就改目录。工具链没坏你修它干嘛3. 默认目录不修改日常开发的几个真相有些人担心“全局包装默认目录以后清理很麻烦”这也是典型的想象问题。实际体验下来默认路径非常省心。3.1 安装、升级、卸载都很方便装全局包就一条命令npm install -g typescript不用 sudo不用指定目录不用管 PATH。升级也是同样一条命令npm 会直接覆盖到原目录。卸载时更省事npm uninstall -g typescript干净利落不会留下一个不知道什么时候加进去的自定义环境变量。对比一下改了目录之后的情况全局包装在D:\node_global但 npm 升级的时候偶尔会把 prefix 的配置搞丢于是命令行突然找不到命令了你又得去检查环境变量。这种事我见过不少改目录省下的那点 C 盘空间不够你排查一次 PATH 问题的时间成本。3.2 npx 的出现已经颠覆了全局包的使用习惯这是最容易被旧教程忽略的一点。现在你随手要用一个工具比如create-react-app、vuepress根本不需要全局安装。npx create-react-app my-app这条命令会自动下载、执行、然后用完就走不污染全局环境。以前需要全局装的脚手架工具现在 npx 全都能干。全局包的使用频率大幅下降你再去为“全局包目录”费心配置多少有点刻舟求剑了。3.3 日常“全局包”最常用的其实是这几个类型我平时真正长期全局装的包一只手数得过来yarn、pnpm这种包管理器还有nodemon这类开发辅助工具。这些工具装一次能用半年以上更新频率很低。它们放在默认目录里从来不需要我改任何配置。如果你发现自己装全局包特别频繁、还老是要清理重装那大概率是工作流有问题不是目录的问题。比如经常手动重复安装同一类脚手架工具这种场景下我更建议用 npx 而不是全局装。4. 为什么我不建议你改改了之后反而带来的新问题这部分我想说几个实际踩过的坑不是理论推演。4.1 自定义目录会导致 Windows 权限报错变多改到 D 盘目录、配合 PATH 配置这里藏着一个坑Windows 的运行库在加载某些全局包时会试图往prefix目录写入编译缓存或配置文件。如果 D 盘那个目录的权限设置不合理比如是根目录直接建的文件夹报 EPERM 的频率比用默认目录高得多。4.2 升级 Node.js 时要额外处理路径用官方安装包更新 Node 到新版安装器是针对默认路径做升级的。你把全局包挪到自定义目录Node 升级不会管你那个目录。你不是只要重新装 Node还得保证环境变量 PATH 里那个自定义路径依然存在且正确。升级一次全查一遍虽然不复杂但多做这一步明显没有收益。4.3 团队协作时最容易出问题如果你在团队里分享脚本里面用了全局命令比如vue create、nest new默认环境大家跑起来都很顺畅。一旦某个成员改了全局路径环境变量不统一脚本在他机器上表现可能完全不一样。这个排错难度极大因为 JavaScript 代码本身没报错就是命令找不到或者版本不对。同一套代码为什么别人行你不行十有八九就是这种环境差异造成的。5. 有没有真正需要改目录的场景我也不是一刀切说永远不需要改。确实有几个特定场景改了目录有道理但注意这跟普通开发完全无关。5.1 公司电脑或自动化构建环境如果在一台受管制的办公电脑上用户权限被锁死确实无法写入Program Files这时候把全局目录改到用户目录算是一个合理的妥协。又或者单位要求开发环境统一装在某个固定盘符下为了合规你只能手动指定 prefix。这类需求本质上属于组织环境约束不是 Node 本身的问题。5.2 内网穿透工具链共存有些网络环境部署离线 npm 镜像时希望全局包放在固定数据盘避免系统盘重置后工具链全部丢失。这种情况下手动配置 prefix 也有道理。但你会专门做系统镜像管理根本不会纠结“哦原来 Node.js 默认路径不行啊”这种入门问题。5.3 Node 版本管理器已经能解决隔离需求如果你纠结的其实是“全局包不要互相污染”真正值得装的是 nvm 或者 fnm而不是手动改 prefix。版本管理器自动控制每个 Node 版本各自的全局目录切换 Node 版本之后全局包自动跟着切换完全不需要手工改环境变量。6. 如果你非要“彻底干净”也不必改目录以前有个很常见的诉求是“我不喜欢 Program Files我想把 Node.js 装到 D 盘。”这不需要在 npm 层面改 prefix直接在安装时用官方安装器的界面改安装路径就行它会自动把 Node 路径加进 PATH全局包目录也会跟着变。注意这跟手动配置 prefix 是两码事后者是装完再来改配置前者是安装时的原生选项。6.1 只想重装系统后不用重复搞环境这种情况最好的做法不是改 node_modules 的位置而是维护一份package.json列清楚全局工具清单。{ name: global-tools, private: true, devDependencies: { typescript: ^5.3.0, nodemon: ^3.0.0, pnpm: ^8.15.0 } }全局依赖进清单重装时一行命令装回来。这比手动备份目录、再折腾权限要可靠得多。同样的思路也适用于 Docker 化开发容器里直接在那条npm install后面追加全局包即可改目录纯属多此一举。6.2 如果真遇到权限报错先查这三样很多人被报错吓到了才去找改目录的教程。这里按顺序排查确认 Node 是否装在系统目录看process.execPath确认当前用户对C:\Program Files\nodejs有写入权限确认用了管理员权限是否还会报错三步走完绝大多数“权限错”都能定位到是安装包本身损坏或者杀毒软件拦截跟全局默认目录没半点关系。7. 实操中的“实际无用”步骤清单这里把网上教程最典型的几套操作拉出来逐条对应说明为什么实际上不是必须的。建新目录并修改 prefixmkdir D:\node_global npm config set prefix D:\node_global这条命令执行后真正发生的只是 npm 把全局包装到了新路径但PATH 不会自动更新。哪怕装了包命令行照样找不到命令必须继续配置环境变量。第一步只是制造问题第二步才是补救两个一起做才显得不那么突兀。手动配置 PATH# 控制面板 - 环境变量 - 新增 D:\node_global这步是为了让上一步的产物能被命令行发现。也就是说你手动搭建了一套“新的默认路径”而 Node 官方安装包本来已经给你搭好了一套完整可用的。这工作做一遍不费劲但重装系统之后还要再做一遍每台新电脑都要再做一遍换一台别人编译好的镜像还得再做一遍。禁用 npm 缓存或迁移缓存npm config set cache D:\node_cache这步在我看来最没必要。缓存只是加速下载位置在哪对你使用无感。挪缓存目录的唯一作用是把 C 盘空间腾出一点。但如果你 C 盘空间真紧张到这种程度就该直接清理系统盘大文件了靠挪 npm 缓存省不了几个 GB。8. 一点实在建议真正值得花时间的地方比起折腾全局目录下面这几件事对日常开发体验的提升更明显也更值得你花时间理解。8.1 用 npm config 了解现状而不是照抄网上配置npm config list这条命令会把当前生效的所有配置项列出来包括 build-in、cli、userconfig 各种来源。输入一次你就能明白 npm 配置的真实结构。以后看到“修改 .npmrc”这种教程你也知道它改的是什么。8.2 学会使用--prefix参数做临时安装有种场景是你想在指定路径临时试一个工具又不想污染全局环境。不需要永久改配置用参数就一行事npm install --prefix D:\temp_tools typescript这条命令只在当前命令生效范围内指定了 prefix不会写进任何配置文件用完即弃。对测试、CI 环境非常友好还不用改 PATH。8.3 善用npm exec而不是频繁装全局包新版 npmv7 以上自带npm exec和 npx 类似。你可以临时跑某个包的命令而不全局安装比如npm exec --packagetypescript -- tsc --version这在和旧版本工具并存时尤其有用。你完全没必要给每个工具准备一个专属全局目录更不用为了它们去调环境变量。9. 写在后面的经验总结我反复说过很多次技术教程看多了最危险的就是照单全收。安装 Node.js 之后那两招“标配操作”在我这几年的实践中基本没派上过用场。真正让我发现自己不需要改目录的瞬间是在重装电脑之后——装好官方安装包跑npm i -g几个常用工具打开新终端直接就能用那一刻我就明白了默认的设计就是够用的。如果你是因为网上教程看多了焦虑我可以明确告诉你不改目录完全不影响你开发。全局包装哪不是重点核心是你对 npm、PATH、环境变量的底层认知。把这几个概念搞明白比你会背一百条“一键配置脚本”有价值得多。最后给看完这篇文章的你一个可落地的方向回你自己机器上敲一句npm config get prefix然后看一眼那个目录是不是出现在 PATH 里了。如果是你就可以安安心心继续写代码了。至于再有人发你那篇“必须改目录”的教程你大可以微微一笑心里默念那是上一个时代的事情我这套默认配置挺好的。
前阵子有个群友问我“我刚装完 Node.js网上教程都说要改全局安装目录、配置环境变量不然以后装全局包会出问题你怎么看”我回了他一句如果你只是正常开发这两步确实基本是多余的。这个标题其实很有讨论价值因为你在任何搜索引擎搜“npm 全局包目录修改”能搜出来几百篇文章清一色教你先建一个node_global目录、再改 prefix、再配 PATH步骤写得比淮扬菜谱还细。但你有没有想过为什么官方安装包装完就能直接跑npm i -g根本没人逼你改目录为什么很多老手重装系统后从来不碰这些配置全局包照样用得好好的先说观点默认情况下不需要修改全局包的安装目录也不需要手动配置环境变量。网上的教程绝大多数是把简单问题复杂化甚至是在传播一套“历史遗留的重复劳动”。这篇文章把背后的原理说透顺便聊聊哪种极端情况下你才需要考虑动这些配置。希望你看完能少走弯路不再被那些套娃教程牵着鼻子走。1. 先说清楚“全局包”到底被装到哪了很多人一听到“修改全局安装目录”第一反应是“是不是默认装的地方不对”实际上Node.js 官方安装包在 Windows 上默认做配置就是完全够用的。1.1 默认的 npm 全局目录机制npm 的全局安装路径由配置项prefix决定。在 Windows 上官方安装包装完之后装进C:\Program Files\nodejs\这个目录。而npm config get prefix的输出结果通常就是上面那个路径。关键在这里这个路径已经在环境变量 PATH 里了。安装包在装的时候就帮你把nodejs目录加进了系统 PATH。所以全局包装完后二进制文件会直接软链到C:\Program Files\nodejs\下面你打开新的命令行直接用不需要额外操作。用npm root -g看目录也很直观。默认就是C:\Program Files\nodejs\node_modules所有全局安装的包都堆在这里面。这地方有点像是你的系统工具箱所有全局命令都从这里出来。1.2 在 macOS 和 Linux 上是什么情况如果你用 nvm 装的 Node情况更简单。nvm 会把不同版本的 Node 装进~/.nvm/versions/node/vXX这种目录切换版本后全局包路径也会跟着变。这里有个小细节nvm 的模式下每个 Node 版本有自己的全局包目录根本不共享。用系统包管理器装的呢比如 apt 装的 nodejsnpm 的 prefix 常常是/usr/local全局包就放/usr/local/lib/node_modules也不用改。因为系统早就把/usr/local/bin放进 PATH 了。所以默认机制设计得很干净官方已经把“装完就能用”这件事想清楚了装完之后立刻开始用才是正常状态。2. 那为什么网上这么多教程教人改目录这绝非空穴来风这个问题的历史成因和现实原因都要掰开看。2.1 历史原因老版本 Node 和权限坑早年间有些发行版通过包管理器装的 Nodenpm 的全局根目录会被指到系统目录下比如/usr/lib/node_modules普通用户没有写入权限。那时候装全局包需要sudo npm i -g每次提示权限错误体验很糟糕。改目录的教程正是为了解决那个时代的痛点——把全局目录改到用户主目录下绕开权限问题。但放到现在你直接装官方安装包根本没有权限问题C:\Program Files\nodejs安装器已经替你处理好了。网上大量教程讲的是十几年前的老解决方案不知道从哪年开始被疯狂转载越传越像“标准步骤”其实早就不合时宜了。2.2 现实原因教程作者在“用旧地图找新大陆”很多教程的写手并没有真正搞清楚 PATH、prefix、bin 目录之间的依赖关系只是把以前的教程重新包装一遍。有个典型的逻辑错误是改完prefix到D:\node_global之后npm 不会自动把新目录加进 PATH必须手动改环境变量。于是教程里必然跟着出现“配置 PATH”一步这出现得多了看起来就特别像官方标准流程。更搞笑的是改完 prefix、配好 PATH有些教程还会让你把npm cache、npm userconfig也挪走。挪完发现原来的全局包都不见了又让你把原目录里的包重新装一遍。一套组合拳下来目录确实变了但你已经浪费了大半天得到的环境和默认的没本质区别。2.3 改目录的本质治标不治本再往深处说一句。改全局目录也好、配置 PATH 也好解决的不适感到底是什么呢最常见的原因是无非这几个觉得 C 盘空间被占用装全局包报 EACCES 或者 EPERM 错误看教程说“不能装在 C 盘”但真正碰到这些情况首先该排查的是权限设置、磁盘剩余空间、Node 安装包来源是否靠谱而不是上来就改目录。工具链没坏你修它干嘛3. 默认目录不修改日常开发的几个真相有些人担心“全局包装默认目录以后清理很麻烦”这也是典型的想象问题。实际体验下来默认路径非常省心。3.1 安装、升级、卸载都很方便装全局包就一条命令npm install -g typescript不用 sudo不用指定目录不用管 PATH。升级也是同样一条命令npm 会直接覆盖到原目录。卸载时更省事npm uninstall -g typescript干净利落不会留下一个不知道什么时候加进去的自定义环境变量。对比一下改了目录之后的情况全局包装在D:\node_global但 npm 升级的时候偶尔会把 prefix 的配置搞丢于是命令行突然找不到命令了你又得去检查环境变量。这种事我见过不少改目录省下的那点 C 盘空间不够你排查一次 PATH 问题的时间成本。3.2 npx 的出现已经颠覆了全局包的使用习惯这是最容易被旧教程忽略的一点。现在你随手要用一个工具比如create-react-app、vuepress根本不需要全局安装。npx create-react-app my-app这条命令会自动下载、执行、然后用完就走不污染全局环境。以前需要全局装的脚手架工具现在 npx 全都能干。全局包的使用频率大幅下降你再去为“全局包目录”费心配置多少有点刻舟求剑了。3.3 日常“全局包”最常用的其实是这几个类型我平时真正长期全局装的包一只手数得过来yarn、pnpm这种包管理器还有nodemon这类开发辅助工具。这些工具装一次能用半年以上更新频率很低。它们放在默认目录里从来不需要我改任何配置。如果你发现自己装全局包特别频繁、还老是要清理重装那大概率是工作流有问题不是目录的问题。比如经常手动重复安装同一类脚手架工具这种场景下我更建议用 npx 而不是全局装。4. 为什么我不建议你改改了之后反而带来的新问题这部分我想说几个实际踩过的坑不是理论推演。4.1 自定义目录会导致 Windows 权限报错变多改到 D 盘目录、配合 PATH 配置这里藏着一个坑Windows 的运行库在加载某些全局包时会试图往prefix目录写入编译缓存或配置文件。如果 D 盘那个目录的权限设置不合理比如是根目录直接建的文件夹报 EPERM 的频率比用默认目录高得多。4.2 升级 Node.js 时要额外处理路径用官方安装包更新 Node 到新版安装器是针对默认路径做升级的。你把全局包挪到自定义目录Node 升级不会管你那个目录。你不是只要重新装 Node还得保证环境变量 PATH 里那个自定义路径依然存在且正确。升级一次全查一遍虽然不复杂但多做这一步明显没有收益。4.3 团队协作时最容易出问题如果你在团队里分享脚本里面用了全局命令比如vue create、nest new默认环境大家跑起来都很顺畅。一旦某个成员改了全局路径环境变量不统一脚本在他机器上表现可能完全不一样。这个排错难度极大因为 JavaScript 代码本身没报错就是命令找不到或者版本不对。同一套代码为什么别人行你不行十有八九就是这种环境差异造成的。5. 有没有真正需要改目录的场景我也不是一刀切说永远不需要改。确实有几个特定场景改了目录有道理但注意这跟普通开发完全无关。5.1 公司电脑或自动化构建环境如果在一台受管制的办公电脑上用户权限被锁死确实无法写入Program Files这时候把全局目录改到用户目录算是一个合理的妥协。又或者单位要求开发环境统一装在某个固定盘符下为了合规你只能手动指定 prefix。这类需求本质上属于组织环境约束不是 Node 本身的问题。5.2 内网穿透工具链共存有些网络环境部署离线 npm 镜像时希望全局包放在固定数据盘避免系统盘重置后工具链全部丢失。这种情况下手动配置 prefix 也有道理。但你会专门做系统镜像管理根本不会纠结“哦原来 Node.js 默认路径不行啊”这种入门问题。5.3 Node 版本管理器已经能解决隔离需求如果你纠结的其实是“全局包不要互相污染”真正值得装的是 nvm 或者 fnm而不是手动改 prefix。版本管理器自动控制每个 Node 版本各自的全局目录切换 Node 版本之后全局包自动跟着切换完全不需要手工改环境变量。6. 如果你非要“彻底干净”也不必改目录以前有个很常见的诉求是“我不喜欢 Program Files我想把 Node.js 装到 D 盘。”这不需要在 npm 层面改 prefix直接在安装时用官方安装器的界面改安装路径就行它会自动把 Node 路径加进 PATH全局包目录也会跟着变。注意这跟手动配置 prefix 是两码事后者是装完再来改配置前者是安装时的原生选项。6.1 只想重装系统后不用重复搞环境这种情况最好的做法不是改 node_modules 的位置而是维护一份package.json列清楚全局工具清单。{ name: global-tools, private: true, devDependencies: { typescript: ^5.3.0, nodemon: ^3.0.0, pnpm: ^8.15.0 } }全局依赖进清单重装时一行命令装回来。这比手动备份目录、再折腾权限要可靠得多。同样的思路也适用于 Docker 化开发容器里直接在那条npm install后面追加全局包即可改目录纯属多此一举。6.2 如果真遇到权限报错先查这三样很多人被报错吓到了才去找改目录的教程。这里按顺序排查确认 Node 是否装在系统目录看process.execPath确认当前用户对C:\Program Files\nodejs有写入权限确认用了管理员权限是否还会报错三步走完绝大多数“权限错”都能定位到是安装包本身损坏或者杀毒软件拦截跟全局默认目录没半点关系。7. 实操中的“实际无用”步骤清单这里把网上教程最典型的几套操作拉出来逐条对应说明为什么实际上不是必须的。建新目录并修改 prefixmkdir D:\node_global npm config set prefix D:\node_global这条命令执行后真正发生的只是 npm 把全局包装到了新路径但PATH 不会自动更新。哪怕装了包命令行照样找不到命令必须继续配置环境变量。第一步只是制造问题第二步才是补救两个一起做才显得不那么突兀。手动配置 PATH# 控制面板 - 环境变量 - 新增 D:\node_global这步是为了让上一步的产物能被命令行发现。也就是说你手动搭建了一套“新的默认路径”而 Node 官方安装包本来已经给你搭好了一套完整可用的。这工作做一遍不费劲但重装系统之后还要再做一遍每台新电脑都要再做一遍换一台别人编译好的镜像还得再做一遍。禁用 npm 缓存或迁移缓存npm config set cache D:\node_cache这步在我看来最没必要。缓存只是加速下载位置在哪对你使用无感。挪缓存目录的唯一作用是把 C 盘空间腾出一点。但如果你 C 盘空间真紧张到这种程度就该直接清理系统盘大文件了靠挪 npm 缓存省不了几个 GB。8. 一点实在建议真正值得花时间的地方比起折腾全局目录下面这几件事对日常开发体验的提升更明显也更值得你花时间理解。8.1 用 npm config 了解现状而不是照抄网上配置npm config list这条命令会把当前生效的所有配置项列出来包括 build-in、cli、userconfig 各种来源。输入一次你就能明白 npm 配置的真实结构。以后看到“修改 .npmrc”这种教程你也知道它改的是什么。8.2 学会使用--prefix参数做临时安装有种场景是你想在指定路径临时试一个工具又不想污染全局环境。不需要永久改配置用参数就一行事npm install --prefix D:\temp_tools typescript这条命令只在当前命令生效范围内指定了 prefix不会写进任何配置文件用完即弃。对测试、CI 环境非常友好还不用改 PATH。8.3 善用npm exec而不是频繁装全局包新版 npmv7 以上自带npm exec和 npx 类似。你可以临时跑某个包的命令而不全局安装比如npm exec --packagetypescript -- tsc --version这在和旧版本工具并存时尤其有用。你完全没必要给每个工具准备一个专属全局目录更不用为了它们去调环境变量。9. 写在后面的经验总结我反复说过很多次技术教程看多了最危险的就是照单全收。安装 Node.js 之后那两招“标配操作”在我这几年的实践中基本没派上过用场。真正让我发现自己不需要改目录的瞬间是在重装电脑之后——装好官方安装包跑npm i -g几个常用工具打开新终端直接就能用那一刻我就明白了默认的设计就是够用的。如果你是因为网上教程看多了焦虑我可以明确告诉你不改目录完全不影响你开发。全局包装哪不是重点核心是你对 npm、PATH、环境变量的底层认知。把这几个概念搞明白比你会背一百条“一键配置脚本”有价值得多。最后给看完这篇文章的你一个可落地的方向回你自己机器上敲一句npm config get prefix然后看一眼那个目录是不是出现在 PATH 里了。如果是你就可以安安心心继续写代码了。至于再有人发你那篇“必须改目录”的教程你大可以微微一笑心里默念那是上一个时代的事情我这套默认配置挺好的。
