系统 Python 的 site-packages 不可乱动，因会破坏 apt、macOS 后台服务等系统工具依赖，导致 apt update 报错、GUI 工具失效甚至 sudo 异常；pip install 需 sudo、包来源混杂、ABI 不兼容易引发延迟性崩溃。
系统 Python 的 site-packages 为什么不能乱动
直接用 pip install 装包到系统 Python（比如 macOS 自带的 /usr/bin/python3，或 Ubuntu 的 /usr/lib/python3/dist-packages），最直接的风险是破坏系统工具依赖。Ubuntu 的 apt、macOS 的某些后台服务、甚至 GNOME 或 KDE 的组件，都可能依赖特定版本的 python3-requests 或 python3-gi。一旦你用 pip 升级或覆盖了它们，apt update 可能报错，software-properties-gtk 打不开，连 sudo 都可能间接出问题——因为部分 sudoers 配置会调用 Python 脚本。
这类问题往往不立刻显现，而是在某次系统升级后爆发，排查时容易误判为“系统坏了”，实际只是 dist-packages 里混进了不兼容的 wheel。
- 系统 Python 的
site-packages权限通常为 root，每次pip install都得加sudo，这本身就在鼓励危险操作 -
pip list看到的包列表里混着 apt 安装的和 pip 安装的，无法区分来源，pip uninstall可能误删系统关键包 - 不同发行版对系统 Python 的 patch 行为不同（如 Debian 加了
debian-sys-maint补丁），第三方包若调用底层 C API，可能因 ABI 不一致崩溃
venv 创建失败的常见原因和绕过方式
运行 python -m venv myenv 报错 ModuleNotFoundError: No module named 'ensurepip'，说明当前 Python 是精简编译版（常见于 Linux 发行版的 python3-minimal 包）。这不是环境配置问题，而是缺失必要模块。
解决路径很明确：不用硬扛，换一个带完整标准库的 Python。比如：
立即学习“Python免费学习笔记（深入）”；
- Ubuntu/Debian 上装
python3-venv：sudo apt install python3-venv - macOS 用
brew install python装的 Python，默认就带venv和pip - Windows 用户如果用 Microsoft Store 安装的 Python，需在安装时勾选 “Add Python to PATH” 和 “Install pip”
别试图用 virtualenv 替代——它只是对旧版 Python 的兼容方案，现代 Python 3.3+ 原生 venv 更轻量、无额外依赖，且与 pyenv、pipx 兼容性更好。
pip install --user 真的比系统安装安全吗
--user 会把包装进 ~/.local/lib/python3.x/site-packages，看似避开了系统路径，但隐患仍在：它仍是全局生效的。只要你的 PYTHONPATH 或 sys.path 包含该路径，所有用同一 Python 解释器启动的脚本都会看到这些包。
这意味着：
- 你用
--user装了个新版numpy，结果 Jupyter Notebook（系统自带）突然报ImportError: cannot import name 'multiarray'—— 因为 notebook 内核用的是系统 Python，却加载了用户目录下 ABI 不匹配的二进制扩展 -
~/.local/bin下的可执行脚本（如black、flake8）会覆盖/usr/bin同名命令，导致 cron 任务或 CI 脚本行为突变 - 没有隔离机制，
pip list --user和pip list输出混在一起，卸载时容易漏掉或误删
它适合单工具、无依赖冲突的 CLI 工具（比如 pipx install pycowsay），但绝不适合开发项目。
什么情况下可以不建虚拟环境
只有两种真实场景：一是你明确知道自己只运行一个脚本，且它只依赖标准库；二是你用 pipx 安装的是纯 CLI 工具（如 httpie、ripgrep），且从不 import 它们的模块。
其余所有情况都该用虚拟环境，哪怕只是临时试一个包：
- 新建项目第一件事不是写代码，而是
python -m venv .venv && source .venv/bin/activate（Linux/macOS）或.venv\Scripts\activate.bat（Windows） - 把
.venv加进.gitignore，但保留requirements.txt—— 这才是可复现的关键 - 不要共享
.venv目录，不同机器上重新pip install -r requirements.txt，否则二进制依赖（如torch）大概率失效
虚拟环境不是“最佳实践”，它是 Python 生态在缺乏统一包管理器前提下的生存底线。跳过它，等于把版本冲突、路径污染、调试黑洞全留给自己收尾。
