我前段时间整理旧开发机的时候发现本机同时躺着 2.7.9、3.9.1 和 3.14.2 三个版本的 Python第一反应是“这也太乱了”但仔细一想这种组合其实一点也不奇怪手上有维护到一半的老项目还跑在 Python 2 上新写的脚本又不想被旧解释器拖后腿加上偶尔想试试最新版语法三个版本就这么共存了下来。写这篇东西就是记录我如何让这三个版本在同一台机器上互不干扰地工作包括安装、路径管理、虚拟环境隔离、pip 分发和编辑器切换这一整套流程。如果你也想在 Windows 或 Linux 上装多个 Python 版本或者已经被“版本错乱”折磨过这篇应该能给你一个比较完整的参考。1. 三个版本并存不是洁癖是被项目需求逼出来的1.1 我为什么现在还留着 Python 2.7.9很多新人看到本机装了 Python 2.7.9 的第一反应通常是“赶紧卸了”。但实际场景里一台机器上有 2.7.9 是有充分理由的一些公司内部的老系统、老教学案例、或者很偏门的第三方库只支持 Python 2。前阵子我接手一个数据同步脚本里面用了urllib2和一个老旧的MySQLdb扩展换到 Python 3 直接一堆导入报错。这种代码不是不能改但要花时间验证批量行为成本很高。与其改代码不如在开发机里留一个 2.7.9 环境专门用来跑这些遗留任务。2.7.9 这个版本号本身也有点特殊。它是 Python 2.7 系列里第一个默认集成 pip 的版本也是之后官方还维持了较长时间维护的版本之一。很多老教程和旧项目的依赖锁定就是按 2.7.9 写的。如果你的电脑需要处理这类旧代码自己安装一个干净的 2.7.9 比去下载那些打包好的免安装版靠谱得多——至少干净没有夹带隐私疑虑。1.2 3.9.1 是稳定中间层3.14.2 是前沿试验田3.9.1 其实是我主力环境里的“稳定中间层”。它发布已经有一段时间大部分第三方库都在这个版本上有现成的 wheel 包。跑数据分析、写爬虫、做 Web 服务我用 3.9.1 很少遇到“这个库不支持该版本 Python”的情况。相比更老的 3.5、3.63.9.1 的语法和标准库已经完全面向新开发方式相比最新版又不会因为版本更新频繁而影响既有项目。3.14.2 则算是这台机器上的“新玩具”角色。Python 3.14 在性能、异常分组、文件操作等特性上都有不少变化新项目我想直接踩在这些新特性上写不想再按旧版本的习惯约束自己。尤其一些纯 Python 写的新脚本、AI/ML 领域的实验代码我会优先用 3.14.2 跑尽早发现兼容性问题而不是等到选型那天才突然发现某个依赖装不上。所以三版本共存本质上是“遗留模块、稳定生产、前沿探索”三种需求同时存在。一台机器要同时满足这三种需求不是靠“只装一个最新版”就能解决的也不是靠反复改环境变量能解决的。1.3 如果不做共存会发生什么不共存的做法通常是“只装一个最新版”然后开始改造所有老代码。结果往往是老项目崩了新项目也没爽到还有人会装一个版本然后不断切换环境变量 PATH改来改去最后连python指向哪个解释器都不知道。长期这么搞最危险的不是代码而是你根本不知道当前正在操作哪一个解释器安装依赖时安装到错误环境然后排查一整天。这就是为什么这篇记录打算从“共存的顶层设计”开始说而不是上来就让你去下载安装包。理解版本与版本之间的“物理隔离”机制比会敲几个安装命令重要得多。2. 先搞懂解释器定位和命令分发不然装三个版本就是装三颗雷2.1 每个解释器都必须有自己独一无二的路径让三个版本共存的第一条原则是“每个解释器的安装路径必须独立而且你要记住它们分别在哪”。通常 Windows 安装 Python 时默认安装目录会按版本号分开比如C:\Python27、C:\Python39、C:\Python314但如果安装时选了“仅当前用户”路径会跑到C:\Users\你的用户名\AppData\Local\Programs\Python\下面同样会按Python27、Python39、Python314分目录。路径独立的含义是python.exe、pip.exe、Lib\site-packages全都各自待在自己的安装目录里。这样互不影响。最怕的是有人手动把两个 Python 装到同一个目录里后装的那个会覆盖掉先装的python.exe然后你得到一个说不清是哪个版本的解释器。更合理的做法其实是自定义安装目录D:\Python\2.7.9 D:\Python\3.9.1 D:\Python\3.14.2这样做的好处路径短、好记忆、后续做 IDE 配置和写脚本时不用猜。虽然官方支持自定义路径但有一点要注意Python 安装程序对自定义路径可能有要求推荐全部用英文小写字母和数字不要带空格或中文。2.2 PATH 顺序是引发“版本错乱”的第一大元凶在 Windows 上执行python --version系统会从PATH环境变量里从左到右找第一个python.exe。如果同时把C:\Python27、C:\Python39、C:\Python314都写进 PATH那谁在前面谁就“赢了”。很多人改 PATH 改得很随意结果就是今天在 A 项目里执行python得到 2.7.9明天不知哪次安装软件又把它挪到 3.9.1 后面然后一脸懵。我的建议是不要把所有版本的 Python 都加进 PATH只保留一个默认版本比如把D:\Python\3.9.1和D:\Python\3.9.1\Scripts放进 PATH 里的靠前位置。2.7.9 和 3.14.2 平时不走python这个命令而是用py -2.7、py -3.14这种带参数的方式调用。这样至少python命令的指向永远是明确的不会随系统设置心情乱变。Linux/macOS 下的问题也类似而且更麻烦因为很多系统工具本身依赖系统自带的 Python你要是乱改/usr/bin/python3的软链接可能会导致桌面环境或包管理器崩溃。后面的章节我会专门说 Linux 下该怎么处理。2.3 Windows 的 py 启动器多个版本的“调度台”Windows 官方 Python 安装包会自动带上py.exe这是一个“版本路由器”。装完 2.7.9、3.9.1、3.14.2 之后可以直接用py -0查看当前已注册的所有 Python 版本。输出大概是-V:3.14.2 Python 3.14 (64-bit) -V:3.9.1 Python 3.9 (64-bit) -V:2.7.9 Python 2.7 (64-bit)调用方式就是py -3.9、py -2.7或者像下面这样直接执行脚本py -3.9 -m pip install requests py -2.7 script.py py -3.14 -m venv myenv这个机制有个好处无论 PATH 怎么乱只要py.exe还在系统路径里所有 Python 版本都是可控、可调的。Windows 下我强烈建议把py当主调度命令来用这比一个个去记完整路径省事太多也特别适合在 CI 脚本里固定版本。3. Windows 上三版本落地的安装顺序与关键勾选项3.1 安装顺序先老后新如果你打算一次性装三个版本我建议的顺序是先装 2.7.9再装 3.9.1最后装 3.14.2。原因不复杂Python 2.7 的安装程序很老安装时不会主动去关联.py文件或写 launcher后安装的 3.x 会自动注册py.exe并识别已有版本。反过来说如果先装了新版本某些旧版安装程序在“添加 PATH”时可能把旧版本路径塞到最前面导致你执行python得到的是 2.7而不是你想用的 3.x这类问题特别让人烦躁。当然安装顺序也不是绝对不可逆。装完之后你用py -0看一下注册列表如果某个版本没出现可以检查安装时是否勾选了“为所有用户安装”以及是否安装了“py launcher”组件。3.2 安装界面里几个关键选项在 Windows 的安装向导里有几个选项经常被人忽略Add python.exe to PATH要不要勾如果按我前面说的“PATH 里只放一个默认版本”那这一步留给 3.9.1 勾选就行。2.7.9 和 3.14.2 可以不勾。不过这取决于你是想以哪个版本为默认版本。提醒一点安装程序写的 PATH 是在当前用户环境变量里不是系统级所以即使勾错了也能事后手动调整。py launcherPython 3.3 之后安装器都有一个“py launcher”组件默认勾选。一定要保留。这是 Windows 多版本管理的基础。For all users为所有用户安装如果你有管理员权限建议勾上。这样安装路径会落到D:\Python\3.9.1这种自定义目录而不是当前用户的 AppData 目录后续在公司域账号或其他用户下也能访问。安装 Python 2.7.9 时还要注意2.7.9 安装包对 Windows 10/11 支持不算完美如果提示“需要 Service Pack”可以右键属性在兼容性里选择 Windows 7 兼容模式运行。3.3 安装完成后的验证命令装完后先用这几个命令确认状态py -0 py -2.7 --version py -3.9 --version py -3.14 --version如果输出正常再验证各自对应的 pippy -2.7 -m pip --version py -3.9 -m pip --version py -3.14 -m pip --version这里特别说明一个新手困惑执行pip --version会显示 pip 所属的 Python 路径而不是仅仅显示 pip 版本号。如果你看到pip 20.2.1 from D:\Python\3.9.1\lib\site-packages\pip (python 3.9)那说明当前这个 pip 是 3.9.1 专属的。很多人装依赖装错环境就是没注意这行输出。3.4 Linux/macOS 该怎么对应如果是 Linux我建议先用系统包管理器装好 python3再用手动源码编译的方式补另外两个版本。比如# 安装编译工具链 sudo apt update sudo apt install -y build-essential libssl-dev libffi-dev zlib1g-dev # 下载对应版本源码 wget https://www.python.org/ftp/python/3.14.2/Python-3.14.2.tgz tar xzf Python-3.14.2.tgz cd Python-3.14.2 ./configure --enable-optimizations --prefix/opt/python/3.14.2 make -j$(nproc) sudo make install直接把每个版本安装到/opt/python/版本号这种独立目录下然后靠软链接来指定python3.9、python3.14等可执行文件。sudo update-alternatives也可以但我不太推荐拿它去动系统的python3默认指向尤其 Ubuntu 上不少系统组件都依赖/usr/bin/python3乱改容易把桌面搞挂。macOS 上可以用 Homebrew 安装大多数版本brew install python3.9 python3.14但 2.7 版本在 Homebrew 里已经下架需要手动加仓库或源码编译。macOS 环境用pyenv更顺手一些这个工具可以按目录自动切换 Python 版本后面会简单提到。4. 虚拟环境才是真正的隔离层2.7.9 必须单独搭环境4.1 为什么有了“多版本共存”还不够“多版本共存”解决的是“机器上有多个解释器”的问题但同一个解释器下安装的包仍然是全局共享的。比如你用 3.9.1 的 pip 装一个flask2.0再用 3.9.1 的 pip 去给另一个项目装flask3.0后装的那个会把前一个顶掉。所以真正的隔离是“项目级隔离”。项目级隔离的标准做法就是虚拟环境。每个虚拟环境里有一个独立的site-packages你在这个环境里装了什么不会影响其他环境。虚拟环境的本质也不复杂它是一套经过改造的 Python 解释器入口加上一组环境变量让代码从这个环境自己的目录里找包。4.2 Python 3.9.1 和 3.14.2 用标准库 venvPython 3.9 和 3.14 都自带venv模块用法几乎一样# 在项目目录下创建一个 Python 3.9.1 的虚拟环境 py -3.9 -m venv venv39 # 在另一个项目下创建 Python 3.14.2 的虚拟环境 py -3.14 -m venv venv314然后激活# Windows cmd venv39\Scripts\activate.bat # Windows PowerShell venv39\Scripts\Activate.ps1 # Linux/macOS source venv39/bin/activate激活之后命令行的python和pip都会指向虚拟环境里的 Python。这样做的好处就是进入不同的项目目录激活不同的虚拟环境各自依赖互不干扰。这里有一个容易被坑的点如果你在 Windows PowerShell 里执行venv39\Scripts\activate遇到“禁止运行脚本”错误要先执行Set-ExecutionPolicy -Scope CurrentUser RemoteSigned。不是环境坏了是 PowerShell 默认执行策略问题。4.3 Python 2.7.9 要用的是 virtualenv不是 venvPython 2.7 本身没有venv它用的是第三方库virtualenv。好在 2.7.9 已经内置 pip可以直接装py -2.7 -m pip install virtualenv py -2.7 -m virtualenv venv27激活方式和 3.x 类似# Windows venv27\Scripts\activate # Linux/macOS source venv27/bin/activate不过 Python 2 的virtualenv在较新的平台上有个问题它自带的setuptools、pip版本很老安装某些包时可能出现UnicodeDecodeError或编译问题。我的经验是如果只是为了跑旧脚本2.7.9 环境里尽量少装依赖能用标准库就用标准库。真要装建议优先选择还有 wheel 二进制包的旧版本库避免现场编译。另外要说清楚Python 2.7.9 能装的“现代包”越来越少很多库在后续版本发布的要求是 Python 3.6。所以给 2.7.9 装包时可能必须指定旧版本比如pip install requests2.26、pip install urllib31.27。否则会撞上一堆“该库不支持 Python 2”的报错。4.4 怎么快速验证当前环境是哪一个激活虚拟环境后执行python -c import sys; print(sys.executable); print(sys.version)看到的是这个环境绝对路径和具体版本。如果sys.executable指向venv27\Scripts\python.exe那当前就是 2.7.9 隔离环境如果指向D:\Python\3.14.2\python.exe那就是 3.14.2 全局解释器。这个验证习惯很重要。每次安装依赖前花三秒钟确认一下当前解释器路径能避开绝大多数“装错环境”的问题。5. pip 安装装错版本是最常见的翻车现场提前用这招根治5.1 默认 pip 到底指向哪里Windows 安装 Python 3.9/3.14 时默认会往Scripts目录放pip.exe、pip3.exe而 Python 2.7.9 的Scripts下可能只有pip.exe和pip2.exe。如果你 PATH 混乱执行pip install xxx到底装到哪个版本完全取决于 PATH 里先找到哪个 pip。这种情况我见过太多次有人明明执行了pip install requests但import requests还是报错一查他把包装到了 2.7.9 的 site-packages而脚本用的是 3.9.1 解释器。不是安装命令有问题是“pip”这个命令本身有歧义。5.2 推荐统一采用 python -m pip 形式最稳妥的写法是“显式调用某个版本的 Python然后用-m pip运行 pip 模块”。这样绕开了 PATH 里 pip.exe 的指向问题# 给 2.7.9 装包 py -2.7 -m pip install requests2.25.1 # 给 3.9.1 装包 py -3.9 -m pip install numpy pandas # 给 3.14.2 装包 py -3.14 -m pip install fastapi注意Python 3.9.1 自带的 pip 版本可能比较旧如果遇到 pip 本身版本过低报错先升级py -3.9 -m pip install --upgrade pip同理如果你在虚拟环境里直接用python -m pip install ...即可因为python已经被替换成虚拟环境里的解释器。5.3 主动检查“当前环境和包列表”如果已经出现“明明装了import 还是失败”的疑问排查三步走先确认当前解释器python -c import sys; print(sys.executable)再确认包安装到了哪里python -m pip show requests看 Site-packages 路径是不是和当前解释器前缀一致。如果pip show显示的位置在D:\Python\2.7.9\Lib\site-packages而解释器是 3.9.1那答案就出来了装错环境了。解决办法不是去“移动包”而是重新用正确的解释器执行python -m pip install。5.4 多版本项目的依赖清单建议如果你维护多版本项目建议每个项目目录里的 requirements 文件按版本命名或者干脆放到各自的虚拟环境里。比如requirements_py2.txt # 给 2.7.9 用 requirements_py39.txt # 给 3.9.1 用 requirements_py314.txt # 给 3.14.2 用或者更简单所有安装命令都进虚拟环境每个项目通过说明文档或脚本标记使用哪个 Python 版本。这类“文件即配置”的做法比靠人脑记“这个项目应该用哪个版本”靠谱得多。6. 编辑器里切换解释器的几个顺手操作6.1 VS Code一次把三个解释器都装进选择列表在 VS Code 里安装 Python 扩展后按CtrlShiftP输入“Python: Select Interpreter”它会自动扫描系统里的已注册 Python 和虚拟环境。如果你的 2.7.9、3.9.1、3.14.2 路径比较规范比如都在D:\Python下通常都会直接出现在列表里。如果你希望某个项目固定用某个解释器不要依赖“全局默认”而是在该项目根目录创建.vscode/settings.json{ python.defaultInterpreterPath: D:\\Python\\3.9.1\\python.exe }这样无论全局默认怎么变这个项目始终用 3.9.1。同理另外两个项目分别指定不同路径即可。若 VS Code 没扫描到某个 Python最可能的原因是安装时没勾“py launcher”或“为所有用户安装”。这时可以尝试在终端里先手动执行一次对应版本的 Python比如py -3.14让系统注册信息更新后再刷新 VS Code。6.2 PyCharm 的项目级解释器设置PyCharm 里每个项目都可以单独指定解释器操作路径是 File Settings Project Python Interpreter Add Interpreter。选“Existing environment”然后把对应版本的 python.exe 或虚拟环境入口填进去。这个工作是一次性的。项目创建好之后右下角解释器状态会显示当前 Python 版本如果看到版本不对就说明解释器没选对。6.3 团队协作时解释器配置怎么避免“我本地行你那边不行”VS Code 本身不内置 Python 解释器它只是一个编辑器真正干活的是你 多版本Python共存指南：安装、虚拟环境与pip隔离全解析
我前段时间整理旧开发机的时候发现本机同时躺着 2.7.9、3.9.1 和 3.14.2 三个版本的 Python第一反应是“这也太乱了”但仔细一想这种组合其实一点也不奇怪手上有维护到一半的老项目还跑在 Python 2 上新写的脚本又不想被旧解释器拖后腿加上偶尔想试试最新版语法三个版本就这么共存了下来。写这篇东西就是记录我如何让这三个版本在同一台机器上互不干扰地工作包括安装、路径管理、虚拟环境隔离、pip 分发和编辑器切换这一整套流程。如果你也想在 Windows 或 Linux 上装多个 Python 版本或者已经被“版本错乱”折磨过这篇应该能给你一个比较完整的参考。1. 三个版本并存不是洁癖是被项目需求逼出来的1.1 我为什么现在还留着 Python 2.7.9很多新人看到本机装了 Python 2.7.9 的第一反应通常是“赶紧卸了”。但实际场景里一台机器上有 2.7.9 是有充分理由的一些公司内部的老系统、老教学案例、或者很偏门的第三方库只支持 Python 2。前阵子我接手一个数据同步脚本里面用了urllib2和一个老旧的MySQLdb扩展换到 Python 3 直接一堆导入报错。这种代码不是不能改但要花时间验证批量行为成本很高。与其改代码不如在开发机里留一个 2.7.9 环境专门用来跑这些遗留任务。2.7.9 这个版本号本身也有点特殊。它是 Python 2.7 系列里第一个默认集成 pip 的版本也是之后官方还维持了较长时间维护的版本之一。很多老教程和旧项目的依赖锁定就是按 2.7.9 写的。如果你的电脑需要处理这类旧代码自己安装一个干净的 2.7.9 比去下载那些打包好的免安装版靠谱得多——至少干净没有夹带隐私疑虑。1.2 3.9.1 是稳定中间层3.14.2 是前沿试验田3.9.1 其实是我主力环境里的“稳定中间层”。它发布已经有一段时间大部分第三方库都在这个版本上有现成的 wheel 包。跑数据分析、写爬虫、做 Web 服务我用 3.9.1 很少遇到“这个库不支持该版本 Python”的情况。相比更老的 3.5、3.63.9.1 的语法和标准库已经完全面向新开发方式相比最新版又不会因为版本更新频繁而影响既有项目。3.14.2 则算是这台机器上的“新玩具”角色。Python 3.14 在性能、异常分组、文件操作等特性上都有不少变化新项目我想直接踩在这些新特性上写不想再按旧版本的习惯约束自己。尤其一些纯 Python 写的新脚本、AI/ML 领域的实验代码我会优先用 3.14.2 跑尽早发现兼容性问题而不是等到选型那天才突然发现某个依赖装不上。所以三版本共存本质上是“遗留模块、稳定生产、前沿探索”三种需求同时存在。一台机器要同时满足这三种需求不是靠“只装一个最新版”就能解决的也不是靠反复改环境变量能解决的。1.3 如果不做共存会发生什么不共存的做法通常是“只装一个最新版”然后开始改造所有老代码。结果往往是老项目崩了新项目也没爽到还有人会装一个版本然后不断切换环境变量 PATH改来改去最后连python指向哪个解释器都不知道。长期这么搞最危险的不是代码而是你根本不知道当前正在操作哪一个解释器安装依赖时安装到错误环境然后排查一整天。这就是为什么这篇记录打算从“共存的顶层设计”开始说而不是上来就让你去下载安装包。理解版本与版本之间的“物理隔离”机制比会敲几个安装命令重要得多。2. 先搞懂解释器定位和命令分发不然装三个版本就是装三颗雷2.1 每个解释器都必须有自己独一无二的路径让三个版本共存的第一条原则是“每个解释器的安装路径必须独立而且你要记住它们分别在哪”。通常 Windows 安装 Python 时默认安装目录会按版本号分开比如C:\Python27、C:\Python39、C:\Python314但如果安装时选了“仅当前用户”路径会跑到C:\Users\你的用户名\AppData\Local\Programs\Python\下面同样会按Python27、Python39、Python314分目录。路径独立的含义是python.exe、pip.exe、Lib\site-packages全都各自待在自己的安装目录里。这样互不影响。最怕的是有人手动把两个 Python 装到同一个目录里后装的那个会覆盖掉先装的python.exe然后你得到一个说不清是哪个版本的解释器。更合理的做法其实是自定义安装目录D:\Python\2.7.9 D:\Python\3.9.1 D:\Python\3.14.2这样做的好处路径短、好记忆、后续做 IDE 配置和写脚本时不用猜。虽然官方支持自定义路径但有一点要注意Python 安装程序对自定义路径可能有要求推荐全部用英文小写字母和数字不要带空格或中文。2.2 PATH 顺序是引发“版本错乱”的第一大元凶在 Windows 上执行python --version系统会从PATH环境变量里从左到右找第一个python.exe。如果同时把C:\Python27、C:\Python39、C:\Python314都写进 PATH那谁在前面谁就“赢了”。很多人改 PATH 改得很随意结果就是今天在 A 项目里执行python得到 2.7.9明天不知哪次安装软件又把它挪到 3.9.1 后面然后一脸懵。我的建议是不要把所有版本的 Python 都加进 PATH只保留一个默认版本比如把D:\Python\3.9.1和D:\Python\3.9.1\Scripts放进 PATH 里的靠前位置。2.7.9 和 3.14.2 平时不走python这个命令而是用py -2.7、py -3.14这种带参数的方式调用。这样至少python命令的指向永远是明确的不会随系统设置心情乱变。Linux/macOS 下的问题也类似而且更麻烦因为很多系统工具本身依赖系统自带的 Python你要是乱改/usr/bin/python3的软链接可能会导致桌面环境或包管理器崩溃。后面的章节我会专门说 Linux 下该怎么处理。2.3 Windows 的 py 启动器多个版本的“调度台”Windows 官方 Python 安装包会自动带上py.exe这是一个“版本路由器”。装完 2.7.9、3.9.1、3.14.2 之后可以直接用py -0查看当前已注册的所有 Python 版本。输出大概是-V:3.14.2 Python 3.14 (64-bit) -V:3.9.1 Python 3.9 (64-bit) -V:2.7.9 Python 2.7 (64-bit)调用方式就是py -3.9、py -2.7或者像下面这样直接执行脚本py -3.9 -m pip install requests py -2.7 script.py py -3.14 -m venv myenv这个机制有个好处无论 PATH 怎么乱只要py.exe还在系统路径里所有 Python 版本都是可控、可调的。Windows 下我强烈建议把py当主调度命令来用这比一个个去记完整路径省事太多也特别适合在 CI 脚本里固定版本。3. Windows 上三版本落地的安装顺序与关键勾选项3.1 安装顺序先老后新如果你打算一次性装三个版本我建议的顺序是先装 2.7.9再装 3.9.1最后装 3.14.2。原因不复杂Python 2.7 的安装程序很老安装时不会主动去关联.py文件或写 launcher后安装的 3.x 会自动注册py.exe并识别已有版本。反过来说如果先装了新版本某些旧版安装程序在“添加 PATH”时可能把旧版本路径塞到最前面导致你执行python得到的是 2.7而不是你想用的 3.x这类问题特别让人烦躁。当然安装顺序也不是绝对不可逆。装完之后你用py -0看一下注册列表如果某个版本没出现可以检查安装时是否勾选了“为所有用户安装”以及是否安装了“py launcher”组件。3.2 安装界面里几个关键选项在 Windows 的安装向导里有几个选项经常被人忽略Add python.exe to PATH要不要勾如果按我前面说的“PATH 里只放一个默认版本”那这一步留给 3.9.1 勾选就行。2.7.9 和 3.14.2 可以不勾。不过这取决于你是想以哪个版本为默认版本。提醒一点安装程序写的 PATH 是在当前用户环境变量里不是系统级所以即使勾错了也能事后手动调整。py launcherPython 3.3 之后安装器都有一个“py launcher”组件默认勾选。一定要保留。这是 Windows 多版本管理的基础。For all users为所有用户安装如果你有管理员权限建议勾上。这样安装路径会落到D:\Python\3.9.1这种自定义目录而不是当前用户的 AppData 目录后续在公司域账号或其他用户下也能访问。安装 Python 2.7.9 时还要注意2.7.9 安装包对 Windows 10/11 支持不算完美如果提示“需要 Service Pack”可以右键属性在兼容性里选择 Windows 7 兼容模式运行。3.3 安装完成后的验证命令装完后先用这几个命令确认状态py -0 py -2.7 --version py -3.9 --version py -3.14 --version如果输出正常再验证各自对应的 pippy -2.7 -m pip --version py -3.9 -m pip --version py -3.14 -m pip --version这里特别说明一个新手困惑执行pip --version会显示 pip 所属的 Python 路径而不是仅仅显示 pip 版本号。如果你看到pip 20.2.1 from D:\Python\3.9.1\lib\site-packages\pip (python 3.9)那说明当前这个 pip 是 3.9.1 专属的。很多人装依赖装错环境就是没注意这行输出。3.4 Linux/macOS 该怎么对应如果是 Linux我建议先用系统包管理器装好 python3再用手动源码编译的方式补另外两个版本。比如# 安装编译工具链 sudo apt update sudo apt install -y build-essential libssl-dev libffi-dev zlib1g-dev # 下载对应版本源码 wget https://www.python.org/ftp/python/3.14.2/Python-3.14.2.tgz tar xzf Python-3.14.2.tgz cd Python-3.14.2 ./configure --enable-optimizations --prefix/opt/python/3.14.2 make -j$(nproc) sudo make install直接把每个版本安装到/opt/python/版本号这种独立目录下然后靠软链接来指定python3.9、python3.14等可执行文件。sudo update-alternatives也可以但我不太推荐拿它去动系统的python3默认指向尤其 Ubuntu 上不少系统组件都依赖/usr/bin/python3乱改容易把桌面搞挂。macOS 上可以用 Homebrew 安装大多数版本brew install python3.9 python3.14但 2.7 版本在 Homebrew 里已经下架需要手动加仓库或源码编译。macOS 环境用pyenv更顺手一些这个工具可以按目录自动切换 Python 版本后面会简单提到。4. 虚拟环境才是真正的隔离层2.7.9 必须单独搭环境4.1 为什么有了“多版本共存”还不够“多版本共存”解决的是“机器上有多个解释器”的问题但同一个解释器下安装的包仍然是全局共享的。比如你用 3.9.1 的 pip 装一个flask2.0再用 3.9.1 的 pip 去给另一个项目装flask3.0后装的那个会把前一个顶掉。所以真正的隔离是“项目级隔离”。项目级隔离的标准做法就是虚拟环境。每个虚拟环境里有一个独立的site-packages你在这个环境里装了什么不会影响其他环境。虚拟环境的本质也不复杂它是一套经过改造的 Python 解释器入口加上一组环境变量让代码从这个环境自己的目录里找包。4.2 Python 3.9.1 和 3.14.2 用标准库 venvPython 3.9 和 3.14 都自带venv模块用法几乎一样# 在项目目录下创建一个 Python 3.9.1 的虚拟环境 py -3.9 -m venv venv39 # 在另一个项目下创建 Python 3.14.2 的虚拟环境 py -3.14 -m venv venv314然后激活# Windows cmd venv39\Scripts\activate.bat # Windows PowerShell venv39\Scripts\Activate.ps1 # Linux/macOS source venv39/bin/activate激活之后命令行的python和pip都会指向虚拟环境里的 Python。这样做的好处就是进入不同的项目目录激活不同的虚拟环境各自依赖互不干扰。这里有一个容易被坑的点如果你在 Windows PowerShell 里执行venv39\Scripts\activate遇到“禁止运行脚本”错误要先执行Set-ExecutionPolicy -Scope CurrentUser RemoteSigned。不是环境坏了是 PowerShell 默认执行策略问题。4.3 Python 2.7.9 要用的是 virtualenv不是 venvPython 2.7 本身没有venv它用的是第三方库virtualenv。好在 2.7.9 已经内置 pip可以直接装py -2.7 -m pip install virtualenv py -2.7 -m virtualenv venv27激活方式和 3.x 类似# Windows venv27\Scripts\activate # Linux/macOS source venv27/bin/activate不过 Python 2 的virtualenv在较新的平台上有个问题它自带的setuptools、pip版本很老安装某些包时可能出现UnicodeDecodeError或编译问题。我的经验是如果只是为了跑旧脚本2.7.9 环境里尽量少装依赖能用标准库就用标准库。真要装建议优先选择还有 wheel 二进制包的旧版本库避免现场编译。另外要说清楚Python 2.7.9 能装的“现代包”越来越少很多库在后续版本发布的要求是 Python 3.6。所以给 2.7.9 装包时可能必须指定旧版本比如pip install requests2.26、pip install urllib31.27。否则会撞上一堆“该库不支持 Python 2”的报错。4.4 怎么快速验证当前环境是哪一个激活虚拟环境后执行python -c import sys; print(sys.executable); print(sys.version)看到的是这个环境绝对路径和具体版本。如果sys.executable指向venv27\Scripts\python.exe那当前就是 2.7.9 隔离环境如果指向D:\Python\3.14.2\python.exe那就是 3.14.2 全局解释器。这个验证习惯很重要。每次安装依赖前花三秒钟确认一下当前解释器路径能避开绝大多数“装错环境”的问题。5. pip 安装装错版本是最常见的翻车现场提前用这招根治5.1 默认 pip 到底指向哪里Windows 安装 Python 3.9/3.14 时默认会往Scripts目录放pip.exe、pip3.exe而 Python 2.7.9 的Scripts下可能只有pip.exe和pip2.exe。如果你 PATH 混乱执行pip install xxx到底装到哪个版本完全取决于 PATH 里先找到哪个 pip。这种情况我见过太多次有人明明执行了pip install requests但import requests还是报错一查他把包装到了 2.7.9 的 site-packages而脚本用的是 3.9.1 解释器。不是安装命令有问题是“pip”这个命令本身有歧义。5.2 推荐统一采用 python -m pip 形式最稳妥的写法是“显式调用某个版本的 Python然后用-m pip运行 pip 模块”。这样绕开了 PATH 里 pip.exe 的指向问题# 给 2.7.9 装包 py -2.7 -m pip install requests2.25.1 # 给 3.9.1 装包 py -3.9 -m pip install numpy pandas # 给 3.14.2 装包 py -3.14 -m pip install fastapi注意Python 3.9.1 自带的 pip 版本可能比较旧如果遇到 pip 本身版本过低报错先升级py -3.9 -m pip install --upgrade pip同理如果你在虚拟环境里直接用python -m pip install ...即可因为python已经被替换成虚拟环境里的解释器。5.3 主动检查“当前环境和包列表”如果已经出现“明明装了import 还是失败”的疑问排查三步走先确认当前解释器python -c import sys; print(sys.executable)再确认包安装到了哪里python -m pip show requests看 Site-packages 路径是不是和当前解释器前缀一致。如果pip show显示的位置在D:\Python\2.7.9\Lib\site-packages而解释器是 3.9.1那答案就出来了装错环境了。解决办法不是去“移动包”而是重新用正确的解释器执行python -m pip install。5.4 多版本项目的依赖清单建议如果你维护多版本项目建议每个项目目录里的 requirements 文件按版本命名或者干脆放到各自的虚拟环境里。比如requirements_py2.txt # 给 2.7.9 用 requirements_py39.txt # 给 3.9.1 用 requirements_py314.txt # 给 3.14.2 用或者更简单所有安装命令都进虚拟环境每个项目通过说明文档或脚本标记使用哪个 Python 版本。这类“文件即配置”的做法比靠人脑记“这个项目应该用哪个版本”靠谱得多。6. 编辑器里切换解释器的几个顺手操作6.1 VS Code一次把三个解释器都装进选择列表在 VS Code 里安装 Python 扩展后按CtrlShiftP输入“Python: Select Interpreter”它会自动扫描系统里的已注册 Python 和虚拟环境。如果你的 2.7.9、3.9.1、3.14.2 路径比较规范比如都在D:\Python下通常都会直接出现在列表里。如果你希望某个项目固定用某个解释器不要依赖“全局默认”而是在该项目根目录创建.vscode/settings.json{ python.defaultInterpreterPath: D:\\Python\\3.9.1\\python.exe }这样无论全局默认怎么变这个项目始终用 3.9.1。同理另外两个项目分别指定不同路径即可。若 VS Code 没扫描到某个 Python最可能的原因是安装时没勾“py launcher”或“为所有用户安装”。这时可以尝试在终端里先手动执行一次对应版本的 Python比如py -3.14让系统注册信息更新后再刷新 VS Code。6.2 PyCharm 的项目级解释器设置PyCharm 里每个项目都可以单独指定解释器操作路径是 File Settings Project Python Interpreter Add Interpreter。选“Existing environment”然后把对应版本的 python.exe 或虚拟环境入口填进去。这个工作是一次性的。项目创建好之后右下角解释器状态会显示当前 Python 版本如果看到版本不对就说明解释器没选对。6.3 团队协作时解释器配置怎么避免“我本地行你那边不行”VS Code 本身不内置 Python 解释器它只是一个编辑器真正干活的是你