说真的，但凡写过两年以上代码的，谁没在Python版本这事儿上栽过跟头？我反正栽过，而且不止一次。
你想想那个场景，一个祖传项目，README里就写了个python app.py，你一跑，好家伙，满屏的红色报错，仔细一看，哦，人家用的是Python 3.6，而你的系统默认是3.10，那感觉，酸爽。或者，更刺激的，你为了跑A项目装了个新依赖，结果发现B项目直接崩了，因为这个新依赖把某个B项目需要的老版本库给覆盖了。是不是很熟悉？简直是噩梦。
所以，今天不谈什么高深理论，就聊点实在的，聊聊我踩了无数坑之后总结出来的，关于“怎么切换python”这件事的生存哲学。
蛮荒时代的“野路子”：别学！
刚入行那会儿，我也干过不少蠢事。比如，直接改系统环境变量，或者用alias搞个软链接。
alias python=python3.8
当时还觉得自己特聪明，你看，一行命令就解决了！可后来呢？C盘（或者说/usr/bin）里一团糟，各种版本的Python快捷方式、软链接、硬链接，自己都分不清哪个是哪个。系统里某些依赖Python的工具，比如yum，突然就罢工了。那真是追悔莫及。
这种直接动系统默认Python的方式，我称之为“自杀式攻击”。伤敌八百，自损一千。听我一句劝，千万别这么干。你的操作系统之所以带一个Python，是因为它自己也要用，你把它换了，等于把大楼的承重墙给敲了。
进入文明社会：认识真正的版本管理神器 pyenv
折腾够了，终于有人给我指了条明路——pyenv。
这玩意儿，简直就是Python版本管理界的瑞士军刀。它的核心思想特别简单，也特别高明：它不碰你系统自带的Python，一根毛都不碰。它会在你的用户目录下创建一个专门放Python解释器的“收纳箱”（.pyenv目录），你想要什么版本的Python，它就给你下载编译一个放进去。你想用哪个，它就帮你“指”一下。
整个过程，对你的操作系统来说是完全无感的、隔离的。这才是现代开发者该有的优雅。
怎么用 pyenv 来切换Python？
这东西上手一点都不复杂，咱们走一遍流程：
-
安装
pyenv:
在macOS上，用brew就行：brew install pyenv。
在Linux上，官方有个一键安装脚本，或者你也可以跟着GitHub上的步骤手动配置一下环境变量，不难。 -
查看你能装哪些版本:
装好了，先看看它都支持哪些Python版本。
pyenv install --list
一长串列表出来，从古老的2.x到最新的3.x，应有尽有，安全感爆棚。 -
安装你想要的版本:
比如，那个祖传项目需要Python 3.6.8，而你本地想用个3.10.4。
pyenv install 3.6.8
pyenv install 3.10.4
这个过程会需要编译，可能要花几分钟，泡杯咖啡，耐心等着。第一次装可能还会提示缺一些编译依赖，比如openssl、readline之类的，缺啥补啥就行，都是小事。 -
见证奇迹的时刻：切换！
这才是怎么切换python这个问题的核心答案。pyenv提供了两种主要的切换方式：-
全局切换 (
global):
pyenv global 3.10.4
执行完这句，你在任何地方打开终端，敲python --version，看到的都会是Python 3.10.4。这是你的“日常主力”版本。 -
局部切换 (
local):
这招就更精髓了！你cd到那个祖传项目的文件夹里，然后执行：
pyenv local 3.6.8
你会发现，这个文件夹里多了个.python-version文件，里面就写着3.6.8。
神奇的事情发生了：只要你在这个文件夹（以及它的子文件夹）里，你用的Python就自动变成了3.6.8！你一离开这个目录，回到其他地方，Python版本又变回了你全局设置的3.10.4。
看明白了吗？
pyenv实现了项目级别的版本隔离。它让你可以在A项目用3.6，B项目用3.8，C项目用3.10，彼此之间互不干扰，世界一下就清净了。 -
更上一层楼：pyenv 与虚拟环境的完美合奏
只管理Python解释器本身，还不够。我们前面提到的第二个噩梦——依赖库冲突，还没解决呢。
这时候，就需要虚拟环境登场了。主流的选择是venv（Python 3.3+自带）或者virtualenv。
我的工作流通常是这样的：
-
用
pyenv把项目的Python版本“定死”。
cd my-legacy-project
pyenv local 3.6.8 -
在这个“定死”的版本基础上，创建一个纯净的虚拟环境。
python -m venv venv
这里用的python命令，因为pyenv的存在，它已经是3.6.8版本了。所以创建出来的这个venv虚拟环境，就是一个基于Python 3.6.8的、不包含任何多余第三方库的“沙盒”。 -
激活这个沙盒。
source venv/bin/activate(macOS/Linux)
venv\Scripts\activate(Windows)
激活后，你的命令行提示符前面会多一个(venv)的标记，告诉你现在进入了“结界”。 -
在沙盒里为所欲为。
pip install -r requirements.txt
现在，所有的pip install都只会安装到这个venv文件夹里，项目需要什么古老的、奇葩的依赖，都尽管装。它绝对不会污染到你其他的项目，更不会动到系统库。
pyenv管的是“你用哪个版本的锅做饭”，而venv管的是“你这道菜都放了哪些调料”。两者结合，天下无敌。
顺便提一句 conda
有些朋友，特别是搞数据科学的兄弟们可能更熟conda。conda是个巨无霸，它不仅能管理Python版本，还能管理虚拟环境，甚至能管理非Python的软件包（比如CUDA、cuDNN）。
conda好不好？当然好，非常强大。但对于纯粹的Web开发、后端开发或者脚本小子来说，它有时候有点“重”。安装一个Miniconda还行，要是装完整的Anaconda，那体积，那预装的一大堆库，对于追求轻量和纯净的我来说，有点过度了。
所以我的观点是：
* 如果你是数据科学家、算法工程师，项目里深度依赖NumPy, Pandas, SciPy全家桶，而且经常要处理复杂的C/C++依赖，conda可能是你的最佳选择。
* 如果你是Web开发者、后端工程师、运维或者就是写写脚本，项目环境相对纯粹，那么pyenv + venv 这个组合，轻量、专注、优雅，绝对是黄金搭档。它让你对环境的掌控感更强。
最终，怎么切换python这个问题的答案，不是一个简单的命令，而是一种思想：隔离。把不同项目的Python解释器隔离开，把不同项目的依赖库隔离开。当你真正理解并实践了这种思想，Python版本问题，就再也无法成为你前进路上的绊脚石了。它只会变成你工具箱里一把顺手的工具，想用哪个，就用哪个。这自由，谁用谁知道。
评论(0)