本文讲解如何让 Python 子进程真正生效地运行于目标虚拟环境中，指出仅设置 VIRTUAL_ENV 环境变量不足以激活依赖，推荐通过直接调用虚拟环境中的 Python 解释器来可靠执行脚本。
本文讲解如何让 python 子进程真正生效地运行于目标虚拟环境中，指出仅设置 `virtual_env` 环境变量不足以激活依赖，推荐通过直接调用虚拟环境中的 python 解释器来可靠执行脚本。
在 Python 中通过 subprocess 启动外部程序时，常误以为只需修改 VIRTUAL_ENV 环境变量即可“切换”到目标虚拟环境。但事实是：VIRTUAL_ENV 仅是一个提示性变量，Python 解释器本身并不会因该变量改变而自动加载对应 site-packages 或修改 sys.path。因此，即使你正确设置了 env["VIRTUAL_ENV"] = "/path/to/venv"，子进程若仍调用系统默认 Python（如 /usr/bin/python3），它根本不会感知或使用该虚拟环境中的包——这正是 ModuleNotFoundError: No module named 'wx' 的根本原因。
✅ 正确做法是：绕过环境变量欺骗，直接调用目标虚拟环境中的 Python 可执行文件。例如，若你的虚拟环境位于 ~/.pyenv/versions/wx，其 Python 解释器路径为 ~/.pyenv/versions/wx/bin/python。此时应显式构造命令：
import subprocess
from pathlib import Path
venv_python = Path.home() / ".pyenv/versions/wx/bin/python"
script_path = "scripts/foo.py" # 注意：这里应为 .py 脚本，而非 shell 包装器
result = subprocess.run([str(venv_python), script_path],
capture_output=True, text=True)
if result.returncode != 0:
print("Error:", result.stderr)
else:
print("Output:", result.stdout)
⚠️ 注意事项：
- 若原 scripts/foo 是 Bash 脚本（如 #!/bin/bash 开头且内部调用 python foo.py），请优先将其逻辑重构为纯 Python 脚本，或在子进程中明确用 venv_python 执行其核心 Python 文件；
- 不要依赖 activate 脚本或 source 命令——它们仅对当前 shell 有效，无法透传至 subprocess；
- 使用 os.environ.copy() 并修改 VIRTUAL_ENV 对 pip 或某些工具链可能有辅助作用，但对 Python 解释器加载模块无实质影响；
- 若必须保留 Bash 包装器，请确保其内部显式调用 $VIRTUAL_ENV/bin/python（但此方式耦合度高，不推荐）。
总结：环境变量不是魔法开关，执行上下文由实际调用的二进制文件决定。要确保子进程使用特定虚拟环境，唯一可靠的方式是直接调用该环境下的 python 解释器——清晰、可控、符合 Python 运行时机制。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
