唯一安全解法是用 python3 -m venv 创建虚拟环境；因 PEP 668 将系统 Python 标记为外部管理，pip 检测到 /pyvenv.cfg 中 externally-managed = true 或 EXTERNALLY-MANAGED 文件即中止安装，防止覆盖 apt/dnf/pacman 管理的包引发系统崩溃。
直接结论：别碰系统 Python，用 python3 -m venv 创建虚拟环境是唯一安全、可长期维护的解法。
为什么 pip install 会卡在 “externally-managed-environment”
这不是 pip 坏了，也不是你权限不够，而是系统 Python（比如 /usr/bin/python3）被发行版主动“上锁”了。Ubuntu 23.04+、Debian 12+、Fedora 38+、Arch/Manjaro、Kali 等默认启用 PEP 668 —— 它会在 pyvenv.cfg 里写 externally-managed = true，或在 site-packages 下放一个 EXTERNALLY-MANAGED 文件。pip 检测到这个标记，就立刻中止安装，防止你用 pip install 覆盖 apt/dnf/pacman 管理的包，导致 apt 崩溃、桌面起不来这类真实事故。
用 venv 创建隔离环境（推荐且必须掌握）
这是官方唯一推荐、CI/CD 和团队协作的基准做法。系统 Python 保持干净，你的项目依赖完全可控。
- 创建：
python3 -m venv ~/myproject-env（venv是标准库，无需额外安装） - 激活：
source ~/myproject-env/bin/activate（Linux/macOS）或~/myproject-env/Scripts/activate.bat（Windows） - 验证：
which python应输出~/myproject-env/bin/python；pip --version显示路径也应在该目录下 - 此时
pip install requests就能正常执行，不再报错
注意：venv 不是“临时方案”，它是 Python 生态的事实标准。别用 sudo pip install —— 多数发行版已禁用 root 权限下的 pip 写入，且会污染系统。
什么时候该用 pipx 而不是 venv
当你想装的是命令行工具（比如 black、httpx、poetry），而不是开发依赖时，pipx 比手动管理一堆 venv 更省心。
- 先装 pipx：
sudo apt install pipx（Debian/Ubuntu）或sudo pacman -S python-pipx（Arch/Manjaro） - 初始化路径：
pipx ensurepath，然后重启终端或运行source ~/.local/bin - 安装工具：
pipx install black→ 自动创建独立虚拟环境，并把black命令软链到$PATH
pipx 本质是 venv 的封装，但专为 CLI 工具设计。它不解决项目开发依赖问题，也不替代 requirements.txt 流程。
绕过检查的风险与适用边界
--break-system-packages 不是“修复”，是明确告诉 pip：“我清楚可能让 apt 失效、桌面崩溃、下次系统升级后包全丢”。只在极少数场景下临时用：
- 快速验证某个脚本是否真需要某包（非安装到系统）
- Docker 构建中无法改基础镜像，又必须跑一条 pip 命令（应优先换用
python:slim或带 venv 的多阶段构建） - 你正在调试 PEP 668 本身（99.9% 的人不需要）
绝对不要：alias pip='pip --break-system-packages'、写进 CI 脚本、或用于安装 django numpy 这类项目依赖。它绕过了保护，没绕过后果。
真正容易被忽略的点是：这个机制不是 Linux 特有 —— macOS 上通过 Homebrew 安装的 Python@3.12、以及 Windows 上 python.org 官方安装器的“Add Python to PATH”选项，只要启用了 PEP 668（Python 3.12+ 默认启用），同样会触发该错误。判断依据永远是 python -c "import sysconfig; print(sysconfig.get_config_var('externally_managed'))" 是否返回 True，而不是看操作系统。
