全局包管理实为高风险操作，将系统Python解释器当作共享白板；pip install --user仅隔离安装路径，仍共享依赖导致版本冲突；conda混用pip会破坏依赖图谱；venv需手动升级pip等工具；requirements.txt须锁定所有间接依赖；Docker中应避免直接pip install，须分层构建并多阶段分离。
全局包管理不是“方便”，而是把系统 Python 的脚本解释器当成了共享白板——写错一行，整块板子都可能翘边。
pip install --user 也不能算安全
很多人以为用 --user 就能避开系统级污染，其实它只是把包装进用户目录（如 ~/.local/lib/python3.x/site-packages/），仍会和所有用同一 Python 解释器的项目共享依赖。一旦某个项目要求 requests==2.25.1，另一个项目依赖 requests>=2.30.0，pip install --user 会静默覆盖旧版本，后续运行时就可能抛出 AttributeError: 'Session' object has no attribute 'resolve_redirects' 这类 API 不兼容错误。
- 它不隔离
python可执行文件本身，无法解决不同项目需要不同 Python 版本的问题 -
PATH和PYTHONPATH仍可能被意外干扰，尤其在 shell 配置混乱时 - CI/CD 流水线中几乎无法复现，因为开发者本地环境和构建机环境不再一致
conda 环境崩溃比 pip 更隐蔽
conda 表面看是环境隔离，但若长期混用 conda install 和 pip install（尤其在同一个 conda 环境里），会破坏 conda 的依赖图谱。典型症状是：某天 import numpy 突然报 ImportError: libopenblas.so.0: cannot open shared object file，而 conda list 显示 numpy 已安装——这是因为 pip 覆盖了 conda 安装的二进制包，却没同步更新其底层 C 库链接。
- 修复方式不是
conda update --all，而是先conda activate env_name，再pip uninstall -y $(pip list --format=freeze | cut -d'=' -f1)清空 pip 包，最后conda install重装全部 - 新建环境时优先用
conda create -n myenv python=3.11，而不是conda activate base后直接装 - 避免在 conda 环境中运行
pip install -e .，除非你明确知道该包未在 conda-forge 中提供
venv 是最轻量但最容易被忽略的坑
python -m venv 创建的环境看似干净，但它默认不带 pip 升级机制。很多团队在 CI 中用 python -m venv venv && source venv/bin/activate && pip install -r requirements.txt，结果发现某些包（如 setuptools）版本太老，导致 pyproject.toml 中的构建后端解析失败，报错 ModuleNotFoundError: No module named 'build'。
立即学习“Python免费学习笔记（深入）”；
- 务必在激活后立即升级：
python -m pip install --upgrade pip setuptools wheel -
requirements.txt必须锁定所有间接依赖版本，不能只写flask，得写flask==2.3.3、werkzeug==2.3.7等——否则下次pip install -r可能拉到不兼容的新版 - Windows 上注意
venv\Scripts\activate.bat和venv\Scripts\Activate.ps1的执行策略限制，需先运行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser
Docker 容器里还用全局 pip？那是双重灾难
在 Dockerfile 里写 RUN pip install flask pandas，等于把整个容器镜像的可重现性交给了 PyPI 当天的包状态。更糟的是，如果基础镜像用了 python:3-slim，里面没有 gcc，而某个包要编译（比如 psycopg2），就会在构建阶段卡死或静默降级为纯 Python 版本，运行时报 OperationalError: could not connect to server。
- 正确做法是分层：先
RUN apt-get update && apt-get install -y build-essential（Debian系），再RUN pip wheel --no-deps --wheel-dir /wheels -r requirements.txt，最后COPYwheels 并pip install --find-links /wheels --no-index - 永远不要在容器内运行
pip install --upgrade pip，基础镜像的 pip 版本是经过测试的，升级反而可能触发pip自身的 bug（如 23.3.1 版本对 PEP 660 支持不全） - 使用
multi-stage build，把构建环境和运行环境彻底分离，避免把gcc、git等工具塞进最终镜像
真正麻烦的从来不是“怎么建环境”，而是“谁在改环境”。只要有一个脚本、一个 CI 步骤、甚至一个同事的临时调试命令绕过环境隔离直连全局 pip，整个项目的确定性就崩了一角。这点在跨团队协作或遗留系统维护中尤其致命——你永远不知道哪行 sudo pip install 被悄悄执行过。
