python项目必须用虚拟环境以避免依赖冲突，venv默认不继承系统包实现干净隔离，激活后path优先指向虚拟环境路径确保pip安装仅作用于当前项目。
Python项目必须用虚拟环境，否则依赖冲突几乎是必然的。这不是“建议”，而是实际协作和部署中踩过坑后的硬性实践——系统级 pip install 会把包装进全局 site-packages，一旦两个项目需要同一库的不同版本（比如 requests==2.25.0 和 requests==2.28.1），其中一个必崩。
venv 创建时为什么默认不继承系统包？
因为 venv 的设计目标就是“干净隔离”。它默认不带 --system-site-packages 参数，生成的 site-packages 是空的（只含 pip、setuptools 等基础工具）。这样能确保：你 pip install 的每个包都明确属于当前项目，不会偷偷从系统里拉一个旧版 numpy 导致行为不一致。
- 加
--system-site-packages是特例，仅适用于临时调试或嵌入式受限环境，日常开发中几乎不用 - 哪怕系统已装了
flask，新venv激活后运行import flask仍会报ModuleNotFoundError - 目录下
pyvenv.cfg文件里的include-system-site-packages = false就是这个行为的配置依据
激活后为什么 which python 和 which pip 指向的是 venv 内路径？
激活脚本（source venv/bin/activate 或 venv\Scripts\activate.bat）本质是修改了 PATH 环境变量，把虚拟环境的 bin/（或 Scripts/）放在最前面。所以：
-
python执行的是venv/bin/python（Linux/macOS）或venv\Scripts\python.exe（Windows） -
pip安装的包只会写入venv/lib/python3.x/site-packages/，和系统/usr/lib/python3.x/site-packages/完全无关 - 没激活时运行
python -m pip install xxx，如果没加-m venv，就还是在装全局包——这是新手最常误操作的地方
为什么不能直接删掉 venv/ 目录就完事？
可以删，但要注意两点：
- 删除前必须先
deactivate，否则 shell 还在用已不存在的bin/下的命令，后续执行python可能报错或 fallback 到系统 Python - Windows 上若用 PowerShell 激活过，删完再建同名环境时，旧的
activate.ps1签名可能残留，导致新环境无法激活（需手动删venv\Scripts\activate.ps1并重新生成） - 别把
venv/提交到 Git——它体积大、平台相关、可重生成；应把requirements.txt当作唯一可信依赖声明
真正容易被忽略的是：虚拟环境不是“一劳永逸”的保险箱。它只隔离包，不隔离 C 扩展兼容性、Python 解释器 ABI、甚至操作系统级依赖（如 libpng 版本）。如果你的项目用了 torch 或 tensorflow，光靠 venv 不够，还得确认 Python 小版本（3.9/3.10/3.11）和构建时链接的系统库是否匹配——这时候 venv 是起点，不是终点。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
