根本不用配置全局环境——每个项目应配独立虚拟环境并锁定依赖版本。用 python -m venv .venv 创建隔离环境，激活后 pip install 仅影响当前项目；再通过 pip-tools 编译 requirements.in 生成带哈希的 requirements.txt 并提交 Git，确保环境可重现。
根本不用配置全局环境——配置它只会让问题更糟。
为什么全局环境注定是冲突源头
Python 全局环境只有一个 site-packages 目录，所有 pip install 都往里写。只要两个项目对同一包有不同版本要求（比如 requests==2.25.0 和 requests==2.31.0），就必然有一个报 ImportError 或 AttributeError。这不是配置能解决的问题，而是设计上就不该共享。
- 系统级 Python（如
/usr/bin/python3）是操作系统依赖的一部分，动它可能破坏系统工具 - 即使你用
pip install --user，也只是换了个用户级全局路径，仍无法隔离项目 - 任何“统一全局版本”的尝试，都会在团队协作或 CI/CD 中立刻失效——别人机器上不是你的环境
真正该做的：每个项目配独立虚拟环境
用 Python 自带的 venv，三步到位，零额外依赖：
- 进项目根目录，运行
python -m venv .venv（名称可自定义，但.venv是 IDE 通用识别名） - 激活：
source .venv/bin/activate（macOS/Linux）或.venv\Scripts\activate（Windows CMD） - 确认生效：
which python（macOS/Linux）或where python（Windows）必须输出.venv路径内的解释器
激活后 pip install 所有包都只存在这个项目里，删掉整个 .venv 文件夹就干净清空，不残留、不污染。
立即学习“Python免费学习笔记（深入）”；
激活后还装到全局？检查这三处
这是最常被忽略的实操断点，不是命令不对，而是上下文没切换成功：
- PowerShell 用户必须先执行
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser，否则.venv\Scripts\Activate.ps1被策略拦截，看似执行了实则没生效 - VS Code 编辑器右下角显示的 Python 解释器路径，和终端里
which python的结果可能不一致——必须手动点击选择.venv/bin/python或.venv\Scripts\python.exe - IDE 启动的调试器或终端，有时会继承父进程的 PATH，导致即使你激活了，
python命令仍调用系统默认版本；重启 IDE 或新开终端窗口再试
依赖版本漂移比冲突更隐蔽
只靠 venv 隔离还不够。今天 pip install requests 装的是 2.31.0，明天可能变成 2.32.0，而某个库只兼容 2.31.x。所以必须锁定：
- 开发时用
pip install pip-tools，然后写requirements.in（只列顶层依赖，如requests、django） - 运行
pip-compile requirements.in生成requirements.txt，里面含精确版本号和哈希值 -
requirements.txt必须提交进 Git——它才是你项目依赖的唯一事实来源，不是pip list的当前快照
真正的痛点从来不在“怎么装”，而在“装完怎么确保下次一模一样”。环境可以重建，锁文件不能丢。
