刚接触 Jupyter Notebook 那会儿我一直没搞明白“多环境”到底是怎么一回事。装了 Anaconda创建了虚拟环境也在环境里pip install了一堆包结果打开 Notebook 新建文件时下拉菜单里永远只有默认的Python 3我新建的环境根本看不到也没法切换过去。当时在网上翻到不少人问“jupyter notebook 配置多环境及内核切换方法”但答案零零散散看完还是一头雾水。后来把kernel、ipykernel、kernelspec这几个概念彻底理清才明白这件事其实一点都不玄乎核心就是三步建环境、装 ipykernel、把内核注册给 Jupyter。这篇文章我打算把完整的配置流程、切换方法以及我实际踩过的坑一次讲清楚。不管你是用 Anaconda 管理环境还是用原生的venv、virtualenv配置思路都是相通的。适合所有被 Notebook 多环境问题困扰的朋友尤其是做数据分析和机器学习、经常要在不同 Python 版本和依赖组合之间来回切换的人。1. 为什么 Jupyter 的多环境问题经常让人一头雾水1.1 环境、解释器、内核三者到底是什么关系想搞清楚内核切换首先要分清三个概念环境environment、解释器Python interpreter、内核kernel。很多人配置失败根源就是把这仨当成了一回事。环境是一个独立的圈子圈子里有自己的一套 Python 可执行文件、pip、各种第三方库。比如你用 conda 创建了一个叫py311的环境那这个环境里的 Python 是 3.11site-packages目录里装的是给 3.11 用的包这些都是隔离的。解释器就是环境里那个python可执行文件。它在 Linux/macOS 下通常在环境路径/bin/pythonWindows 下在环境路径\python.exe。你写的 Python 代码最终就由它来执行。同一个环境里可能同时存在系统 Python、conda 的 Python、或者自编译的 Python注意别混淆。内核就比较特殊了。Jupyter 本身是一个“前端页面 后端执行器”的架构页面负责展示代码和结果真正跑代码的是后端进程。前后端之间的桥梁就是一个叫“内核”的进程通常是 IPython 内核。内核会调用某个环境里的 Python 解释器来执行代码。我习惯用一个生活化的类比环境就像厨房解释器是灶台内核则是菜单上指向某个厨房的“招牌菜入口”。你点菜的时候菜单上显示的是菜名Python 3.11后厨真正做主的是对应的厨房里的灶台解释器。1.2 网上教程那么多为什么还会失败网上讲 Notebook 多环境的教程不少但很多教程只给了命令没讲原理。比如有人说“创建环境后直接pip install ipykernel就行”但如果你的命令是在 base 环境下执行的而不是在目标环境里执行的包就装错地方了内核自然指向错误解释器。还有一类失败发生在系统里存在多个 Python 的情况下。比如你同时装了 Anaconda 和系统自带的 Python命令行里执行python时路径可能已经被某个.bashrc或环境变量劫持了执行python -m ipykernel install时注册的内核指向的是另一个 Python最终打开 Notebook 后 import 不到包或者 Python 版本对不上。另外一个常见误区是把“内核名”和“环境名”搞混。jupyter kernelspec list显示的是内核名比如py311和 conda 环境名也是py311可能相同也可能不同。真正决定代码运行环境的是内核背后的kernel.json文件里写的解释器路径而不是名字。1.3 这篇文章能解决什么问题我会把配置多环境的标准流程重头讲一遍包括 conda 和 venv 两种方式再讲内核切换的日常操作包括新建、切换、删除、重命名最后专门用一节整理我实战中遇到过的坑每一条都给出完整的排查思路。看完全文你应该能独立完成从“环境构建”到“内核注册”再到“日常切换”的闭环遇到问题也知道从哪里下手查。2. 动手前的准备先选好环境管理工具不要在中途换车配置多环境之前先要想清楚用哪套环境管理工具。工具选对了后面能省掉大量麻烦中途换了再返工真的会怀疑人生。2.1 Anaconda 与 Miniconda 的选择Anaconda 和 Miniconda 底层都是 conda 这个包管理器区别只在于 Anaconda 预装了很多科学计算和数据分析常用的包开箱即用但体积巨大Miniconda 只装 conda、Python 和一些基础依赖体积小想用什么自己装。我个人的建议是如果你做的方向主要是数据分析、机器学习、科学计算并且不想折腾依赖安装装 Anaconda 省心如果你更习惯自己的包管理方式或者硬盘空间紧张Miniconda 就够了。反正多环境的核心流程跟用 Anaconda 还是 Miniconda 没多大关系区别只在创建环境时是否自带一堆科学计算包。conda 最大的优势是能直接管理 Python 版本比如conda create -n py311 python3.11一句话就能创建一个带着 Python 3.11 的干净环境底层会去 conda 源拉取对应的 Python 和 pip不依赖系统里任何 Python。这一点是venv做不到的——venv只能基于现有的某个 Python 版本创建环境。2.2 venv 和 virtualenv 在什么场景下更合适如果你的系统里已经装好了需要的 Python 版本项目比较简单不需要 conda 这种重量级管理工具python -m venv 环境名完全可以。venv 是 Python 官方自带的不需要额外安装创建速度快体积小。但 venv 有个限制它只能基于当前命令行的 Python 版本创建环境。你在 Python 3.10 下运行python -m venv myenv这个环境只能跑 3.10。想用 3.11 就必须先装好 3.11再用 3.11 的 python 去创建。conda 就不存在这个问题它直接从源拉取任意 Python 版本。virtualenv 是第三方工具出现得比 venv 早功能上有一些差异比如创建环境的速度、pip 版本兼容性方面的细节。对绝大多数人来说venv 够用了没必要专门装 virtualenv。不过有些老项目或教程里还在用pip install virtualenv思路是相通的不影响内核配置方法。2.3 环境变量与命令行接口检查正式操作前建议先检查命令行环境确保基础是干净的。执行python --version和which pythonWindows 用where python确认当前命令行使用的解释器是预期的那一个。如果装了 Anaconda 但没有执行conda init可能出现在终端里输入conda提示找不到命令的情况。这种情况下建议先执行conda init按提示重启终端后再继续。Windows 上如果装 Anaconda 时勾选了自动加入 PATH也要留意系统里是不是存在多个 Python 的冲突。个人经验在一台机器上只保留一套“基础环境管理器”是最舒服的。要么以 conda 为主要么以系统 Python venv 为主不要两套同时抢 PATH否则内核配置出问题时排查路径真的能让你先抽一包烟。3. 核心操作把环境注册成 Jupyter 内核的完整流程这一节是全文重点给的是最标准、最不容易出错的操作步骤。先说明一下我下面以 conda 环境为主展开但 venv 环境的操作只有创建和激活环节不一样注册内核的命令完全一致。3.1 第一步创建并激活目标环境打开终端执行conda create -n py311 python3.11 -y中间的py311是我给环境起的名字python3.11指定版本。创建完成后激活conda activate py311Windows 上如果用的是 cmd激活命令也是conda activate py311但如果 conda 初始化的是 PowerShell需要在 PowerShell 中执行conda init powershell后重启才生效。用 venv 的话第一步变成python -m venv /path/to/myenv激活方式Windows 下是/path/to/myenv/Scripts/activateLinux/macOS 下是source /path/to/myenv/bin/activate。激活不是可选项。你要在“目标环境”里装包、注册内核前提就是终端当前处于目标环境。激活成功后命令行提示符一般会出现环境名比如(py311) C:\Users\...或者(py311) userhost:~$。养成看提示符的习惯可以少踩一半的坑。3.2 第二步在目标环境里安装 ipykernel激活环境后执行pip install ipykernel这一步的原理是Jupyter 内核本质上就是一个 Python 交互式进程而ipykernel是这个进程和 Notebook 前端通信的协议实现。环境里必须装了ipykernel后面注册内核才有可执行的东西。很多人把pip install ipykernel这条命令放在了 base 环境里跑结果后续注册的内核实际从 base 环境启动目标环境的包统统用不了。判断包是否装对了位置最直接的方法是运行pip show ipykernel看它显示的文件路径是不是位于你的目标环境目录下。如果在 base 环境里说明上一步激活没生效或者终端刚打开时自动回到了 base。除了ipykernel还有些配套依赖比如ipywidgets、jupyter_client是依赖自动拉取的一般不用手动装。如果运行 Jupyter 时提示缺某个模块可以再补装。3.3 第三步注册内核并验证装好ipykernel后执行python -m ipykernel install --user --name py311 --display-name Python 3.11 (py311)拆解一下每个参数的含义--user把内核注册到当前用户目录而不是系统目录。加这个参数不需要管理员权限也不太容易污染系统配置。不加这个参数而在某些系统上会把内核写到/usr/local/share/jupyter/kernels/可能需要 sudo。--name内核的内部名称相当于 ID。这个名字不能有空格一般用环境名保持一致比如py311。--display-name你在 Notebook 内核下拉菜单里看到的名字可以随便起比如Python 3.11 (py311)或者数据分析环境。执行成功后终端会显示Installed kernelspec py311 in ...之类的提示。此时运行jupyter kernelspec list应该能看到py311这一项。然后启动 Jupyterjupyter notebook或者新版用jupyter lab打开页面后点击右上角“新建”下拉菜单里就能看到刚才的Python 3.11 (py311)。选它之后在单元格里执行import sys print(sys.executable)输出的路径如果指向py311环境里的 python说明内核注册成功了。这个验证动作不要跳过我见过不少号称配好了、结果sys.executable显示的还是 base 环境的情况。3.4 内核注册文件的本质一个 JSON 文件就够了python -m ipykernel install背后的逻辑其实很朴素它会在某个内核目录下生成一个kernel.json文件。这个文件记录了内核启动时需要执行的命令、显示名称、语言类型等信息。我的内核目录下py311对应的kernel.json大致长这样{ argv: [ /opt/miniconda3/envs/py311/bin/python, -m, ipykernel_launcher, -f, {connection_file} ], display_name: Python 3.11 (py311), language: python }argv的第一项就是解释器路径这是整个文件最关键的部分。内核启动时Jupyter 会执行这一串命令把{connection_file}替换成实际的连接文件路径然后这个 Python 进程就作为内核进程运行起来了。你看display_name只是一个给人看的标签真正决定代码在哪个环境里跑的是argv里的解释器路径。理解这一点后你会明白几个重要结论注册内核只是生成一个“快捷方式”不会复制环境里的包也不会把环境“搬”到 Jupyter 里。只要解释器路径不变你改了显示名运行环境不会变。手动编辑kernel.json也可以实现注册适合需要精细控制的场景比如指定 Python 路径、附加参数我会在第六节讲。4. 内核切换的日常操作新建、切换、删除、重命名全覆盖环境都注册好了接下来是实际使用中的操作问题。4.1 新建文件时切换内核在 Jupyter Notebook 经典界面里点击左上角的“File → New Notebook”或者页面右上角的“New”按钮会弹出一个下拉菜单里面列出所有已注册的内核。选哪个新建的 Notebook 就会用哪个内核执行代码。在 JupyterLab 中操作稍微有点不一样。点击左上角“文件 → 新建启动器”或者快捷键Ctrl Shift L会打开 Launcher 页面里面有一个 Notebook 区域列着所有内核点击对应卡片就新建了使用该内核的 Notebook。如果你之前设置了默认内核Launcher 可能默认选中某一个但选择权还是在你手上。有一个小细节New下拉菜单只出现在经典 Notebook 页面JupyterLab 启动页面通常是 Launcher。如果按教程说的“点 New”找不到多半是界面版本不同不表示内核注册失败。4.2 打开 Notebook 之后怎么切换内核这个问题经常有人问。已经打开了一个 Notebook 文件发现内核选错了不需要关闭重开。在经典 Notebook 界面中点击菜单栏的“Kernel → Change Kernel”会弹出当前文件的内核列表直接选目标内核即可。JupyterLab 的入口也类似在菜单栏“运行内核”或“Kernel”取决于语言下找“更改内核”点击后会弹出内核选择框。切换回内核后Notebook 会软重启内核已执行的变量会被清空。这是一个经常被忽略的点切完内核记得重新运行所有单元格不然你print一个变量会直接NameError。4.3 查看、删除内核日常管理内核的命令主要是这三个# 查看所有已注册内核 jupyter kernelspec list # 删除某个内核 jupyter kernelspec remove py311 # Windows/Unix 有些版本用的是 uninstall作用相同 jupyter kernelspec uninstall py311删除内核只是删掉了那个“快捷方式”kernel.json不会删除对应的 conda 环境和环境里的包。比如删除py311内核后环境还在你仍然可以conda activate py311继续使用只是 Notebook 新建文件时不再显示这个入口了。如果你删除内核是想“解决环境混乱问题”那是无效操作。环境里的包装得对不对跟内核不存在直接关系根源还是环境本身的依赖情况。4.4 给内核改名如果你觉得一个内核的显示名不好看比如一开始写的Python 3.11 (py311)太罗嗦想改成py311 主分析环境可以通过修改kernel.json文件实现。先找到内核目录jupyter kernelspec list输出里会给出路径比如~/.local/share/jupyter/kernels/py311或C:\Users\用户名\AppData\Roaming\jupyter\kernels\py311用编辑器打开其中的kernel.json把display_name字段的值改成想要的名字保存然后回到 Jupyter 页面刷新一下新名字就生效了有时需要重启 Jupyter 进程。这个操作改的是显示名argv里的解释器路径没动所以运行环境不会变。记住改名只是换标签不会换解释器。5. 实际使用中踩过的坑与排查路径配多环境这件事“配置”本身往往是最顺利的一步真正的麻烦在使用过程中。这里整理五个我真实经历过的坑每一条都会给出排查路径。5.1 内核下拉菜单里看不到刚注册的环境明明jupyter kernelspec list显示了py311但页面里新建文件时就是看不到。试试这么排查先确认启动的 Jupyter 进程内核目录和你kernelspec list看到的是否一致。Jupyter 启动时会扫描“内核目录列表”通常包括用户目录和系统目录。如果kernelspec list写在用户目录而 Jupyter 进程以系统服务方式启动可能没权限或没扫描到用户目录。碰到这种情况先重启 Jupyter 进程因为有些版本的内核列表是在启动时缓存的。然后检查浏览器缓存CtrlF5 强制刷新。如果还是看不到执行jupyter --paths确认data路径里是否包含你注册内核的目录。我最常遇到的原因是注册时没有加--user内核被写到了系统目录而 Jupyter 进程的用户对系统目录没有读取权限。解决办法是重新执行注册命令并加上--user。5.2 包明明装好了import 却报 ModuleNotFoundError这个坑的典型场景是你在命令行conda activate py311后pip install了一个包然后在 Notebook 里import时报ModuleNotFoundError。先不要急着重新安装。在 Notebook 单元格里执行import sys print(sys.executable) print(sys.path)如果sys.executable指向的是 base 环境或者系统 Python说明 Notebook 跑在别的内核上跟你py311环境无关这是“切换错误”而不是“安装失败”。解决方法是切换内核或者新建 Notebook 时选对内核。如果sys.executable确实是py311的 python但包还是找不到那要检查包的安装位置。在终端执行pip show 包名看Location字段是否在py311的site-packages里。如果跑到了~/.local/lib/python3.x/site-packages说明是pip以用户级方式安装的隔离性出了问题。解决方法是检查环境变量PYTHONPATH是否设置了用户级目录或者在安装时显式用python -m pip install 包名并且不要混用多个 pip。还有一种隐蔽情况py311环境里有两个 python 可执行文件一个bin/python一个bin/python3.11注册内核时用的解释器和命令行激活后使用的解释器不是同一个。检查一下kernel.json里的argv路径是否和你sys.executable一致。我遇到过有些杂牌环境的argv路径指向了/usr/bin/python这种事排查起来很费劲但验证也很简单直接看 JSON 文件就好。5.3 pip 与 conda 混装导致的依赖冲突很多人习惯在 conda 环境里用pip装包这本身没问题但要注意pip装包时依赖解析和 conda 的依赖解析是两套系统。比如你pip install tensorflow可能会装上一整套和 conda 环境里 numpy 版本冲突的依赖随后 import 时报一堆奇怪的 C 库加载错误。规避方法是能用 conda 安装的包尽量用 conda 装特别是 numpy、scipy、pandas 这类底层库。装 pip 包之前先确保pip本身在环境里存在执行python -m pip install --upgrade pip升级一下然后用python -m pip install 包名的方式安装避免直接使用系统级的pip命令。如果已经发生了依赖混乱最快的解决办法不是一个个降级包而是重建一个干净环境。这就是多环境最大的好处坏了就删重建成本比修复低得多。5.4 虚拟环境里的 Python 版本和预期不符有时候你创建 conda 环境的命令写的是python3.11但环境里实际用的 Python 还是老的 3.9。出现这种情况多半是 conda 源里没有你要的版本或者创建命令被某处的conda配置覆盖了。在终端执行conda activate py311 python --version如果版本不对检查conda --version和conda info输出的 base 环境是否正常。然后强制重新创建conda create -n py311 python3.11 -y如果 conda 找不到 3.11检查conda config --show channels的源配置看源的覆盖范围和官方版本是否一致。另外Windows 上如果 PATH 里有多个 conda也可能出现conda命令实际来自另一个发行版导致创建环境时行为不同。执行where conda看看声明的路径是不是预期那个。5.5 VSCode 与 Jupyter Notebook 混用时的内核路径问题现在很多人在 VSCode 里直接使用 Jupyter Notebook 扩展这个扩展会自动发现已注册的内核。如果 VSCode 里看不到你的 conda 环境大概率是因为扩展的 Python 解释器路径没选对。打开一个.ipynb文件后点击右下角的“选择内核”或“Python 环境”手动选择py311。VSCode 会把 Jupyter 内核和 Python 解释器分开管理Notebook 内核决定代码在哪跑Python 解释器主要影响代码提示、调试和 lint 工具。很多时候你觉着“内核选对了但自动补全还是老版本的”那就是这个解释器没同步选。这类问题排查优先级是先看 Notebook 右上角的 Python 版本显示再看内核列表最后看 VSCode 底部的解释器。顺序错了很容易误判。6. 进阶玩法脚本化注册、自定义内核与无界面集成配置多环境这件事如果只是手动跑几次命令半年后你大概率又忘了流程。我这里准备了几个进阶方案让环境管理更自动化、更贴合真实工作流。6.1 一键注册脚本我的做法是把“建环境 装 ipykernel 注册内核”打包成一个脚本放项目里以后换机器、换环境时直接跑一遍。这里给一个 Bash 脚本示例#!/usr/bin/env bash # create_and_register_env.sh ENV_NAME$1 PY_VERSION$2 DISPLAY_NAME$3 conda create -n $ENV_NAME python$PY_VERSION -y conda activate $ENV_NAME python -m pip install --upgrade pip python -m pip install ipykernel python -m ipykernel install --user --name $ENV_NAME --display-name $DISPLAY_NAME echo Done! Run: jupyter kernelspec list使用方式bash create_and_register_env.sh py311 3.11 Python 3.11 (py311)Windows 下可以用 PowerShell 脚本注意激活环境后子进程隔离导致的坑。Bash 脚本里conda activate之后执行的命令都在当前 shell 内效果是正常的但如果是通过脚本调用conda run -n py311 python -m pip ...会更稳不依赖 activate 的路径解析。6.2 手动编写 kernel.json 控制复杂参数前面提到过kernel.json只是入口想精细控制内核行为时可以手动编写。比如你的环境里 Python 解释器需要传一些附加参数比如--safe-path指定模块搜索路径或者你想让内核在特定工作目录启动都可以在argv里加参数。手动创建内核的完整步骤执行jupyter kernelspec list找一个已有内核的路径比如~/.local/share/jupyter/kernels/py311。在该目录下新建一个子目录如my-custom-kernel。在my-custom-kernel目录下创建kernel.json内容参考{ argv: [ /path/to/env/bin/python, -m, ipykernel_launcher, -f, {connection_file} ], display_name: Custom Kernel, language: python, env: { PROJECT_ROOT: /path/to/project } }这里我加了env字段里面定义的环境变量在内核启动时会注入到进程。display_name和language都很好理解。手动编写的好处是灵活缺点是得自己保证路径正确而且写错 JSON 格式内核会直接启动失败。验证 JSON 最简单的方法是用 Pythonpython -c import json; json.load(open(kernel.json))如果有语法错误这里会立刻报错比在 Jupyter 页面里猜原因高效多了。6.3 Jupyter 与 Neovim / 终端场景下的内核管理现在不少人在 Neovim 里写 Python配合 Jupyter 做交互式执行。这种情况下内核切换靠的不是图形界面而是jupytext或者vim-jupyter这类插件。它们依然依赖你已经注册好的内核所以在 Neovim 中执行“切换内核”时底层调用的是同一个jupyter kernelspec。Neovim 场景下有个额外需求经常被忽略Python 包的安装位置要清楚。因为你可能同时用 Neovim 的 Python provider 和 Jupyter 内核如果 provider 解释器是 base 环境Jupyter 内核是 py311 环境那两边能 import 的包就不一样。排查时先用:checkhealth或python3 -c import sys; print(sys.executable)确认。命令行场景下还有一个技巧可以直接用jupyter console --kernelpy311在终端里使用指定内核这种方式适合快速测试环境里的包是否完好不用开浏览器。我就是这样排查各种“环境里装好了但 import 失败”的问题的比反复在 Notebook 里跑sys.executable快得多。7. 多环境规划与长期维护配置完环境和内核不能算结束。真实项目中多环境的使用频率和规划方式决定了这套配置能让你舒服多久。7.1 按项目维度规划环境而不是按 Python 版本规划很多人习惯“一个 Python 版本一个环境”比如py36、py38、py311。这个思路在做库开发、需要测试多版本兼容性时没问题但在做实际项目时更合理的是“一个项目一个环境”比如recommendation-v1、nlp-service。因为项目依赖之间的冲突往往是版本层面的而不是 Python 版本层面的。A 项目的 pandas 锁死在 1.5B 项目的 pandas 需要 2.0如果环境按 Python 版本划分两个项目共用一个 3.11 环境升级了一个必然影响另一个。我的习惯是base环境尽量保持干净只放最基本的工具。每个活跃项目建一个独立环境名字带项目缩写比如rec-v1。实验性的一两行代码不开新环境直接在当前项目环境里跑。按项目划分还有一个好处注册内核时--name直接用项目名打开 Notebook 时一眼就知道该选哪个不需要去猜“我刚才那个环境装的什么 Python”。7.2 定期清理无用内核和环境时间一长jupyter kernelspec list和conda env list会变得很长一眼看不到头。每完成一个阶段性项目我都习惯清理一下jupyter kernelspec list # 找到不用的内核名比如 old_exp jupyter kernelspec remove old_exp conda env list # 找到不用的环境路径 conda env remove -n old_exp清理的时候注意jupyter kernelspec remove和conda env remove是两个独立操作删了内核不会删环境删了环境也不会删内核。如果你的策略是“环境没了就不要再显示在列表里”两个都要删。7.3 依赖导出与复现多环境配置好之后把依赖固化下来是持续可复用的前提。在环境里执行pip freeze requirements.txt但pip freeze的产物体积大而且会带上依赖路径上的一些杂项包。更语义化的做法是pip list --formatfreeze requirements.txt如果你用的是 conda也可以conda env export environment.yml这个 YAML 文件包含了环境名、依赖通道、所有包及其版本还原时只要conda env create -f environment.yml复现环境配合内核注册脚本可以做到“一台新机器十分钟内恢复所有工作环境”而且保证 Jupyter 里能直接选中对应内核。7.4 一个实际项目的完整配置示例拿我最近一个推荐系统项目举例。需求是 Python 3.11、数据科学全家桶、额外需要lightgbm和tensorflow。我的完整操作顺序是这样的conda create -n rec-v1 python3.11 -y conda activate rec-v1 conda install numpy pandas scipy matplotlib jupyter -y python -m pip install lightgbm tensorflow python -m pip install ipykernel python -m ipykernel install --user --name rec-v1 --display-name RecSys v1 (Py3.11)需要注意我为什么没用pip install jupyter因为 conda 直接安装 jupyter 生态更干脆避免 pip 把依赖搞乱。在环境里装好包后进入 Notebook 选择RecSys v1 (Py3.11)内核执行tensorflow.__version__一路畅通。这套流程我复制到了三台机器上除了个别 conda 源速度差异外没有出过问题。我在实际使用中有一个体会很多人把“切换内核”当成了一个有门槛的技术活但真正理解了内核只是“指向解释器的快捷方式”后整个问题就非常简单。关键就三件事——环境建对、ipykernel 装到环境里、注册时选对解释器路径。剩下的坑基本都能通过sys.executable和jupyter kernelspec list这两条命令排查出来。最后分享一个小技巧注册完内核后别急着打开 Notebook先在终端用jupyter console --kernelpy311快速连一下试试。这种方式比图形界面更容易暴露底层问题比如 kernel.json 路径错误、环境缺包而且测试完成后不用保存任何文件干净利落。这套配置方法我也用了快四年从 conda 到 venv、从本地到服务器核心步骤没变过。希望这篇文章能让你少走弯路一次把多环境这件事做对。