nvm与pnpm离线迁移：Node.js开发环境完整打包指南

上个月帮一位同事迁移开发环境时踩了一整天的坑。事情是这样的：新入职的同事拿到一台离线测试机，要把整套 Node.js 开发需要的环境搬过去，nvm、nodejs、pnpm 一个都不能少。刚开始我以为拷贝几个文件夹就行，结果发现如果不理解这三者各自的目录结构和管理机制，离线迁移就是一场噩梦。后来我把整套流程跑通之后，也把之前踩过的坑一起整理成了这篇记录，希望能帮到要自己搭环境、或者正在给新同事和离线环境准备 Node 开发机的朋友。

这篇文章以 Windows 环境为主，macOS 和 Linux 的路径逻辑有差异，但核心原理完全通用。内容适合刚接触 Node 生态的初学者，也适合已经用 npm 很久但没折腾过 nvm 和 pnpm 的开发者。我会把整个搭建和迁移过程拆开讲，不光是命令，还会解释每一步为什么要这样做，以及每个报错背后的真正原因。

1. 整体思路与方案选型

1.1 为什么是 nvm + nodejs + pnpm 这套组合

先说个大背景。做过前端或者 Node 后端开发的人，大概率都经历过这种场景：项目 A 用的是 Node 16，项目 B 要求 Node 18，项目 C 内部工具链又依赖 Node 20。如果没有版本管理工具，你得反复去官网下载安装包卸载重装，光一个版本切换就能耗掉一个上午。

nvm 的价值就在这里。它可以在同一台机器上同时安装多个 Node.js 版本，用一条命令随时切换当前 PATH 里激活的版本。对 Windows 用户来说，最常用的实现是 nvm-windows，它和 macOS/Linux 上的 nvm 是两个不同的项目，千万不要混为一谈，后面我会单独说清楚它们的区别。

nodejs 本身自带的 npm 是 Node 生态的老牌包管理器，但它有一个比较明显的痛点：每个项目都会生成一份自己的 node_modules，100 个项目装了同一个依赖，磁盘里就躺了 100 份副本。pnpm 之所以越来越流行，就是因为它用“内容寻址存储 + 硬链接”的方式，把同一版本的依赖在全局只保存一份，然后通过硬链接放回每个项目的 node_modules 里。简单点类比，以前的 npm 是每个人家里都囤一箱矿泉水，pnpm 相当于小区里只有一个公共水仓，每户门口放一个空桶，用水的时候直接接过来。

这套组合的实际运行逻辑就是：nvm 管 Node 版本，Node 自带 npm，npm 可以装 pnpm，pnpm 负责真正管理项目依赖。平时开发和构建走 pnpm，遇到需要切换 Node 版本时用 nvm 快速切，整个工作流非常顺畅。

1.2 离线迁移的核心逻辑

离线迁移这个词听起来唬人，本质上就是解决一个问题：在没有外网的目标机器上，如何让原本需要联网下载的所有东西都能直接可用。

这里需要先建立一个概念。在线搭建环境时，工具链的“完整状态”由三部分组成。第一部分是 nvm 目录里各个 Node 版本的实际文件；第二部分是 pnpm 的全局 store（也就是依赖缓存仓库）；第三部分是各类配置文件，比如.npmrc、.pnpmrc、pnvm 的 settings.txt 等。这三样东西全部带齐，离线机器上就能恢复出 90% 的开发环境，剩下的只是让工具知道这些文件在哪里。

很多人迁移失败，就是只拷贝了项目代码，到目标机器上执行pnpm install后才发现网络不通，瞬间陷入“装不了依赖 = 什么都干不了”的僵局。反过来，如果把 store 和配置文件一并带过去，pnpm 在离线模式下一句pnpm install --offline就能从本地 store 里把所有依赖硬链接出来，速度甚至比在线安装还快。

所以整篇文章的主线就一条：先讲清楚 nvm、nodejs、pnpm 各自的安装和配置细节，再讲怎么把这三者的“状态”完整打包搬走，最后总结各种报错的排查思路。

2. nvm 的安装与配置实操

2.1 下载安装：nvm-windows 与 Linux 版不是同一样东西

先强调一下容易踩的第一个坑。很多人到网上搜 nvm，看到官方仓库叫 nvm-sh/nvm，那是给 macOS 和 Linux 用的。Windows 上用的是另一个项目叫 nvm-windows，作者是 coreybutler，不要下载错。

安装方式有两种。一种是下载nvm-setup.exe直接安装，下一步下一步就完了，非常省事。另一种是下载nvm-no-install.zip解压到某个目录自己配环境变量，适合习惯手动管理工具链的开发者。我之前偷懒直接用安装包，后来发现安装包会自动写环境变量，省了很多手工配置的麻烦，所以推荐新手直接选安装包方式。

不过安装路径要特别注意。nvm 的整个工作是靠目录结构和符号链接实现的，一旦路径里有中文、空格或者特殊符号，后面很容易出现各种莫名其妙的错误。比如C:\Program Files\nvm4这种带空格的路径，使用 nvm 时大概率会遇到命令找不到或者切换失败的问题。我自己的习惯是装到根目录下的一个纯英文路径，比如D:\nvm4。

装完之后打开系统环境变量，会看到 nvm 自动添加了几项：

• NVM_HOME指向 nvm 的安装目录，比如D:\nvm4
• NVM_SYMLINK指向一个专门的软链接目录，比如D:\nvm4\current
• PATH里增加了%NVM_HOME%和%NVM_SYMLINK%

这三项配置是 nvm 整个切换机制的关键。不理解也没关系，等到后面遇到permission denied类的问题再回头看这段话，你会恍然大悟。

2.2 修改 settings.txt：解决下载慢和默认架构问题

安装包装完后，nvm 目录下会生成一个settings.txt文件，里面的内容大概是这样的：

root: D:\nvm4 path: D:\nvm4 arch: 64 proxy: none node_mirror: https://npmmirror.com/mirrors/node/ npm_mirror: https://npmmirror.com/mirrors/npm/

其中arch表示默认下载 64 位还是 32 位的 Node 包，现在新机器基本都是 64 位，写死成 64 就行。重点提一下node_mirror和npm_mirror，这两个是国家软件镜像站提供的 Node 发行版镜像地址。国内网络环境下面直接下载 Node 官方包经常慢到怀疑人生，把这两个值配上后，nvm install的下载速度会有一个质的提升。

这个文件修改完不需要重启，存盘后重新打开终端即可生效。如果之后执行nvm install提示找不到版本号或者下载地址不对，问题多半出在 mirror 配置上。

2.3 核心命令与切换原理

nvm 的常用命令不多，日常用到的基本就这几个：

nvm list // 查看本机所有 Node 版本，带星号的是当前使用版本 nvm install 20.15.0 // 安装指定版本 nvm install lts // 安装最新长期支持版 nvm use 20.15.0 // 切换到指定版本 nvm alias default 20.15.0 // 设置默认版本，新开终端后自动激活 nvm ls available // 列出可在线安装的所有版本

第一次接触 nvm 的人可能会好奇，为什么nvm use之后，PATH 里不需要手工改东西？因为 nvm 的切换操作实际上是删掉了NVM_SYMLINK这个目录里原有的符号链接，再重新创建一个指向当前版本目录的链接。换句话说，D:\nvm4\current永远指向“当前应该生效的那个 Node 版本”，而 PATH 里的%NVM_SYMLINK%一直指向这个目录。这样一来，无论你怎么切版本，系统的 PATH 都不用变。

这个机制理解后，很多后续问题都能想通。举个例子，某个全局命令行工具如果在安装时把路径写死到了某个具体版本目录，nvm 一切换，它可能就找不到了。这个坑我在后面章节还会专门讲。

3. Node.js 的安装与环境变量配置

3.1 用 nvm 安装 Node 并激活

通过 nvm 安装 Node 不需要去官网下载安装包，所有事情都在命令行里完成。我自己习惯先装一个 LTS 版本，再看看项目需要什么额外版本。具体操作就是：

nvm install 20.15.0 nvm use 20.15.0

安装完成后直接验证版本：

node -v npm -v

这时候你会看到node -v输出版本号，npm -v也会输出一个版本号。这里要留个心眼：npm 的版本号是随 Node 版本捆绑的，并不是全局独立安装的。每个 Node 版本的目录下都有自己的一套 npm，这也是为什么后来通过npm i -g pnpm安装的 pnpm 会“跟随”当前 Node 版本走的原因——它被装进了当前激活的那个 Node 的全局目录里。

3.2 配置 npm 镜像源与全局参数

Node 装好之后，npm 的默认源大概率是官方源。国内使用经常会遇到下载包超时的问题，所以第一件事就是把它指到合法的镜像源。

npm config set registry https://registry.npmmirror.com/

可以通过npm config list看当前所有配置：

npm config list

除了 registry，还有两个经常被提及的配置项是prefix和cache。在 nvm 管理的 Node 环境下，我不建议随便去改这两个值。为什么？因为 npm 的全局包默认会安装到当前 Node 版本的目录下的node_modules中，这个位置天然由 nvm 接管。如果你手工把 prefix 改到一个自定义目录，短期内看似把全局包集中到了一处，但后续切换 Node 版本时，可能会出现全局工具和当前 Node 版本不匹配的兼容问题。

如果你确实想把 npm 全局包固定到一个独立目录，那就要做好“每次切换 Node 后手动处理依赖”的心理准备。对于大多数场景，我建议让 npm 全局包随着 nvm 的版本目录走，保持最简单、最不容易出错的路径逻辑。

3.3 理解 Windows 下全局命令的执行顺序

还有一个 Windows 特有知识点，很多人在这里栽过跟头。npm i -g安装的全局工具，在 Windows 下会生成一个同名目录，里面至少有三个文件：.cmd文件、.ps1文件、无扩展名的 shell 文件。在 PowerShell 中执行命令时，系统会按照特定顺序去匹配这些文件，而.ps1文件的执行又受“脚本执行策略”的约束。

这就导致了网上最常见的一个报错：

npm : 无法加载文件 D:\Program Files\nodejs\npm.ps1，因为在此系统上禁止运行脚本

这个报错的核心原因是 PowerShell 默认的 ExecutionPolicy 是Restricted，不允许运行任何.ps1脚本。而 npm 在 PowerShell 下实际调用的就是npm.ps1，因此被直接拦截。解决办法也很简单，在管理员终端里执行：

Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

它只对本机用户生效，不是系统全局的，安全性可控。执行后重新打开终端，npm 就不会再被拦截了。这个问题不解决，后续安装 pnpm 也会遇到一模一样的报错，所以建议装环境时顺便把这个执行策略一次改到位。

4. pnpm 的安装与配置要点

4.1 pnpm 的硬链接机制与现代 Monorepo

pnpm 能火，绝不是营销出来的，而是它在依赖管理上确实动了真格。用 npm 安装依赖时，每个项目都会完整复制一份依赖树；pnpm 则把所有依赖包的实体文件统一放在一个全局 store 里，项目里的 node_modules 只是通过硬链接和符号链接指向这些实体。这意味着如果你有 50 个项目都依赖 React 18，磁盘上只有一份 React 18 的真实文件，其它全是链接。

这种设计不仅省空间，还能显著提升安装速度。更重要的是，pnpm 对 Monorepo 有天然支持，一个仓库里多个子包，所有子包的依赖都抽到顶层 node_modules 和 store 里统一管理，避免重复安装。现在的开源生态里，像 Vite、Nuxt 这些知名项目都已经切换到了 pnpm，可以说它是社区默认的前端包管理器。

4.2 三种安装方式，我最终选了哪一种

pnpm 的安装方式大致有三种，我逐一试过，各有取舍。

第一种是直接通过 npm 安装：

npm install -g pnpm

这条命令最简单，但前面已经分析过，npm 的全局安装是跟着当前激活的 Node 版本走的。一旦你用 nvm 切换了 Node 版本，原来的 pnpm 就找不到了。新开终端输入pnpm -v，很大概率会提示“pnpm 不是内部或外部命令”。

第二种是官方提供的独立脚本安装。Windows 下执行：

iwr https://get.pnpm.io/install.ps1 -useb | iex

这条命令会从 pnpm 官网拉取安装脚本，并把 pnpm 装到用户目录下一个固定的位置，比如C:\Users\你的用户名\AppData\Local\pnpm。由于它不在任何特定 Node 版本目录里，nvm 切换版本不会直接弄丢它。它仍然依赖 PATH 里的 node 命令来运行，但工具本身是独立存在的。

第三种是 Node 内置的 Corepack 机制。Node 16.13 以后的版本自带 Corepack，执行corepack enable后就能直接使用 pnpm。听起来很优雅，但实际使用中我遇到过 Corepack 下载 pnpm 包卡住的情况，它背后的下载逻辑依然需要联网去拉二进制文件，离线环境里一样会尴尬。

我做了一张对比表，方便直观比较：

我最终选择了独立脚本安装。原因很简单：稳定、可迁移、不依赖具体 Node 版本。

4.3 配置 store 目录和镜像源

装完 pnpm 后，最重要的一件事不是pnpm -v验证版本，而是先把 store 目录固定到你自己想要的位置。

pnpm 默认的 store 目录在 Windows 上通常位于用户缓存目录下面，路径很长，而且散落在 C 盘。后续如果要迁移或者清理，找起来非常麻烦。我建议立刻把它改到专门的数据盘或某个固定的工具目录下：

pnpm config set store-dir D:\pnpm-store pnpm config set registry https://registry.npmmirror.com/

此时可以执行pnpm config list检查配置是否生效。另外还有一个非常实用的命令：

pnpm store path

它会直接输出当前 store 到底在哪。如果输出的路径和你配置的不一致，说明可能项目级.npmrc里还设置有别的store-dir，优先查一下项目目录下的.npmrc和环境变量。

4.4 pnpm 与 workspace 配置的基本须知

pnpm 在普通项目中可以直接使用，但如果你的项目根目录下存在pnpm-workspace.yaml文件，pnpm 就会把它当作一个 workspace 项目来对待，并强制要求该文件包含packages字段。

这个文件容易埋坑。我之前有一个旧项目，不知道谁放了一个内容为空的pnpm-workspace.yaml，结果执行pnpm install时报了一个让人摸不着头脑的错误：

ERR_PNPM_INVALID_WORKSPACE_CONFIGURATION packages field is missing or empty

解决办法就是检查这个文件，补上正确的字段。如果只是普通单包项目，里面写：

packages: - '**'

如果是 Monorepo，则按实际子包目录来配置。另外还有一个经常用到的命令是pnpm link，它用于把本地开发的库链接到当前项目，相当于软链。对于本地私有库的联调，一句pnpm link ../my-lib就能搞定，后续改代码立即生效，不需要反复 npm publish。

5. 离线迁移的完整实操记录

5.1 迁移前在源机器上先完成这些准备工作

离线迁移的第一步，不是在目标机器上折腾，而是在源机器上把所有“状态”整理好。我总结了一个口诀叫“三目录两文件”，你可以照着检查：

三目录指的是：

• nvm 安装目录，比如D:\nvm4，里面包含所有已安装的 Node 版本和 settings.txt
• pnpm store 目录，比如D:\pnpm-store，里面是所有依赖包的实体缓存
• pnpm 安装目录，也就是独立脚本安装的位置，通常是C:\Users\你的用户名\AppData\Local\pnpm

两文件指的是用户目录下的配置文件：

• .npmrc，记录 npm 和 pnpm 共享的 registry、store-dir 等配置
• .pnpmrc，如果存在，里面可能会有针对 pnpm 的额外全局配置

在源机器上动手打包之前，我建议先跑一遍全局包清单，确认哪些工具需要在新环境保留：

npm ls -g --depth=0 pnpm list -g

接着做一个操作：进入你已经拉好代码、并且执行过pnpm install的项目目录，再跑一次pnpm install或者pnpm fetch。这样做的目的是把项目所有的依赖包索引进 store 里补齐，确保 store 是最全的状态。这个过程可能在联网状态下很快，但它直接决定了目标机器离线下能不能成功恢复。

5.2 目标机器上恢复 nvm 和 Node 版本

这一步有两种做法。

做法一是全程离线安装。先把源机器的 nvm 整个目录拷贝到目标机器的同一个路径。比如源机器在D:\nvm4，目标机器也放到D:\nvm4，然后手工创建或修改环境变量，把NVM_HOME、NVM_SYMLINK和 PATH 都指向对应目录。这样目标机器上的 nvm 直接就能看到所有已经存在的 Node 版本目录，不需要联网下载。

做法二是在目标机器上先正常安装 nvm 安装包，然后把源机器 nvm 目录下各个v20.15.0之类的版本文件夹复制到目标机器 nvm 目录下的对应位置。这种方式更保险，因为安装包会自动帮你把环境变量、注册表相关项配置齐全，省去手工设置可能带来的遗漏。

不管哪种方式，都建议在恢复后打开新终端验证：

nvm list nvm use 20.15.0 node -v npm -v

nvm list如果能看到一堆已存在的版本号，说明安装目录被正确识别了。此时node -v和npm -v如果能正常输出版本号，环境恢复就成功了一半。

5.3 目标机器上恢复 pnpm 和 store

pnpm 的恢复逻辑和 nvm 类似。因为源机器使用的是独立脚本安装，整个 pnpm 目录本身就具备可迁移性。把它原样拷贝到目标机器同一个位置，然后确认系统 PATH 环境变量里包含了 pnpm 对应的 bin 目录。

如果目标机器上 PATH 没有自动添加，手工加一下。然后验证：

pnpm -v pnpm store path

这里有个非常重要的细节：如果目标机器上的 store 目录路径与源机器不一致，pnpm 需要重新初始化 store 的索引。最省事的方式是让 store 路径保持一致，两边的.npmrc配置也保持一致，这样从源机器拷贝过来的 store 就能被 pnpm 无缝识别。

如果必须使用不同路径，也不要慌。先把.npmrc里的store-dir改成新路径，然后把源 store 目录复制到新路径下。pnpm 启动时会扫描 store 目录的内容重新建立索引文件，虽然耗时取决于依赖包数量，但不会影响最终结果。

迁移完成后，回到项目目录执行一次：

pnpm install --offline

如果 store 完整，这个命令会以极快的速度完成，因为它不需要访问网络，纯粹是“从本地仓库提取依赖并创建硬链接”。如果中途提示某个包缺失，说明 store 不完整，需要回到源机器把缺失的包补齐后再拷贝一次。

5.4 为什么不能直接拷贝项目里的 node_modules

很多第一次接触离线迁移的人会有一个直觉操作：既然 node_modules 项目里已经有了，直接把整个项目文件夹包括 node_modules 一起拷过去不就行了？

我可以非常明确地说，pnpm 项目里千万别直接这么干。原因很简单，pnpm 的 node_modules 里大量使用的是符号链接和硬链接结构。符号链接是相对当前路径建立的，直接拷贝过去后，目标机器上没有对应的 store 实体文件，这些链接全部都会变成断链。即便能启动，运行时会报一堆“找不到模块”的错误，排查起来很痛苦。

正确的做法是把项目代码连同 lockfile（pnpm-lock.yaml）一起拷过去，然后把 store 也拷过去，最后在目标机器上重新执行pnpm install --offline。pnpm 会对照 lockfile 检查 store 里是否有对应依赖，有的话就直接从 store 里建立链接，整个过程非常快。

这里再补一个冷门但实用的命令pnpm store add。如果有一些不在 lockfile 里的离线 tgz 包，可以通过这条命令手工添加到 store 中，然后再用pnpm install --offline安装。虽然平时用到的场景不多，但在私有包离线迁移时，它是最可靠的兜底方案。

6. 常见问题与排查技巧实录

6.1 npm 或 pnpm 执行报 Permission Denied / 禁止运行脚本

这个问题的完整报错通常长这样：

npm : 无法加载文件 D:\Program Files\nodejs\npm.ps1，因为在此系统上禁止运行脚本 pnpm : 无法加载文件 C:\Users\xxx\AppData\Local\pnpm\pnpm.ps1，因为在此系统上禁止运行脚本

原因就是 PowerShell 的 ExecutionPolicy 限制导致.ps1脚本无法执行。解决方式之前说过，管理员终端里执行一条命令：

Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

这里我想补充两个细节。第一个，修改之后要重新打开终端窗口，很多人在当前窗口直接执行，发现还是报错，其实是 PowerShell 会话没有重新加载环境变量和策略。第二个，如果公司设备管理策略锁死了 ExecutionPolicy，不允许修改，那么可以改用 CMD 窗口执行命令，或者临时用powershell -ExecutionPolicy Bypass启动一个不受限制的终端来操作。

6.2 提示“pnpm 不是内部或外部命令”或“无法将 pnpm 项识别为 cmdlet”

这个报错出现的原因基本就是两个。第一种，pnpm 确实装了，但安装目录没有被加进 PATH 环境变量。第二种，pnpm 是通过npm i -g pnpm安装的，后来 nvm 切换了 Node 版本，它随着旧版本一起“消失”了。

排查顺序其实很快：

where pnpm

如果提示找不到，说明 PATH 里没有。先去检查源机器上安装 pnpm 时生成的那个目录路径，把它手动加入 PATH，重启终端。如果where pnpm能找到路径，但执行还是报错，那大概率是 nvm 切换导致全局命令路径变化。解决方式就是改用独立脚本安装，或者切换到安装 pnpm 时的那个 Node 版本再重新执行npm i -g pnpm。

6.3 nvm 切换 Node 版本后，VSCode 里某些全局工具报 Permission Denied

这个场景很经典，比如你平时用 VSCode 的终端跑全局命令，某天执行nvm use 20.15.0切到另一个版本后，突然发现某个通过 npm 全局安装的工具报起了/xxx: Permission denied，而且重启 VSCode 也没用。

这里其实和 pnpm 的问题同源。很多 CLI 工具在安装时会把自己的 shim 或者执行入口放到当时激活的 Node 版本的全局目录里，或者把 PATH 中的某个路径写死。nvm 一切换版本，原来的 shim 入口路径失效，新的版本目录下又没有这个工具的安装记录，自然就报“permission denied”。

解决思路有两个。一个是把那个工具在“当前激活的 Node 版本”下重新安装一遍，让它的 shim 指向新的版本目录。另一个是如果你希望它不随 nvm 变化，就使用工具的独立安装方式，把它装到用户目录，通过固定的 PATH 入口去调用。我个人在后面遇到这种情况时，会选择后者，它从根上解决了“nvm 一切换，全局工具就失踪”的问题。

6.4 报错 ERR_PNPM_INVALID_WORKSPACE_CONFIGURATION

这个报错的排查方法前面提过，直接看项目根目录下有没有pnpm-workspace.yaml。有就打开检查，packages字段是否存在、是否为空，格式是否合法。没有文件的话还要检查一下是不是命令敲错了，比如在 monorepo 根目录执行pnpm install时误把 workspace 配置文件删了，也会触发这个错误。

补充一个容易被忽略的点：pnpm-workspace.yaml里如果 glob 写错了，会把一些不该当成子包的东西识别成 workspace 包，导致 install 时出现奇怪的依赖提醒。建议是非 monorepo 项目干脆不要放这个文件，放了就保证它内容是完整的。

6.5 pnpm 在线安装下载失败或超时

在线安装 pnpm 或安装项目依赖时，如果频繁出现“ETIMEDOUT”“ECONNRESET”“Failed to find response”之类的错误，绝大多数情况是网络问题。优先检查镜像源是否配置正确：

pnpm config get registry

如果指向的是官方源，建议改成镜像源。如果已经配置了镜像还是失败，那就是代理或内网限制问题。可以试试关闭系统代理，或者临时在命令行里设置环境变量告诉 pnpm 不要走代理。离线环境下，最好的做法是提前在联网机器上把 store 补齐，然后走--prefer-offline或--offline安装，这是我最推荐的方案。

6.6 报错信息速查表

写在最后的一点实际经验

把所有过程走完之后，我最大的体会是：离线迁移最关键的不是“拷贝文件”，而是理解 nvm、nodejs、pnpm 各自把状态放在了哪里。nvm 的 Node 版本在 nvm 目录，pnpm 的依赖实体在 store，配置文件在.npmrc和.pnpmrc。把这三个位置搞清楚，离线迁移其实就是在搬三样东西，剩下的只是换了个路径重新告诉工具“东西在这里”。

所以如果让我给一个建议，那就是不要等到要迁移了才去整理环境。从搭建第一天起，就把 nvm 目录、pnpm store、全局配置放在固定的、可预期的路径下，并且写进自己的环境初始化脚本里。这次是离线迁移，下次可能就是新电脑入职、服务器部署，甚至是公司内网环境整体搬迁，这套思路都能直接复用到不同场景。

我个人还有一个比较“笨”但很有效的习惯：每次搭建完环境，都会把当时的node -v、npm -v、pnpm -v、pnpm store path这几个输出结果存成一个environment.txt放到项目目录里。未来不管是自己换机器，还是同事遇到环境问题，翻出这个文件按图索骥，比靠回忆排查高效得多。