在Linux上折腾Python的人迟早会在一个深夜被依赖冲突逼疯新项目要Python 3.11老服务还锁在3.8系统自带的包管理工具又认死理你一升级cron里跑了几年的脚本第二天全挂。我就是在一次手贱升级requests之后才真正把虚拟环境这几个字刻进脑子的。搭建虚拟环境这件事看着简单其实背后牵扯到系统路径、环境变量、pip归属、镜像源、离线迁移一整套逻辑没理清之前照抄命令后面坑很多。这篇文章我就把从零到一、从创建到迁移、从选型到排雷的完整过程写出来给正在折腾Linux下Python环境的朋友一个能直接照做的参考。本文适合刚接触Linux的开发者、被依赖问题困扰的运维同学以及任何想在服务器或本机上把Python项目环境搞得清爽一点的人。我会按真实使用场景走一遍包括venv、conda两条主流路线的实操以及那些很容易被忽略的坑。1. 被依赖冲突逼到墙角的那个下午虚拟环境到底解决了什么1.1 全局安装模式下的合租公寓困境不装虚拟环境的时候你在Linux上执行pip install xxx默认会把包扔进系统的site-packages目录。这个目录是全系统所有Python程序共享的就好比一个大合租公寓谁都能进来住谁也都可能把公共区域弄乱。最典型的场景项目A需要requests2.28项目B需要requests2.31你指望两个项目在同一个全局环境里和平共处没门。后装的那个版本会覆盖前者项目A第二天可能就出现诡异报错。更麻烦的是Linux自带的好多系统工具本身就依赖特定版本的Python库。比如某些发行版里yum、apt这类包管理器或者gnome-terminal这类桌面组件都和系统Python绑得很紧。你要是为了一个项目把系统里的某个库升了级轻则系统工具告警重则包管理器直接罢工。我一个朋友就在生产服务器上干过这事pip install --upgrade把系统Python的依赖搞坏了结果SSH登录后连apt都用不了差点没被运维同事骂死。1.2 虚拟环境的本质不是隔离而是重新定位很多人把虚拟环境想得很玄以为它像容器或虚拟机一样做了什么隔离魔法。其实没那么高级它干的事核心就三件建一套独立的目录结构、放一个Python解释器或者软链接指向已有解释器、把PATH环境变量临时改一下让命令优先指向这套目录。你在Linux下创建并激活一个venv后可以自己验证一下mkdir -p ~/demo cd ~/demo python3 -m venv myenv source myenv/bin/activate which python # 输出类似 /home/user/demo/myenv/bin/python echo $VIRTUAL_ENV # 输出 /home/user/demo/myenv你会发现which python指向的不再是/usr/bin/python而是虚拟环境里的那个。激活脚本做的事本质上就是改了PATH把myenv/bin放到最前面同时设置一个VIRTUAL_ENV变量记录当前环境路径。你看到的shell提示符前面多了个(myenv)也是脚本干的好事。所以虚拟环境不是隔离是重新定位——让工具链默认指向一套独立的文件而已。理解了这一点后面遇到激活了但pip还是全局的命令找不到这类问题你就能自己顺着PATH去排查了。2. 选型不纠结venv、virtualenv、conda的真实边界与取舍2.1 三者的血缘关系与分岔路口很多人一开始会困惑网上教程一会儿说venv一会儿说virtualenv一会儿又说conda到底用哪个我帮你把来龙去脉理清楚。venvPython 3.3以后标准库自带的虚拟环境模块名字就叫venv。你装好Python 3就有它不用额外装任何东西。virtualenv一个第三方工具比venv出现得早Python 2时代的老将。它兼容性更强能在同一台机器上创建基于不同Python版本的环境但需要单独pip install virtualenv安装。condaAnaconda或Miniconda自带的包管理工具它不只是管Python包连Python解释器本身甚至系统层面的库比如CUDA、gcc、OpenBLAS它都能管。conda创建环境时可以直接指定Python版本。这三个不是竞争关系而是定位完全不同的工具。venv和virtualenv更像是给你一个干净的房间conda则是连房间带家具家电全包。2.2 一张表看懂选型差异维度venvvirtualenvconda安装成本Python 3自带需pip安装需装Anaconda/Miniconda创建命令python3 -m venv envvirtualenv envconda create -n env python3.11支持多Python版本只能用当前解释器支持指定解释器支持且非常方便隔离非Python软件不支持不支持支持如CUDA、MKL激活动作source env/bin/activate同左conda activate env环境体积小几十MB量级小较大base环境可能几个GB离线迁移便利度一般需重建一般配合conda-pack很方便适合场景常规Python项目老项目/特殊兼容需求科学计算、多种Python并存2.3 我的选型原则在真实项目里我的习惯是这样的默认选venv。只要项目的Python版本要求和我系统里的一致venv最轻量、最省事、无额外依赖。大部分Web项目、脚本工具、数据处理脚本用它完全够。项目明确要不同Python版本时我用conda。因为conda创建环境时一句话就能指定python3.9、python3.11而venv只能用你当前调用的那个解释器。项目依赖涉及非Python的底层库时也优先conda。比如某些深度学习项目要CUDA、要MKLconda能把这些和Python包一起装进同一个环境版本匹配问题它帮你处理。只有维护那种十年前的老项目、必须用Python 2.x的时候我才会翻出virtualenv。坦白讲不少人习惯了一上来就装Anaconda觉得conda万能。我也这么干过但后来发现纯Python项目用conda有点杀鸡用牛刀base环境几百兆到几个G在小机器上光conda activate就能明显感到卡顿。所以我现在是按需选型而不是一把梭。3. venv实操一个经过验证的最小化落地流程3.1 环境准备与创建先确认系统里有没有Python 3以及版本是多少python3 --version只要版本是3.3以上就自带venv模块。个别发行版可能需要额外装python3-venv包比如Debian/Ubuntu系的精简安装如果执行创建命令时报错先补装sudo apt install python3-venv python3-pip然后在你项目的根目录里创建虚拟环境。我这里建议用.venv作为目录名点开头的隐藏目录不容易被误删也方便和源码区分cd ~/myproject python3 -m venv .venv创建完成后目录结构大概是这样的.venv/ ├── bin/ # python、pip、activate脚本都在这里 ├── include/ # 编译相关头文件 ├── lib/ # site-packages存放依赖包 └── pyvenv.cfg # 环境配置文件这个pyvenv.cfg值得看一眼它记录了当前环境绑定的系统Python路径和版本是判断环境和解释器对应关系的依据。3.2 激活环境确认你真的进入了Linux下激活venv执行的是bin目录下的activate脚本source .venv/bin/activate注意是source不是直接执行./activate。source的语义是在当前shell进程里运行脚本这样才能修改当前shell的PATH。如果你直接./activate它会在子shell里执行等你看到结果时环境变量已经还回去了你会觉得激活了个寂寞。激活后建议立刻做两件事确认状态which python pip -V正常情况which python指向.venv/bin/pythonpip -V显示pip ... from /path/to/.venv/lib/python3.x/site-packages/pip。这一步是后面所有排错的基础。3.3 把pip源换成国内镜像没有这一步你会怀疑人生装依赖之前我强烈建议先配好pip镜像源。从官方源拉包在跨境网络环境下速度可能慢到让你怀疑是不是卡死了。配置方法很简单一行命令pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple装完后配置会写在~/.config/pip/pip.conf里。除了清华源阿里云、腾讯云、豆瓣的PyPI镜像我都试过日常用清华和阿里都算稳定。如果你是临时用某个源不想永久写入配置可以这样pip install -i https://pypi.tuna.tsinghua.edu.cn/simple some-package镜像源这个东西属于不用不知道一用回不去系列。尤其在Linux服务器上网络环境五花八门先把源配好再装包能省掉大把等待时间。3.4 安装依赖、导出清单、退出环境激活之后装包和平常一样用pippip install requests flask装完以后马上导出依赖清单这是让项目具备可复现性的关键一步pip freeze requirements.txt生成的requirements.txt会记录当前环境所有包和精确版本号。下次换机器或者同事接手时一条命令就能复现环境pip install -r requirements.txt退出虚拟环境也很简单deactivate这里特别提醒deactivate是venv和virtualenv提供的shell函数不是可执行文件。有些人在脚本里写deactivate没有生效就是因为当前shell里根本没执行过activatedeactivate函数不存在。3.5 项目级规范把虚拟环境放进项目的基础设施我的习惯是把虚拟环境目录当成项目的一部分来管理但绝不让它进版本库。在.gitignore里加一行.venv/这样别人clone项目后只需要跑两条命令就能进入开发状态python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txt如果你嫌每次手动敲太麻烦可以写一个bootstrap.sh放在项目根目录#!/usr/bin/env bash set -e cd $(dirname $0) python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txt echo Environment ready: source .venv/bin/activate这一步看起来不起眼但团队协作时价值很大——新人接手项目的第一道障碍往往就是环境装不起来。4. conda环境的迁移与异地重建从迁移到D盘热搜说起4.1 为什么conda用户总在问迁移问题热搜里那个conda虚拟环境怎么迁移到d盘本质上是所有conda用户都会撞上的一个问题conda默认把环境装在~/anaconda3/envs/下面装在用户目录里。在Windows上用户想放到D盘腾出C盘空间在Linux上用户想把环境放到数据盘或者指定目录避免系统盘爆掉、方便多用户共享。不管哪种情况诉求都是一样的——把一套已经装好的环境整体挪个地方或者迁移到另一台机器上并且尽量不要再一个个重装包。conda环境不像venv那样轻飘飘里面可能装了成百上千个包重装一遍的时间和网络成本都很高所以迁移就成了刚需。4.2 指定安装位置用-p代替-nconda创建环境大家最熟悉的是这样conda create -n myenv python3.11这个-n是--name的简写环境会被装进默认目录。如果你想从一开始就把环境放到指定位置用-p或者--prefixconda create -p /data/envs/proj python3.11注意区别用-n激活时写名字用-p激活时写路径conda activate proj conda activate /data/envs/proj删除环境也一样名字和路径要对应conda env remove -n proj conda env remove -p /data/envs/proj这个-p参数就是迁移到D盘类需求的官方解法从一开始就规划好环境的落盘位置比事后搬动省心得多。在Linux服务器上我习惯把环境统一放在/opt/conda_envs/或者项目挂载的数据盘里一个团队共用一个环境池谁要用谁的互不干扰。4.3 环境快速重建清单迁移的两条路线环境已经建好、在默认位置现在想整体迁走或者换台机器部署怎么办两条路线我都实测过。路线Aconda env export导出完整清单conda env export -n myenv myenv.yml这个myenv.yml会把conda包和pip包全部记录下来在新机器上执行conda env create -f myenv.yml就能重建一个一模一样的环境。好处是完整连空间的构建来源都记录了坏处是myenv.yml里可能包含本机路径信息跨机器时容易踩坑。所以导完之后建议打开看一眼把明显的绝对路径清理掉。路线Brequirements.txt精简迁移如果环境主要依赖pip包我更常用这个pip freeze requirements.txt到了新环境先建一个干净的conda环境conda create -n newenv python3.11 conda activate newenv pip install -r requirements.txt这种方式的优点是人肉可读、清爽缺点是只在Python包维度还原conda层面的库版本要靠你自己控制。4.4 离线整体搬迁conda-pack才是终极方案如果目标机器网络受限或者环境里有很多需要下载的大包清单重建就不现实了。这时候用conda-pack直接打包整个环境是我用过最省事的方案。首先在源机器安装conda-packconda install -c conda-forge conda-pack然后打包环境conda pack -n myenv -o myenv.tar.gz把生成的myenv.tar.gz拷到目标机器解压并激活mkdir -p /path/to/newenv tar -xzf myenv.tar.gz -C /path/to/newenv source /path/to/newenv/bin/activateconda-pack厉害在它会把环境内部的软链接和脚本路径一起修正打包出来的环境解压后基本可以直接用不需要重新解析依赖。我在几台离线服务器之间搬运深度学习环境都是靠这个方案几百个包一次搞定。有一点要提醒conda-pack对目标机器的架构和glibc版本有要求。你在x86_64上打包的转到ARM机器上多半跑不起来源机器glibc太新目标机器系统太老也会出动态库加载错误。打包前先用uname -m确认架构一致再查一下glibc版本。4.5 删除环境的正确姿势删除conda环境很多人直接rm -rf目录这确实能删但不彻底conda的元数据还残留着下次conda env list可能会看到一堆幽灵环境。正确做法是用conda命令删conda env remove -n myenv删之前先看两眼conda env list确认自己没删错尤其别带*的那个当前激活的和base搞混。我曾见过有人手一抖把base环境删了第二天Anaconda整体报废最后还是重装的。删除操作千万别省那一秒钟的确认时间。5. 实战排雷虚拟环境里最容易踩也最难察觉的几个问题5.1 激活了但pip还是全局的被sudo和pip命令分别坑过这是我在新手阶段踩得最狠的一个坑明明source激活了虚拟环境which python也指向了环境里的解释器结果执行pip install装完发现包跑到全局目录去了。排查思路是分三步走which python which pip pip -V如果which pip指向的是/usr/bin/pip而不是.venv/bin/pip那说明你这个pip根本不是虚拟环境里的。常见原因有两个一是你执行pip时加了sudosudo会切换到root用户环境虚拟环境的PATH直接被丢掉了二是系统里pip命令本身用的是另一种包管理器的别名比如pip3和pip指向不同。我在实际项目里的对策很简单在虚拟环境内装包永远用python -m pip不用裸的pip命令。python -m pip install requests这样能保证pip一定是跟随当前python解释器走的那一个不会出现人和命令错位的尴尬。这是个成本极低但收益极高的习惯。5.2 迁移之后的可执行脚本记性太好虚拟环境如果在创建之后被mv挪过位置或者直接把整个目录复制到另一台机器你可能会遇到一个诡异问题环境看起来在但一执行bin/下的脚本就报错常见的是No such file or directory或者直接段错误。原因在于venv创建时会往bin/下的可执行脚本头部写入一行的解释器绝对路径比如#!/home/user/myproject/.venv/bin/python。你把目录改名或挪走之后shebang还是老路径系统按老路径找解释器当然找不到。conda环境也有类似问题很多脚本会记录conda环境前缀。所以我的建议是venv环境一旦创建路径尽量别改。真要换位置最省事的做法是删掉重建。毕竟venv本来就是个轻量环境重建成本很低rm -rf .venv python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txtconda环境则用上一章说的conda-pack或者conda env export重建都比手动把目录搬来搬去靠谱。5.3 你以为的隔离在底层动态库面前可能是漏风的很多教程会告诉你虚拟环境是完全隔离的这个表述在纯Python包层面基本正确但到了C扩展库层面就有点理想化了。比如有的包底层依赖OpenBLAS、libxml2这类系统动态库Python包虽然在虚拟环境里但运行时加载的系统so文件可能还是系统的。最典型的是某些项目在venv里排除了--system-site-packages依然会意外看到系统的NumPy就是因为有系统级依赖穿透了。碰到这种情况不要硬刚优先换成conda环境。conda的强项恰恰是能把libgcc、openblas、cuda这类底层库和Python包装在同一套环境里通过LD_LIBRARY_PATH也一并管理。虚拟环境解决的是依赖管理问题conda解决的是依赖和二进制一致性问题两者不是一个层级的该用重武器时别舍不得。5.4 激活命令混用conda和venv的激活词完全不一样很多人venv和conda环境都在用结果命令混着来在venv里敲conda activate在conda里敲source activate。两种环境对于激活的定义确实不一样venv用的是source .venv/bin/activate退出用deactivateconda 4.4以后的版本推荐用conda activate和conda deactivate而老教程里的source activate在新版本里可能直接报错。判断自己当前处在哪个环境里我习惯看两个变量echo $VIRTUAL_ENV conda info --envsVIRTUAL_ENV变量非空说明在venv环境里conda info --envs里带星号的那一行是当前conda环境。有了这两个判断基本不会糊涂。顺带说一个Jupyter场景你在虚拟环境里装了jupyter但启动后新建内核时找不到这个环境的解释器。这是因为Jupyter自动注册的内核是它自己发现的和你shell里激活的环境没有必然关系。解决办法是在虚拟环境里手动注册内核pip install ipykernel python -m ipykernel install --user --name myenv --display-name Python (myenv)然后再在Jupyter里就能看到对应的内核了。这个坑纯靠日常使用基本遇不到但一旦遇到能卡你半天。6. 最后说点我自己的使用习惯虚拟环境这东西用熟了以后最大的体会是它不应该是一种补救手段而应该是一种前置习惯。我现在每接一个新项目第一件事不是装包而是先建环境每次装完新包顺手就更新requirements或yml清单每次换机器第一选择是conda-pack整体搬而不是从头再装。这些看起来都是小事但长期省下的时间非常可观。还有一个小技巧可以分享在~/.bashrc里给常用项目配一个快捷函数比如function venv-up() { cd ~/myproject source .venv/bin/activate python -m pip install -r requirements.txt }这样每次新打开终端想进入工作状态敲一个venv-up就够了。我自己在几台服务器上都这么配基本告别了记不住项目路径和忘了装依赖这两个低血压时刻。虚拟环境的意义说到底不是让你多用几个命令而是让环境可复现、依赖可追踪、系统不受污染成为默认状态。这一点越早想明白后面越舒坦。
在Linux上折腾Python的人迟早会在一个深夜被依赖冲突逼疯新项目要Python 3.11老服务还锁在3.8系统自带的包管理工具又认死理你一升级cron里跑了几年的脚本第二天全挂。我就是在一次手贱升级requests之后才真正把虚拟环境这几个字刻进脑子的。搭建虚拟环境这件事看着简单其实背后牵扯到系统路径、环境变量、pip归属、镜像源、离线迁移一整套逻辑没理清之前照抄命令后面坑很多。这篇文章我就把从零到一、从创建到迁移、从选型到排雷的完整过程写出来给正在折腾Linux下Python环境的朋友一个能直接照做的参考。本文适合刚接触Linux的开发者、被依赖问题困扰的运维同学以及任何想在服务器或本机上把Python项目环境搞得清爽一点的人。我会按真实使用场景走一遍包括venv、conda两条主流路线的实操以及那些很容易被忽略的坑。1. 被依赖冲突逼到墙角的那个下午虚拟环境到底解决了什么1.1 全局安装模式下的合租公寓困境不装虚拟环境的时候你在Linux上执行pip install xxx默认会把包扔进系统的site-packages目录。这个目录是全系统所有Python程序共享的就好比一个大合租公寓谁都能进来住谁也都可能把公共区域弄乱。最典型的场景项目A需要requests2.28项目B需要requests2.31你指望两个项目在同一个全局环境里和平共处没门。后装的那个版本会覆盖前者项目A第二天可能就出现诡异报错。更麻烦的是Linux自带的好多系统工具本身就依赖特定版本的Python库。比如某些发行版里yum、apt这类包管理器或者gnome-terminal这类桌面组件都和系统Python绑得很紧。你要是为了一个项目把系统里的某个库升了级轻则系统工具告警重则包管理器直接罢工。我一个朋友就在生产服务器上干过这事pip install --upgrade把系统Python的依赖搞坏了结果SSH登录后连apt都用不了差点没被运维同事骂死。1.2 虚拟环境的本质不是隔离而是重新定位很多人把虚拟环境想得很玄以为它像容器或虚拟机一样做了什么隔离魔法。其实没那么高级它干的事核心就三件建一套独立的目录结构、放一个Python解释器或者软链接指向已有解释器、把PATH环境变量临时改一下让命令优先指向这套目录。你在Linux下创建并激活一个venv后可以自己验证一下mkdir -p ~/demo cd ~/demo python3 -m venv myenv source myenv/bin/activate which python # 输出类似 /home/user/demo/myenv/bin/python echo $VIRTUAL_ENV # 输出 /home/user/demo/myenv你会发现which python指向的不再是/usr/bin/python而是虚拟环境里的那个。激活脚本做的事本质上就是改了PATH把myenv/bin放到最前面同时设置一个VIRTUAL_ENV变量记录当前环境路径。你看到的shell提示符前面多了个(myenv)也是脚本干的好事。所以虚拟环境不是隔离是重新定位——让工具链默认指向一套独立的文件而已。理解了这一点后面遇到激活了但pip还是全局的命令找不到这类问题你就能自己顺着PATH去排查了。2. 选型不纠结venv、virtualenv、conda的真实边界与取舍2.1 三者的血缘关系与分岔路口很多人一开始会困惑网上教程一会儿说venv一会儿说virtualenv一会儿又说conda到底用哪个我帮你把来龙去脉理清楚。venvPython 3.3以后标准库自带的虚拟环境模块名字就叫venv。你装好Python 3就有它不用额外装任何东西。virtualenv一个第三方工具比venv出现得早Python 2时代的老将。它兼容性更强能在同一台机器上创建基于不同Python版本的环境但需要单独pip install virtualenv安装。condaAnaconda或Miniconda自带的包管理工具它不只是管Python包连Python解释器本身甚至系统层面的库比如CUDA、gcc、OpenBLAS它都能管。conda创建环境时可以直接指定Python版本。这三个不是竞争关系而是定位完全不同的工具。venv和virtualenv更像是给你一个干净的房间conda则是连房间带家具家电全包。2.2 一张表看懂选型差异维度venvvirtualenvconda安装成本Python 3自带需pip安装需装Anaconda/Miniconda创建命令python3 -m venv envvirtualenv envconda create -n env python3.11支持多Python版本只能用当前解释器支持指定解释器支持且非常方便隔离非Python软件不支持不支持支持如CUDA、MKL激活动作source env/bin/activate同左conda activate env环境体积小几十MB量级小较大base环境可能几个GB离线迁移便利度一般需重建一般配合conda-pack很方便适合场景常规Python项目老项目/特殊兼容需求科学计算、多种Python并存2.3 我的选型原则在真实项目里我的习惯是这样的默认选venv。只要项目的Python版本要求和我系统里的一致venv最轻量、最省事、无额外依赖。大部分Web项目、脚本工具、数据处理脚本用它完全够。项目明确要不同Python版本时我用conda。因为conda创建环境时一句话就能指定python3.9、python3.11而venv只能用你当前调用的那个解释器。项目依赖涉及非Python的底层库时也优先conda。比如某些深度学习项目要CUDA、要MKLconda能把这些和Python包一起装进同一个环境版本匹配问题它帮你处理。只有维护那种十年前的老项目、必须用Python 2.x的时候我才会翻出virtualenv。坦白讲不少人习惯了一上来就装Anaconda觉得conda万能。我也这么干过但后来发现纯Python项目用conda有点杀鸡用牛刀base环境几百兆到几个G在小机器上光conda activate就能明显感到卡顿。所以我现在是按需选型而不是一把梭。3. venv实操一个经过验证的最小化落地流程3.1 环境准备与创建先确认系统里有没有Python 3以及版本是多少python3 --version只要版本是3.3以上就自带venv模块。个别发行版可能需要额外装python3-venv包比如Debian/Ubuntu系的精简安装如果执行创建命令时报错先补装sudo apt install python3-venv python3-pip然后在你项目的根目录里创建虚拟环境。我这里建议用.venv作为目录名点开头的隐藏目录不容易被误删也方便和源码区分cd ~/myproject python3 -m venv .venv创建完成后目录结构大概是这样的.venv/ ├── bin/ # python、pip、activate脚本都在这里 ├── include/ # 编译相关头文件 ├── lib/ # site-packages存放依赖包 └── pyvenv.cfg # 环境配置文件这个pyvenv.cfg值得看一眼它记录了当前环境绑定的系统Python路径和版本是判断环境和解释器对应关系的依据。3.2 激活环境确认你真的进入了Linux下激活venv执行的是bin目录下的activate脚本source .venv/bin/activate注意是source不是直接执行./activate。source的语义是在当前shell进程里运行脚本这样才能修改当前shell的PATH。如果你直接./activate它会在子shell里执行等你看到结果时环境变量已经还回去了你会觉得激活了个寂寞。激活后建议立刻做两件事确认状态which python pip -V正常情况which python指向.venv/bin/pythonpip -V显示pip ... from /path/to/.venv/lib/python3.x/site-packages/pip。这一步是后面所有排错的基础。3.3 把pip源换成国内镜像没有这一步你会怀疑人生装依赖之前我强烈建议先配好pip镜像源。从官方源拉包在跨境网络环境下速度可能慢到让你怀疑是不是卡死了。配置方法很简单一行命令pip config set global.index-url https://pypi.tuna.tsinghua.edu.cn/simple装完后配置会写在~/.config/pip/pip.conf里。除了清华源阿里云、腾讯云、豆瓣的PyPI镜像我都试过日常用清华和阿里都算稳定。如果你是临时用某个源不想永久写入配置可以这样pip install -i https://pypi.tuna.tsinghua.edu.cn/simple some-package镜像源这个东西属于不用不知道一用回不去系列。尤其在Linux服务器上网络环境五花八门先把源配好再装包能省掉大把等待时间。3.4 安装依赖、导出清单、退出环境激活之后装包和平常一样用pippip install requests flask装完以后马上导出依赖清单这是让项目具备可复现性的关键一步pip freeze requirements.txt生成的requirements.txt会记录当前环境所有包和精确版本号。下次换机器或者同事接手时一条命令就能复现环境pip install -r requirements.txt退出虚拟环境也很简单deactivate这里特别提醒deactivate是venv和virtualenv提供的shell函数不是可执行文件。有些人在脚本里写deactivate没有生效就是因为当前shell里根本没执行过activatedeactivate函数不存在。3.5 项目级规范把虚拟环境放进项目的基础设施我的习惯是把虚拟环境目录当成项目的一部分来管理但绝不让它进版本库。在.gitignore里加一行.venv/这样别人clone项目后只需要跑两条命令就能进入开发状态python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txt如果你嫌每次手动敲太麻烦可以写一个bootstrap.sh放在项目根目录#!/usr/bin/env bash set -e cd $(dirname $0) python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txt echo Environment ready: source .venv/bin/activate这一步看起来不起眼但团队协作时价值很大——新人接手项目的第一道障碍往往就是环境装不起来。4. conda环境的迁移与异地重建从迁移到D盘热搜说起4.1 为什么conda用户总在问迁移问题热搜里那个conda虚拟环境怎么迁移到d盘本质上是所有conda用户都会撞上的一个问题conda默认把环境装在~/anaconda3/envs/下面装在用户目录里。在Windows上用户想放到D盘腾出C盘空间在Linux上用户想把环境放到数据盘或者指定目录避免系统盘爆掉、方便多用户共享。不管哪种情况诉求都是一样的——把一套已经装好的环境整体挪个地方或者迁移到另一台机器上并且尽量不要再一个个重装包。conda环境不像venv那样轻飘飘里面可能装了成百上千个包重装一遍的时间和网络成本都很高所以迁移就成了刚需。4.2 指定安装位置用-p代替-nconda创建环境大家最熟悉的是这样conda create -n myenv python3.11这个-n是--name的简写环境会被装进默认目录。如果你想从一开始就把环境放到指定位置用-p或者--prefixconda create -p /data/envs/proj python3.11注意区别用-n激活时写名字用-p激活时写路径conda activate proj conda activate /data/envs/proj删除环境也一样名字和路径要对应conda env remove -n proj conda env remove -p /data/envs/proj这个-p参数就是迁移到D盘类需求的官方解法从一开始就规划好环境的落盘位置比事后搬动省心得多。在Linux服务器上我习惯把环境统一放在/opt/conda_envs/或者项目挂载的数据盘里一个团队共用一个环境池谁要用谁的互不干扰。4.3 环境快速重建清单迁移的两条路线环境已经建好、在默认位置现在想整体迁走或者换台机器部署怎么办两条路线我都实测过。路线Aconda env export导出完整清单conda env export -n myenv myenv.yml这个myenv.yml会把conda包和pip包全部记录下来在新机器上执行conda env create -f myenv.yml就能重建一个一模一样的环境。好处是完整连空间的构建来源都记录了坏处是myenv.yml里可能包含本机路径信息跨机器时容易踩坑。所以导完之后建议打开看一眼把明显的绝对路径清理掉。路线Brequirements.txt精简迁移如果环境主要依赖pip包我更常用这个pip freeze requirements.txt到了新环境先建一个干净的conda环境conda create -n newenv python3.11 conda activate newenv pip install -r requirements.txt这种方式的优点是人肉可读、清爽缺点是只在Python包维度还原conda层面的库版本要靠你自己控制。4.4 离线整体搬迁conda-pack才是终极方案如果目标机器网络受限或者环境里有很多需要下载的大包清单重建就不现实了。这时候用conda-pack直接打包整个环境是我用过最省事的方案。首先在源机器安装conda-packconda install -c conda-forge conda-pack然后打包环境conda pack -n myenv -o myenv.tar.gz把生成的myenv.tar.gz拷到目标机器解压并激活mkdir -p /path/to/newenv tar -xzf myenv.tar.gz -C /path/to/newenv source /path/to/newenv/bin/activateconda-pack厉害在它会把环境内部的软链接和脚本路径一起修正打包出来的环境解压后基本可以直接用不需要重新解析依赖。我在几台离线服务器之间搬运深度学习环境都是靠这个方案几百个包一次搞定。有一点要提醒conda-pack对目标机器的架构和glibc版本有要求。你在x86_64上打包的转到ARM机器上多半跑不起来源机器glibc太新目标机器系统太老也会出动态库加载错误。打包前先用uname -m确认架构一致再查一下glibc版本。4.5 删除环境的正确姿势删除conda环境很多人直接rm -rf目录这确实能删但不彻底conda的元数据还残留着下次conda env list可能会看到一堆幽灵环境。正确做法是用conda命令删conda env remove -n myenv删之前先看两眼conda env list确认自己没删错尤其别带*的那个当前激活的和base搞混。我曾见过有人手一抖把base环境删了第二天Anaconda整体报废最后还是重装的。删除操作千万别省那一秒钟的确认时间。5. 实战排雷虚拟环境里最容易踩也最难察觉的几个问题5.1 激活了但pip还是全局的被sudo和pip命令分别坑过这是我在新手阶段踩得最狠的一个坑明明source激活了虚拟环境which python也指向了环境里的解释器结果执行pip install装完发现包跑到全局目录去了。排查思路是分三步走which python which pip pip -V如果which pip指向的是/usr/bin/pip而不是.venv/bin/pip那说明你这个pip根本不是虚拟环境里的。常见原因有两个一是你执行pip时加了sudosudo会切换到root用户环境虚拟环境的PATH直接被丢掉了二是系统里pip命令本身用的是另一种包管理器的别名比如pip3和pip指向不同。我在实际项目里的对策很简单在虚拟环境内装包永远用python -m pip不用裸的pip命令。python -m pip install requests这样能保证pip一定是跟随当前python解释器走的那一个不会出现人和命令错位的尴尬。这是个成本极低但收益极高的习惯。5.2 迁移之后的可执行脚本记性太好虚拟环境如果在创建之后被mv挪过位置或者直接把整个目录复制到另一台机器你可能会遇到一个诡异问题环境看起来在但一执行bin/下的脚本就报错常见的是No such file or directory或者直接段错误。原因在于venv创建时会往bin/下的可执行脚本头部写入一行的解释器绝对路径比如#!/home/user/myproject/.venv/bin/python。你把目录改名或挪走之后shebang还是老路径系统按老路径找解释器当然找不到。conda环境也有类似问题很多脚本会记录conda环境前缀。所以我的建议是venv环境一旦创建路径尽量别改。真要换位置最省事的做法是删掉重建。毕竟venv本来就是个轻量环境重建成本很低rm -rf .venv python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txtconda环境则用上一章说的conda-pack或者conda env export重建都比手动把目录搬来搬去靠谱。5.3 你以为的隔离在底层动态库面前可能是漏风的很多教程会告诉你虚拟环境是完全隔离的这个表述在纯Python包层面基本正确但到了C扩展库层面就有点理想化了。比如有的包底层依赖OpenBLAS、libxml2这类系统动态库Python包虽然在虚拟环境里但运行时加载的系统so文件可能还是系统的。最典型的是某些项目在venv里排除了--system-site-packages依然会意外看到系统的NumPy就是因为有系统级依赖穿透了。碰到这种情况不要硬刚优先换成conda环境。conda的强项恰恰是能把libgcc、openblas、cuda这类底层库和Python包装在同一套环境里通过LD_LIBRARY_PATH也一并管理。虚拟环境解决的是依赖管理问题conda解决的是依赖和二进制一致性问题两者不是一个层级的该用重武器时别舍不得。5.4 激活命令混用conda和venv的激活词完全不一样很多人venv和conda环境都在用结果命令混着来在venv里敲conda activate在conda里敲source activate。两种环境对于激活的定义确实不一样venv用的是source .venv/bin/activate退出用deactivateconda 4.4以后的版本推荐用conda activate和conda deactivate而老教程里的source activate在新版本里可能直接报错。判断自己当前处在哪个环境里我习惯看两个变量echo $VIRTUAL_ENV conda info --envsVIRTUAL_ENV变量非空说明在venv环境里conda info --envs里带星号的那一行是当前conda环境。有了这两个判断基本不会糊涂。顺带说一个Jupyter场景你在虚拟环境里装了jupyter但启动后新建内核时找不到这个环境的解释器。这是因为Jupyter自动注册的内核是它自己发现的和你shell里激活的环境没有必然关系。解决办法是在虚拟环境里手动注册内核pip install ipykernel python -m ipykernel install --user --name myenv --display-name Python (myenv)然后再在Jupyter里就能看到对应的内核了。这个坑纯靠日常使用基本遇不到但一旦遇到能卡你半天。6. 最后说点我自己的使用习惯虚拟环境这东西用熟了以后最大的体会是它不应该是一种补救手段而应该是一种前置习惯。我现在每接一个新项目第一件事不是装包而是先建环境每次装完新包顺手就更新requirements或yml清单每次换机器第一选择是conda-pack整体搬而不是从头再装。这些看起来都是小事但长期省下的时间非常可观。还有一个小技巧可以分享在~/.bashrc里给常用项目配一个快捷函数比如function venv-up() { cd ~/myproject source .venv/bin/activate python -m pip install -r requirements.txt }这样每次新打开终端想进入工作状态敲一个venv-up就够了。我自己在几台服务器上都这么配基本告别了记不住项目路径和忘了装依赖这两个低血压时刻。虚拟环境的意义说到底不是让你多用几个命令而是让环境可复现、依赖可追踪、系统不受污染成为默认状态。这一点越早想明白后面越舒坦。
