venv创建时指定Python版本的关键是传入可执行文件路径，因其不支持版本号参数；需用which/where查路径后显式指定，如python3.9 -m venv myenv，并验证sys.executable与python -V一致。
venv 创建时指定 Python 版本的关键是传入 python 可执行文件路径
Python 自带的 venv 模块本身不支持类似 --python 3.9 这样的版本号参数，它只认具体的解释器路径。所以“指定版本”本质上是告诉 venv 去用哪个已安装的 python 二进制文件来初始化环境。
常见错误是直接运行 python -m venv myenv --python=3.9 或 python3.9 -m venv myenv（后者在某些系统上会失败），结果报错 invalid option 或找不到模块。
- 正确做法：先确认目标 Python 版本的可执行文件存在且可调用，例如
which python3.9（Linux/macOS）或where python39.exe（Windows） - 然后显式传入完整路径：
python3.9 -m venv myenv（推荐，最简）或/usr/bin/python3.9 -m venv myenv - 如果系统中只有
python3.9但没加到$PATH，就得写绝对路径；macOS 使用 pyenv 时，路径通常是~/.pyenv/versions/3.9.18/bin/python - Windows 用户注意：不要用
py -3.9启动venv，因为py启动器不保证把-m venv正确透传给目标解释器，应直接用py -3.9 -m venv myenv（py是 Windows 官方启动器，支持该语法）
验证新环境是否真的用了指定版本
创建完别急着用，得确认 python 指向的是你想要的那个版本，否则后续装包、运行都可能出问题。
- 激活环境：
source myenv/bin/activate（Linux/macOS）或myenv\Scripts\activate（Windows） - 检查解释器路径：
which python或where python，看输出是否包含3.9或对应版本号 - 运行
python -V和python -c "import sys; print(sys.executable)"，二者必须一致且指向你当初指定的解释器 - 特别注意：如果激活后
python -V显示的是系统默认版本（比如 3.8），说明创建时根本没生效——大概率是命令写错了，或者python3.9命令根本不存在
为什么不用 virtualenv 或 pipenv？
venv 是标准库模块，轻量、无额外依赖，适合 CI/CD 或明确控制 Python 版本的场景。而 virtualenv 虽支持 -p python3.9 这种更直观的写法，但它需要 pip 单独安装，且底层仍依赖系统中真实存在的解释器路径——它只是帮你做了查找封装，并未绕过“必须有那个 python 二进制”的前提。
立即学习“Python免费学习笔记（深入）”；
-
pipenv和poetry更进一步，能自动下载并管理多个 Python 版本（通过pyenv集成），但它们引入了额外抽象层，调试时容易混淆“谁在调用谁” - 如果你只需要一个干净、确定版本的环境，
venv+ 显式路径是最可控的方式 - CI 脚本里尤其推荐用绝对路径，避免因
$PATH差异导致环境错乱
Windows 上 py.exe 启动器的坑
Windows 用户常以为 py -3.9 -m venv myenv 和 python39 -m venv myenv 等价，但实际行为有细微差别：
-
py -3.9会查找注册表或py.ini中配置的 Python 3.9 安装位置，再调用其python.exe；而python39是一个独立的可执行文件名，不一定存在 - 如果机器上装了多个 3.9.x 小版本（如 3.9.7 和 3.9.18），
py -3.9默认选最新者，但py -3.9.18才能精确锁定 - 建议在脚本中统一用
py -3.9 -m venv myenv，并在文档里注明需安装对应版本的 Python for Windows（带py启动器）
venv 不支持版本指定，而是你敲的 python3.9 根本没装，或者装了但不在 $PATH 里——这时候 venv 会静默 fallback 到当前 shell 的 python，而你完全不知道。 
