在 VPS 上运行 pip install -r requirements.txt，却看到 error: externally-managed-environment？这通常不是网络、镜像源或权限出了问题，而是当前 Python 环境由系统包管理器维护，pip 被要求不要直接修改它。
部署自己的 Python 项目，通常应该创建项目专用的 venv；安装独立命令行工具，可以考虑 pipx；系统工具依赖的包则优先交给 apt。这篇把三种情况拆开，避免靠强制安装解决眼前报错，之后又让系统工具或其他项目出问题。
在准备部署的项目目录执行：
command -v python3
python3 --version
python3 -m pip --version
python3 -c "import sys; print(sys.executable); print(sys.prefix); print(sys.base_prefix)"
python3 -m pip 让 pip 与指定的解释器对应，减少 pip、pip3 指向其他安装的情况。最后两行路径相同，通常说明没有运行在 venv 中；路径不同则说明正在使用虚拟环境。若根本没有 pip，报错会是 No module named pip，要与外部托管限制区分。
Python 包管理规范使用 EXTERNALLY-MANAGED 标记说明解释器受外部管理。它不代表 Python 损坏，也不是让你把标记文件删掉。sudo pip 或 pip install --user 都不应该当作这类报错的通用解决办法。
| 你想安装什么 | 合适的入口 | 安装后的使用方式 |
|---|---|---|
| 网站、API、脚本项目的依赖 | 项目自己的 venv | 使用 .venv/bin/python 运行项目 |
| 独立 Python 命令行应用 | pipx | 运行 pipx 提供的命令 |
| 发行版打包的系统组件 | apt 等系统包管理器 | 按发行版文档使用 |
pipx 会为命令行应用维护独立环境，并提供可执行命令，见 PyPA 的独立命令行工具指南。它不是给任意项目批量安装 requirements.txt 的替代品。
以下适用于 Linux 上已有的 Python 项目。先进入含有可信 requirements.txt 的项目目录，再运行：
python3 -m venv .venv
.venv/bin/python -m pip --version
.venv/bin/python -m pip install -r requirements.txt
.venv/bin/python -m pip check
如果项目已经有 .venv，先核对原解释器、依赖清单和运行服务，不要直接删除重建。创建新环境时使用项目支持的 Python 版本，不能为了通过安装随便换成另一个大版本。
依赖版本应以项目随附的锁定文件或部署说明为准。不要在恢复部署时顺便批量升级全部包，否则即使安装通过，也可能引入新的应用兼容问题。
上面的绝对或相对解释器路径已经足够，不必先激活环境。venv 文档说明，激活主要是调整当前 shell 的 PATH；直接调用虚拟环境中的解释器也可以运行。
想让交互式操作方便些，可以在 Bash 或 Zsh 中执行：
source .venv/bin/activate
python -m pip --version
python -c "import sys; print(sys.executable)"
deactivate
此时 pip 和 Python 的位置应落在当前项目的 .venv 中。deactivate 只恢复当前 shell 的环境设置，不卸载包，也不删除虚拟环境。安装后按项目文档做导入、启动或健康检查；pip check 通过仅说明声明的依赖关系没有检测到冲突，不等于业务正常。
Ubuntu、Debian 精简系统上可能出现 ensurepip is not available。若使用发行版默认的 python3，可通过发行版仓库安装 venv 支持：
sudo apt update
sudo apt install python3-venv
安装完成后再创建项目环境。Ubuntu 的 Python 环境说明也提供了包含 venv 支持的 python3-full 方案。按缺失组件选择即可，不需要为了装依赖移除系统 Python。
如果解释器来自其他版本仓库、源码、pyenv 或面板，默认 python3-venv 不一定匹配它。先确认创建命令调用的解释器，再按同一来源补齐支持。不要修改 /usr/bin/python3 的链接来强行迁就单个项目。
若错误已经变成证书校验失败、连接超时、找不到兼容版本或编译扩展失败，就进入了另一层问题。检查包源、网络、Python 版本、平台和构建依赖；继续加权限或删除环境标记不会解决这些错误。
对于仓库提供 pipx 的 Ubuntu / Debian 系统，可以先安装工具：
sudo apt install pipx
pipx ensurepath
pipx list
然后按目标应用官方文档执行 pipx install 应用的发行包名。这里的包名必须换成实际提供 CLI 的发行包，不是随便一个可导入库。ensurepath 调整后可能要重新登录 SSH 或打开新的 shell，才能让命令被 PATH 找到。
pipx 安装成功，不意味着网站项目的 Python 能导入那个包；它们本来就是不同环境。若你的代码需要 import 某个库，应在项目 venv 中安装。系统包名、PyPI 发行包名和 Python 导入名也可能不同，不要只按报错里的模块名猜安装命令。
激活只影响当前 shell。你退出 SSH、换用户或由后台服务启动时，进程不会自动继承这次激活操作。
假设项目固定在 /srv/myapp，服务应调用 /srv/myapp/.venv/bin/python，并设置正确的工作目录、运行用户和环境变量。Web 服务也可直接使用 /srv/myapp/.venv/bin/gunicorn 等实际入口，而不是假设裸 python 会指向项目环境。
不要把 source .venv/bin/activate 当成 systemd ExecStart 的普通可执行命令。完整上线方式见 VPS 部署 Python 项目教程；后台启动失败则接着看 systemd 服务排查。
迁移 VPS 时也不建议直接复制 .venv。虚拟环境可能包含绝对路径及平台相关文件，应保留项目、依赖锁定信息和必要配置，在目标系统重建，再验证服务。
pip 的安装选项把这个开关定义为允许修改外部托管的 Python 安装。它绕过限制，但不会替你隔离项目依赖，也不会保证与 apt 管理的包兼容。
对单个项目，先用 venv 解决环境归属；对 CLI，用 pipx；对系统组件，用发行版包。若此前已经强制安装过包，先保存安装记录并确认受影响工具，再安排修复，别批量卸载不认识的系统依赖。
本文用本机 macOS 的 Python 3.14.0、pip 25.2 完成 8 项检查：临时 venv 能安装并导入自建离线演示包，基础解释器和另一项目环境无法导入它，激活与直接调用路径均按预期工作，pip check 通过。这不代表已复现 Ubuntu 的外部托管报错，也不包含 apt、pipx、联网下载、真实项目编译或 systemd 服务实测。