python项目必须用venv，否则全局pip必然导致版本冲突；venv通过独立site-packages实现彻底隔离，激活后which python和pip才指向虚拟环境路径，且默认不继承系统包以保障可复现性。
venv 能彻底隔离依赖，全局 pip 必然导致版本冲突
Python 项目必须用 venv，这不是“推荐”，而是避免运行时崩溃的底线。比如项目 A 需要 requests==2.25.0，项目 B 需要 requests==2.30.0，在全局环境里执行两次 pip install，后一次会直接覆盖前一次——项目 A 再运行就报 AttributeError 或 ImportError。而 venv 创建的是完全独立的 site-packages 目录，两个环境里的 requests 互不看见。
激活后 which python 和 pip install 才真正生效
没激活虚拟环境时，python -m pip install xxx 依然走的是系统 Python 的 pip，装进全局 site-packages。只有执行了激活命令，PATH 才被重排：
- Linux/macOS：
source venv/bin/activate - Windows cmd：
venv\Scripts\activate - Windows PowerShell：
venv\Scripts\Activate.ps1（需先执行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser）
激活后终端提示符出现 (venv)，此时 which python 指向 venv/bin/python，pip install 写入的路径才是 venv/lib/python3.x/site-packages/。
venv 不继承系统包是默认行为，别乱加 --system-site-packages
新建的 venv 默认配置 include-system-site-packages = false（见 venv/pyvenv.cfg），这意味着哪怕系统已装 flask，新环境里 import flask 仍会报 ModuleNotFoundError。这是设计使然——干净隔离才能保证可复现性。加 --system-site-packages 是特例，仅用于调试或嵌入式受限场景，日常开发中几乎不用，否则等于半途放弃隔离。
删 venv/ 目录前必须 deactivate，且别提交到 Git
venv/ 是纯生成物，体积大、平台相关、不可跨机器复制。常见误操作：
- 没
deactivate就直接rm -rf venv，后续 shell 还在调用已删除路径下的python，可能 fallback 到系统 Python 或报错 - Windows 上用 PowerShell 激活过，删完重建同名环境时，旧的
activate.ps1签名残留会导致新环境无法激活，需手动删掉再重建 - 把
venv/提交进 Git，不仅浪费空间，还让协作者拉取后无法直接使用——正确做法是只提交requirements.txt，用pip install -r requirements.txt重建
真正容易被忽略的是：venv 只隔离 Python 包，不解决 C 扩展 ABI 兼容性、Python 小版本（3.9/3.10/3.11）匹配、或系统级库（如 libpng、CUDA）冲突。如果项目用了 torch 或 tensorflow，光靠 venv 不够，还得确认解释器版本和底层依赖是否一致。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
