venv本身不解决版本冲突，只提供隔离空间；真正解决靠在隔离环境中正确操作：激活环境、用python -m pip安装、同步ide解释器，并配合requirements.txt或pip-tools锁定依赖。
venv 本身不解决版本冲突，它只提供隔离空间；真正解决冲突靠的是“在隔离空间里做对的事”。
为什么激活后 still 报 ImportError 或版本错乱
常见现象是：明明 pip install requests==2.28.2 成功了，运行时却提示 No module named 'requests'，或者导入的其实是系统里装的 2.31.0 版本。根本原因只有两个：
- 没真正激活环境 ——
where python（Windows）或which python（macOS/Linux）输出路径不含.venv或venv字样，说明解释器没切过去 - 激活了但用错了 pip —— 在 PowerShell 里直接敲
pip install可能调用的是全局 pip（尤其当没升级过时），应统一用python -m pip install - IDE 没同步 —— VS Code / PyCharm 右下角 Python 解释器仍显示系统路径，必须手动选中
.venv/bin/python或.venv\Scripts\python.exe
创建和激活必须按顺序执行的三步
顺序错一步，后续所有依赖操作都可能污染全局或失效：
- 进入项目根目录后，运行
python -m venv .venv（推荐用.venv而非venv，避免误提交） - 激活：
— Windows CMD：运行.venv\Scripts\activate.bat
— Windows PowerShell：先执行Set-ExecutionPolicy RemoteSigned -Scope CurrentUser，再运行.venv\Scripts\Activate.ps1
— macOS/Linux：运行source .venv/bin/activate - 立即升级 pip：
python -m pip install --upgrade pip—— 新环境里的 pip 版本太旧会导致解析失败，比如装torch时卡在 “Could not find a version”
requirements.txt 不是万能解药，但不用它一定出问题
只靠 venv 隔离，无法保证多人协作或换机器后装出一模一样的包。关键在于怎么生成和使用 requirements.txt：
- 别直接
pip freeze > requirements.txt—— 它会把 pip、setuptools 等基础包也写进去，且无法处理传递依赖的精确版本 - 小项目可接受：激活环境后，只装你明确写的依赖，再
pip freeze > requirements.txt，然后删掉pip==、setuptools==行 - 中大型项目推荐
pip-tools：
— 先写requirements.in，只放requests、django这类顶层依赖
— 运行pip-compile requirements.in生成带哈希和完整依赖树的requirements.txt
— 部署时严格用pip install -r requirements.txt，禁止再pip freeze覆盖 -
.venv目录必须加进.gitignore，而requirements.txt（或poetry.lock）必须提交 —— 环境丢了能重建，锁文件丢了就等于丢了依赖事实
最容易被忽略的一点：venv 解决不了 C 扩展编译差异（比如 numpy 在不同机器上链接的 OpenBLAS 版本不同），也压不住 setup.py 里动态判断逻辑引发的行为偏移。这时候得靠 pyproject.toml + 构建缓存 + 显式指定构建后端来兜底。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
