虚拟环境：让每个项目住进自己的房间

01先看一个现场

周一你接手同事的项目。README 第一行写着：

pip install -r requirements.txt

你敲下去，系统回你一句：

error: externally-managed-environment

你不知道这是什么。搜了一下，有人让你加 sudo。你加了，装上了，项目跑起来了。下午你去跑自己那个半年没动的老项目——起不来了。因为上午那一步，把两个项目共用的那个库换成了新版本。

这就是「环境」问题最典型的样子：你以为你只是在装一个包，其实你改的是整台机器共享的一层东西。

这个现场里藏着三个问题，整篇文章就是在回答它们：

• 我敲 python 的时候，跑起来的是哪一份 Python？
• 我装的包，落到硬盘的哪个目录里去了？
• 别人拿到我的仓库，怎么才能装出和我一模一样的那两份东西？

如果你只有 5 分钟：直接跳到 §03 四层楼 看那张总表，再看 §13 一页纸速查表。剩下的章节是给「我要真的动手配一套」准备的。

02「环境」这个词，实际指两个抽屉

「环境」听起来很玄，其实拆开只有两个抽屉。理解这两个抽屉，后面所有工具都能对上号。

抽屉一：敲一个命令时，系统去哪里找它（叫 PATH）

PATH 是一张目录清单，存着一个又一个文件夹的路径。（它就是一个环境变量，只是重要到几乎每个环境问题都要先看它一眼。）你在终端敲 python 的时候，系统从左到右把这张清单看一遍，找到第一个叫 python 的文件就执行它，后面的不再看。

这意味着：「当前用的是哪个 Python」并不是一个固定事实，而是「这一刻 PATH 上谁的排位靠前」。你在终端里看到的 python，在你的编辑器里、在定时任务里、在 AI 帮你跑的那条命令里，可能是完全不同的另一份——因为它们各自有自己的 PATH。

# 看看这张清单长什么样
echo $PATH
# 看看所有叫 python 的，按 PATH 顺序列出（第一个就是会跑起来的那个）
which -a python

抽屉二：装的包，落到哪个目录（Python 叫 site-packages，Node 叫 node_modules）

「装一个包」这个动作，本质就是下载一堆文件放进某个目录。Python 默认的落点是那一个 Python 安装自带的 site-packages 目录（site 是「站点」，指这份 Python 安装自己的地盘）；Node 默认的落点是当前项目目录下的 node_modules。

于是问题来了：Python 的默认落点是「这一份 Python 的所有项目共用」的。你给 A 项目装的库，B 项目也看得见——这就是开头那个现场的成因。

两个抽屉要一起动，只动一个会出事

03四层楼：所有工具都在这四层里

你会在各种教程里撞到几十个名字，它们看起来都在做「让环境干净」这一件事。实际上它们分属四层，每层解决的问题完全不同。（先说一个后面反复出现的词：依赖＝你的项目运行时要用到的、别人写好的库。你写代码时写的那几行 import，对应的就是它们。）先记住这张表，后面每一节都在展开其中一层。

遇到陌生名词时，怎么判断它属于哪一层

只有一个动作：看它「动了什么」。

• 它只是让某个命令指向别的版本，别的什么都没装 → 第 1 层。
• 它在项目目录里多出一个文件夹（.venv、node_modules、vendor/）→ 第 2 层。
• 它要下载一个打包好的文件系统、启动一个「机器里的机器」→ 第 3 层。
• 它只往进程里塞 键=值，不碰硬盘 → 第 4 层。

三层容易误解的地方

04第一层：换语言版本

这一层要解决的问题很朴素：一台机器上，Python 3.9 和 3.14 我都得留着。老项目锁在旧版本上，新项目想用新语法。

它们用的是同一套把戏：把 PATH 里排第一的那份换掉

回忆 §02 的抽屉一。既然「用哪个版本」等于「PATH 上谁排第一」，那么版本管理器做的事就一句话：切换时，把某个版本目录塞到 PATH 最前面。具体实现有三种风格：

逐个认识：你实际会敲的命令

pyenv install 3.13.15        # 装一个版本（pyenv install -l 看全部可装）
pyenv local 3.13.15         # 在当前目录写 .python-version，这一棵树都用它
pyenv global 3.12.14         # 设默认版本
pyenv versions              # 看装了哪些
pyenv which python3         # 看现在这个命令最终指向哪个可执行文件

# 把版本写进项目：
echo "24" > .nvmrc
nvm install                # 读 .nvmrc，没装就装上
nvm use                    # 读 .nvmrc 切的版本，切到当前窗口
nvm install --lts
nvm ls                     # 看装了哪些

[toolchain]
channel = "nightly-2020-07-10"
components = [ "rustfmt" ]
targets = [ "wasm32-unknown-unknown" ]

跨语言的两把「总开关」：asdf 和 mise

如果你同时写 Python、Node、Terraform、kubectl……给每个语言装一个版本管理器太累。这两个工具让一份配置文件管所有语言。

# mise.toml —— 一份文件，同时钉住三个语言的版本 + 一个变量
[tools]
node = "24"
python = "3.13"
terraform = "1.13"

[env]
APP_ENV = "api"

mise use node@24          # 装并写进 mise.toml
mise install              # 按配置文件把缺的都装上
mise current              # 看当前目录实际生效的版本

05第二层 · Python 篇：把包关进项目里

第二层要解决的问题是这样的：A 项目要 requests 2.28，B 项目要 2.32。你为了跑 A 升级了它，B 挂了。原因是它们用的是同一个包目录。解决办法就是给每个项目一个自己的包目录——这就是「虚拟环境」这个词最狭义的意思。

标准做法：venv（Python 自带，不用装任何东西）

Python 从 3.3 起把 venv 收进了标准库（正式说法见 PEP 405——PEP 是 Python 社区用来记录「正式提案」的编号文档，一个编号对一份决议），所以只要你有 Python，就有这个命令。

# 在项目根目录建一个虚拟环境，惯例放在 .venv 里
python3 -m venv .venv

# 激活（macOS / Linux）
source .venv/bin/activate

# 激活（Windows PowerShell）
# .venv\Scripts\Activate.ps1

# 以后 pip 和 python 就都是这个环境里的了
python -m pip install requests
python -m pip freeze > requirements.txt   # 导出当前装的版本清单

# 退出
deactivate

它到底做了什么

在 .venv 目录里放三样东西：一个叫 pyvenv.cfg 的说明文件（写着「我是基于哪个 Python 建的」）、一个 bin/（Windows 上是 Scripts/）目录，里面有一个指向真解释器的 python、以及一个空的 lib/python3.x/site-packages/。

「激活」这个动作本身没有魔法：它只是把 .venv/bin 放到 PATH 最前面（回到 §02 的抽屉一）。所以激活并不是必须的——你完全可以直接写 .venv/bin/python -m pip install requests，效果一样。

三个容易忽略的规矩

• 不要提交到 Git，也不要放项目代码进去。echo ".venv/" >> .gitignore 一行搞定。
• 不要移动或复制它。官方原话是「可丢弃的、不可移植的」——换了路径或者换了机器，重建比搬家便宜得多。
• 想确认自己是不是在虚拟环境里，看这一句：python -c "import sys; print(sys.prefix != sys.base_prefix)"。打印 True 就说明在虚拟环境里。这个判断很有用，因为很多工具（pip、打包工具）内部就是用这个条件来决定「该不该拦你」。

「能装出一样的」：从 requirements.txt 到锁文件

光有虚拟环境还不够。虚拟环境解决的是「装到哪」，没解决「装哪个版本」。别人拿到你的 requirements.txt，如果是手写的、只写了 requests，他今天装到的版本可能和你三个月前装的不一样。

于是有了锁文件（lock file）：一份记录了「所有包及其精确版本」的清单，目的是让别人装出跟你字节级一致的一套。

Poetry 的最小工作流

poetry new myproject          # 或者在一个已有目录里 poetry init
poetry add pendulum           # 找合适的版本约束，装好，并写进 pyproject.toml
poetry install               # 按 poetry.lock 装；没有锁文件就先解析再生成
poetry run python app.py     # 在这个环境里跑命令，不用手动激活

# 看环境在哪、用哪个解释器
poetry env info --path
poetry env use 3.13          # 指定用哪个 Python 建环境

uv 的最小工作流

uv 是 Astral 公司（也是 Ruff 的作者）用 Rust 做的，2026 年 9 月的最新版本是 0.12.14。官方对它的定位是一句很狂的话：「一个工具取代 pip、pip-tools、pipx、poetry、pyenv、twine、virtualenv」——注意这几个名字横跨了本文的第 1 层和第 2 层。

# 装 Python 本身（第一层的活）
uv python install 3.13 3.12

# 新项目
uv init example
cd example
uv add requests              # 装依赖 + 更新 uv.lock + 更新 pyproject.toml
uv run python -c "import requests; print(requests.__version__)"
uv sync                      # 别人 clone 之后跑这个，按 uv.lock 装出一模一样的

# 只想建个虚拟环境、继续用熟悉的 pip 命令也行
uv venv --python 3.12.0

# 跑一个一次性的命令行工具，不装进任何环境
uvx pycowsay "hello"          # uvx = uv tool run

项目里的 .venv 默认就放在 pyproject.toml 旁边——这一点对编辑器很友好，因为编辑器沿目录就能找到它，自动补全才不会认错解释器。

当你要装的不只是 Python 包：conda

纯 Python 的库，pip 就够了。但有些包本身带着 C 代码，需要系统里有对应的库才能编译。conda 的解法是把「非 Python 的东西」也当成依赖一起装。

官方文档给出的对照很直白：venv 是「依赖系统里已有的那份 Python」，而 conda 的「Python 独立于系统」；venv 用 pip 扩展，conda 能装 R、Perl、任意可执行文件这类非 Python 依赖。

conda create -n myenv python=3.13 # 建一个带指定 Python 版本的环境
conda activate myenv
conda env list                # 看有哪些环境（conda info --envs 等价）
conda deactivate

# 导出给别人
conda env export > environment.yml
conda env create --file environment.yml

conda create --prefix ./envs python=3.13 requests
conda activate ./envs           # 注意：用了 prefix 就只能用路径激活，不能用 --name 找它

当你要装的是一条命令，不是一个库：pipx

有些 Python 包是给你敲的（比如一个格式化工具），不是给你 import 的。这类东西用 pip install 装进某个环境，会带来两个问题：它的依赖可能和你项目的依赖打架；想删的时候，你得记得它当初拖来了哪些东西。

pipx 的做法是每个命令行工具给一个独立的虚拟环境，然后把可执行文件挂到 PATH 上让你直接敲。官方把它类比成 macOS 的 Homebrew、JavaScript 的 npx。

pipx install ruff            # 每个工具一个独立环境，互不干扰
pipx run cowsay "一次性的，不留下"
pipx list
pipx upgrade

06第二层 · Node.js 篇：默认就隔离，但隔离得不一样

如果你从 Python 过来，第一件会惊讶的事是：Node 项目通常根本不需要「建虚拟环境」。因为 npm 默认就把包装进项目目录：

官方文档写得很清楚——本地安装（默认行为）把东西放进当前项目根目录的 ./node_modules 里；只有加了 -g 才装到全局，全局的位置是「Node 安装所在的那个目录」，Unix 上通常是 {prefix}/lib/node_modules，而可执行文件挂在 {prefix}/bin。

所以 Node 的项目级隔离，是用「一个目录」实现的，而不是用一个环境。当你 import 或 require 一个包时，Node 会从当前文件所在目录开始，一层层往上找 node_modules。

那为什么 Node 还需要「版本管理器」？

因为 node_modules 只隔离了包，Node 这个程序本身还是全机一份。你机器上装的是 Node 24，而某个老项目需要 Node 18——这就是 §04 里 nvm / fnm / volta 的用武之地。它们和 npm 管的是两件完全不同的事，这一点在第 09 节还会再点一次。

锁文件：package-lock.json 与 pnpm-lock.yaml

和 Python 一样，光有目录隔离不够，还得锁版本。npm install 会顺手生成 package-lock.json，里面记着整棵依赖树的精确版本。CI 或服务器上应该用 npm ci——它严格按锁文件装，不会顺手升级任何东西。

pnpm：把「省磁盘」和「更严格」一起做了

npm 和 Yarn 一个项目一份完整拷贝，100 个项目用到同一个包就是 100 份。pnpm 的官方动机页讲了它的两个不同：

• 内容寻址的仓库 + 硬链接。所有包文件集中存一份，多项目共享；同版本升级时「只有变化的文件进仓库」。（硬链接＝让同一个文件在两个地方同时「出现」，但磁盘上只存一份。）
• 不把依赖「提升」到顶层。官方原话说：npm / Yarn Classic 会把所有包提升（hoist，即统一摊平摆到模块目录的最外层）到模块目录的根，于是「源代码能访问到没有声明为自己的依赖的包」；pnpm 改用符号链接（一个很小的「指路文件」，本身不含内容，只是指向别处），只把你声明过的暴露出来（根目录里的条目是指向 node_modules/.pnpm 的符号链接）。

另外还有一个走得更远的选择：Yarn PnP——它干脆不生成 node_modules，让 Node 按一份清单去缓存里加载包。好处是安装快、没有那个巨大的目录；代价是有些工具还认死 node_modules 的存在。

Corepack：锁住「包管理器自己的版本」

还有一个更细的层次：npm 自己也有版本，Yarn 和 pnpm 更是有整套大版本之间的不兼容。Corepack 解决的就是这个——让一个项目声明「我要用哪个包管理器、哪个版本」，别人 clone 下来自动用对。

# package.json
{
  "packageManager": "pnpm@10.4.1+sha224.953c8..."
}

corepack enable             # 把 yarn / pnpm 的转发命令挂到 PATH 上
corepack use pnpm@10.4.1    # 拉取指定版本并写进 package.json
corepack install -g        # 装成全局默认

一张命令对照表

07第二层 · 其他语言：三种不同的解题思路

Python 和 Node 是两条最主流的路，但「怎么隔离」这件事并没有唯一答案。看另外几种语言的解法，能帮你以后遇到新生态时快速归类。

思路一：把包装进项目目录（Ruby / Bundler）

Ruby 这边的分工是本文里最清楚的：rbenv 管 Ruby 版本，Bundler 管项目依赖，两者不重叠。而且 gem（Ruby 的包）装在哪是跟着 Ruby 版本走的——gem env home 会告诉你它在 ~/.rbenv/versions/<版本>/lib/ruby/gems/ 下面。也就是说，rbenv 本身不提供项目级隔离。

项目级隔离由 Bundler 负责。它的官方说法是「确保 Ruby 能找到 Gemfile 里所有的 gem 以及它们的依赖」——做法是把这些 gem 放到加载路径上。Gemfile 声明依赖，bundle install 会下载并评估全部 gem，形成「唯一一份权威的清单」，写进 Gemfile.lock。

# Gemfile
source "https://rubygems.org"
ruby "3.3.0"
gem "rails", "~> 7.1"

# 应用入口文件里要显式启用，Bundler 才会真正接管加载路径
require 'bundler/setup'

bundle install
bundle exec rails server   # 在 Bundler 选定的这套 gem 里跑命令

注意那个 require 'bundler/setup'：Bundler 不是自动生效的，它要你主动在程序入口声明一下。这是 Ruby 生态一个容易忘的点——Gemfile 写得很漂亮但代码里没 require，运行时用的还是系统里那些 gem。

思路二：不装进项目，装进一个共享缓存（Go）

Go 的答案很不一样：依赖不放进你的项目目录。它们下载到本机一个模块缓存里，多个项目共享；项目里只留两个文件：

• go.mod——记录依赖，以及「最低可接受版本」（官方原话：require 这一行「跟踪的是你的模块依赖的那个模块的最低版本」）。
• go.sum——记校验和，用来验证下载下来的东西没被改过。官方明确说要跟代码一起提交。

更特别的是，Go 把「用哪个版本的工具链」也写进了项目文件。这是一个很少见的思路：语言自己解决自己的版本问题。

默认情况下 GOTOOLCHAIN=auto。这意味着：如果你机器上的 Go 比模块要求的旧，go 命令会自己去下载一个合适的版本接着跑，并且打印一行说明它换了——像这样：

go: module example.com/widget@v1.2.3 requires go >= 1.24rc1; switching to go 1.27.9

而且它很守规矩：换完之后会把这次实际用的工具链版本写回 go.mod，所以下次再跑就不会重复切换、也不会重复打印。

思路三：一个声明文件说清一切（Rust）

Rust 的 rustup 把「工具链」定义为「一套 Rust 编译器安装」。项目根放一个 rust-toolchain.toml（见 §04 的示例），就能把频道、组件、目标平台一起钉住。这个文件适合提交到仓库，官方还建议同时把 Cargo.lock 也提交。

它的选择顺序值得记一下，因为它很典型：命令行 +名字 > RUSTUP_TOOLCHAIN 环境变量 > 目录 override > toolchain 文件 > 全局默认。越「临时、越局部」的设置优先级越高。其他生态的版本管理器基本也是这个规律，记一条能省很多猜。

Java：版本归版本，依赖归依赖

JDK 的版本用 SDKMAN 这类工具管（sdk install java、sdk env 读项目里的 .sdkmanrc）。而项目依赖交给 Maven / Gradle，它们的本地仓库是一份整机共享的缓存——所以 Java 生态里，「每个项目一套隔离的依赖」这件事，传统上是在构建工具层面解决的，不是靠一个虚拟环境目录。

08第三、四层：整个系统，与环境变量

前两层管的是「项目里的东西」。剩下两层管的是项目之外：操作系统本身，以及进程启动时读到的变量。

第三层：容器——连系统一起换

当你的项目需要的不只是一个库，而是「系统里得有个特定的 C 库」「得有个 Ubuntu 才能装的编译工具」时，第 1、2 层就管不了了。这时候要把整个「小机器」换掉。

Docker 官方文档对容器的定义是：「容器是给你的应用的每个组成部分使用的、被隔离的进程」；每个容器把自己需要的东西都带全了，「不依赖任何预先安装好的东西」。你要的东西打包成一个镜像（image，可以理解成一份只读的安装盘模板），运行起来就是容器。

docker run -d -p 8080:80 docker/welcome-to-docker   # 下载镜像并后台运行
docker ps                                        # 看正在跑的容器
docker stop <容器ID前几位>

那容器里的项目还需要 venv 吗

dev container：把容器配置写进仓库

容器的一个痛点是「配置在哪」——你在本地 docker run 了一堆参数，同事并不知道。开发容器（dev container）的解法是把配置写成一个提交到仓库的文件。

官方对自己的定义是：「一份开放规范，给容器补充开发专用的内容与设置」。配置文件名是 devcontainer.json，常用字段有：

{
  "features": { "ghcr.io/devcontainers/features/github-cli": {} },
  "forwardPorts": [3000],
  "postCreateCommand": "yarn install"
}

这份文件的价值在于：新同事打开项目，环境就已经是他要的那个了——不用在 README 里写十步安装说明，还写不准确。

第四层：环境变量

最轻的一层。direnv 是一个「shell 扩展」——它做的事是根据你当前所在目录，加载或卸载环境变量。进目录时加载，出目录时卸掉。

# .envrc（放在项目根目录）
export DATABASE_URL="postgres://localhost:5432/dev"
export NODE_ENV="development"

direnv allow .    # 第一次必须显式允许，见下方说明

两个边界要清楚：① direnv 本身不装任何包，它只注入环境变量；② 它只管「export 出去的变量」，官方的说明提到别名和函数（alias / function）是不能跨回你的 shell 的。它和 asdf、mise 这类工具是互补的——mise 干脆把这两件事做进同一个工具里了。

09最容易混的七组名词

这一节是给你的「查号台」：听到一个名字拿不准，来这里对一下。第三列是判断法，比定义更有用。

10一个具体场景：新同事的第一天

把前面所有东西放进一个你能照着走的场景里：你加入一个团队，仓库里有一个 Python 后端和一个 Node 前端，还配了一个命令行工具。你要在半小时内让它跑起来。

ls -a
# pyproject.toml + uv.lock        → Python，用 uv 管（§05）
# requirements.txt                → Python，用 venv + pip 管（§05）
# package.json + pnpm-lock.yaml   → Node，用 pnpm（§06）
# .nvmrc / .python-version        → 这个项目要求的语言版本（§04）
# .envrc                          → 有环境变量要加载（§08）
# .devcontainer/devcontainer.json → 整包环境已备好，可以直接用（§08）

# 跨语言方案：一份 mise.toml 管住所有版本
mise install
mise current

# 或者分开装（Python 用 uv，Node 用 fnm）
uv python install 3.13
fnm install
fnm use

# 有 uv.lock 就走这条
uv sync
uv run python -m backend

# 只有 requirements.txt 就走这条
python3 -m venv .venv
source .venv/bin/activate
python -m pip install -r requirements.txt

node -v && which node      # 先确认版本对不对（对比 .nvmrc）
corepack enable            # 按 package.json 的 packageManager 字段准备
pnpm install --frozen-lockfile
pnpm dev

uvx some-tool --help      # Python 工具，跑完不留痕
pipx install some-tool    # 想常驻就装成独立环境
pnpm dlx some-tool        # Node 工具的一次性跑法

direnv allow .            # 加载项目里的 .envrc
env | grep DATABASE_URL  # 确认变量真的进来了

devcontainer up --workspace-folder .
# 或者在编辑器里选「Reopen in Container」

11场景索引：你现在是什么状态

这张表是按「你的处境」查的。左边找到最像你的一句，右边直接给你该做的事和该看的节。

在 AI 编程里，你撞见这些名词的场景其实很集中，无非四种：① 你让 AI 帮你跑起来一个项目，它给的安装命令在你机器上报错（多半是层不对，或者仓库里有锁文件而 AI 用了另一个工具）；② 你让 AI 装一个库，它装成功了，但你另一个项目崩了（它装进了全局）；③ AI 说「找不到这个包」，而你的终端里明明是好的（它跑在一个没激活虚拟环境的进程里）；④ 你想让 AI 用某个特定版本来干活（得先有 .nvmrc / .python-version 这类文件，它才有依据）。下面四行就是按这四种情况写的。

12常见坑与排错

坑 1：error: externally-managed-environment

这是 01 节那个现场的真身。它的来历有正式文档：有一份编号 PEP 668 的提案，专门处理「操作系统的包管理器和 pip 打架」的问题——因为 pip 默认往全局装东西，而系统自己也用同一批目录。

它的机制是一个标记文件：如果 Python 的标准库目录里存在一个叫 EXTERNALLY-MANAGED 的文件，pip 就会在「你不在虚拟环境里」的时候拒绝安装。Debian、Fedora 以及 Homebrew、MacPorts 这些「发行版」（Linux 或软件包体系的不同发行版本，各自维护自己的软件清单）都会放这个文件。

坑 2：建了虚拟环境，pip 却还装到全局

九成是因为没激活，或者激活之后换了终端窗口。激活只影响当前这个 shell——新开一个窗口，PATH 就回到原样了。

# 到底现在用的是哪一个？三个命令一起看
which -a python
python -c "import sys; print(sys.prefix != sys.base_prefix)"   # True = 在虚拟环境里
python -m pip --version

顺带一个更隐蔽的原因：你的编辑器 / AI 助手跑的进程，未必继承你终端里激活的那个环境。编辑器的 Python 解释器通常是单独配置的（去找 .venv 目录），而命令行工具可能根本没走你的 shell 配置。判断法永远是同一句：在出问题的那个进程里，打印它自己的解释器路径。

坑 3：把 .venv 或 node_modules 提交进了仓库

# .gitignore
.venv/
node_modules/
__pycache__/

已经提交过的，需要 git rm -r --cached .venv 把它从版本库里摘掉（文件本身保留在本地）。虚拟环境是「可丢弃、不可移植」的，别人应该用锁文件重建，而不是拿到你打包的那一份。

坑 4：pyenv 和 conda 互相打架

两个工具都想决定「哪个 Python 排第一」。它们的解法都是改 PATH，所以谁后动谁就赢——表现为「我明明 pyenv local 了 3.13，怎么还是 3.11」。排查顺序：

pyenv version          # pyenv 认为现在该用哪个
conda info --envs      # conda 当前激活了哪个
which -a python        # 真相在这：按 PATH 顺序列出

建议的做法是别让它们管同一个项目：用 conda 的项目就在 conda 环境里干活，用 pyenv 的项目就别激活 conda。

坑 5：nvm 在编辑器 / 脚本里不生效

因为 nvm 是一段 shell 函数，不是程序。非交互式 shell（脚本、CI、编辑器调起的任务）通常不会加载你的 .zshrc，所以它根本不知道 nvm 存在。两个应对：脚本里用绝对路径指向要用的 node；或者换用 fnm / volta / mise 这类「真二进制 + 按目录自动切换」的工具。

坑 6：corepack 命令找不到

见 §06：它从 Node 25 起不再随 Node 分发。装一个就好：npm install -g corepack。

通用排错法：一次问三个问题

13一页纸速查表

这张表是给你以后回来查的。左边找到你的技术栈，第二列是「换版本」，第三列是「隔离依赖」。

最容易记反的一对

• Python 的默认行为是「全局的」——你不主动建 .venv，装包就是全局污染。
• Node 的默认行为是「项目内的」——你不用建虚拟环境，只要保护好自己的 Node 版本。

14参考来源与时效说明

本文的关键事实来自下面这些一手来源。官方文档的结构是为「已经懂的人」写的，本文只借它核对事实，行文顺序是按理解障碍重新排的。

99一句话总结