前言在 Linux 上「搭建 Python 环境」第一件要建立的概念是你多半不需要装 Python。绝大多数发行版出厂就带 Python 3而且这个自带版本不是给你随便用的——包管理器、系统配置工具、桌面环境的一些组件都依赖它。这带来一个很多从 Windows 转过来的用户不理解的现象为什么在 Linux 上pip install会被拒绝为什么网上都说「不要sudo升级系统的 Python」原因很简单。系统的 Python 是发行版的一部分它和一堆系统包是作为一个整体被测试和发布的。你把某个第三方库升上去可能让某个系统工具在下次开机时起不来。而且发行版通常只打安全补丁不会跟上游小版本所以它看起来「很旧」是正常的。因此 Linux 上的正确姿势是系统 Python 原样保留自己的项目另建隔离环境。本文就按这个思路展开同时讲清楚新发行版里pip会直接报错的那条 PEP 668 限制是怎么回事。一、先摸清系统里有什么动手之前先做侦察不要急着装东西。# 需要 bash查看系统里已有的 Pythonpython3 --versionwhich -a python3ls -l /usr/bin/python3# 需要 bash看看发行版自带的包管理器给 Python 装了什么# Debian / Ubuntu 系dpkg -l | grep -i python3 | head# Red Hat / Fedora 系rpm -qa | grep -i python3 | headwhich -a python3会列出PATH里所有叫python3的可执行文件。如果只出现/usr/bin/python3说明系统里只有一份后续都得靠虚拟环境来隔离。要特别注意一点很多现代发行版故意不提供python这个名字只提供python3。这是因为历史上python曾被 Python 2 占用发行版为了不误伤脚本干脆把这个名字留空。所以你在 Linux 上敲python报找不到命令是完全正常的不代表没装 Python。二、为什么不要动系统 Python做法后果替代方案sudo pip install 包到系统环境可能与系统包冲突系统工具行为异常建 venv 后安装覆盖/usr/bin/python3的版本包管理器可能直接不可用用 pyenv 或源码装到独立前缀修改系统 Python 的sys.path影响所有依赖它的系统脚本在虚拟环境里调整卸载发行版自带的 python3可能连带卸载一批系统组件保留另装新版本具体后果可以设想成这样系统的软件包管理工具本身就是用 Python 写的。你把它的某个依赖库升级到不兼容的版本下次执行安装命令时就可能直接崩掉而且因为包管理器坏了修复手段也少了。这就是「不要动系统 Python」这条建议的由来。三、虚拟环境Linux 上的标准做法# 需要 Python 3.3Debian/Ubuntu 上 venv 可能需要单独装包# sudo apt install python3-venvcd 你的项目目录python3 -m venv .venvsource .venv/bin/activatepython -m pip install --upgrade pipDebian 和 Ubuntu 把venv拆成了独立的系统包所以有时python3 -m venv会提示缺少ensurepip这时按上面的方式把python3-venv装上即可。Red Hat / Fedora 系一般直接可用。激活之后python和pip都指向环境内部的副本。这里有个细节值得记住在虚拟环境里命令就叫python因为环境目录的bin被放到了PATH最前面你不需要写python3。不激活也能用# 需要 bash用环境内解释器的绝对路径./.venv/bin/python -m pip list在 systemd 服务、cron 任务、CI 脚本里写绝对路径比依赖「激活了哪个环境」更稳定。四、需要别的版本时怎么办用版本管理器pyenv这类版本管理器把多个 Python 装在用户目录下通过修改PATH或 shim 来决定用哪一个。好处是不碰系统目录随时切换代价是初次编译较慢而且它属于第三方工具具体用法以其官方文档为准。装完通常是这样用的# 需要 bashpyenv 属于第三方工具命令以官方文档为准pyenv install 3.12.0 # 装一个具体版本pyenv global 3.12.0 # 设为全局默认pyenv local 3.12.0 # 只对当前目录生效从源码编译想在系统里同时保留发行版 Python、又装一个自己版本的时候从源码编译到独立前缀是标准做法# 需要 bash从源码编译安装到自定义前缀./configure --prefix/opt/python312 --enable-optimizationsmake -j$(nproc)sudo make altinstall关键点有两个--prefix指定独立前缀不覆盖/usr这样就不会碰到系统 Python。用make altinstall而不是make install。前者安装的是带版本号的可执行文件如python3.12和对应的库目录不会去创建或覆盖名为python3的软链接后者会从而可能顶掉系统的那一份。编译需要 C 编译器和一堆开发库这一步在服务器上往往比想象中麻烦建议优先考虑版本管理器或直接换一个自带合适版本的基础镜像。五、pip 在 Linux 上的新限制如果你用的是较新的 Debian、Ubuntu、Fedora直接对系统 Python 执行pip install可能会看到这样的报错error: externally-managed-environment× This environment is externally managed╰─ To install Python packages system-wide, try apt installpython3-xyz, where xyz is the package you are trying toinstall.这是 PEP 668 引入的机制发行版在基础环境的库目录里放一个标记文件pip看到它就知道「这个环境由系统包管理器负责」于是拒绝安装。这不是 bug是保护措施。正确应对方式有三条优先级从高到低建虚拟环境在环境里装。这是绝大多数场景的答案。用发行版的包管理器装系统级工具比如对应的发行版包名。确实需要全局安装命令行工具时用pipx这类工具它会给每个工具建独立环境。# 需要 Python 3.3python3 -m venv .venvsource .venv/bin/activatepython -m pip install 包名常见坑点sudo pip install装到系统环境❌ 为了省事直接sudo pip install某天系统工具报ImportError。✅ 建 venv 后安装。新发行版会直接拒绝这种操作并提示externally-managed-environment这是 PEP 668 的保护不要去强行绕过。试图卸载系统的python3❌ 想装新版本先把系统的卸了结果包管理器一起被带走。✅ 系统的 Python 原样保留新版本装到独立前缀或由版本管理器托管。以为 Linux 上敲python应该能用❌ 敲python报找不到以为环境没配好。✅ 很多发行版只提供python3这是有意为之。用python3或者在虚拟环境里用python。覆盖/usr/bin/python3的软链接❌ 手动改软链接指向自己编译的新版本命令行工具开始集体出错。✅ 用make altinstall避免覆盖或把新版本装到/opt等独立前缀通过PATH优先使用。python3 -m venv报缺ensurepip❌ 在 Debian/Ubuntu 上直接跑报错就放弃。✅ 系统把 venv 拆成了单独的包按发行版装上对应的python3-venv再试。在 cron 或服务脚本里依赖「已激活的环境」❌ 脚本里写python xxx.py手动跑没问题放进定时任务就失败。✅ 用环境内解释器的绝对路径/path/to/.venv/bin/python xxx.py。PATH顺序导致用错解释器❌ 装了版本管理器又改了PATH结果python3一会儿是这个一会儿是那个。✅ 用which -a python3确认顺序必要时在脚本里写死绝对路径。把所有东西都装进系统 Python 的--user目录❌ 用pip install --user长期往用户目录堆包几年后一堆版本冲突无从排查。✅--user只用于确实需要的全局工具项目依赖一律进 venv。总结需求推荐做法不要做用系统自带的 Python直接python3用pip往里装包项目依赖python3 -m venv .venvsudo pip install换 Python 版本版本管理器或源码装到独立前缀覆盖/usr/bin/python3装命令行工具独立环境工具如 pipx全局装进系统环境遇到 PEP 668 报错建虚拟环境绕过保护强行安装Linux 上搭建 Python 环境的核心只有一句话系统的归系统项目的归项目。系统自带的 Python 负责让系统工具正常运转你的代码跑在各自的虚拟环境里两边互不干扰。守住这条线Linux 反而是三个平台里最省心的。