本文介绍通过直接调用虚拟环境中的 Python 解释器来运行子进程，替代简单设置 VIRTUAL_ENV 环境变量的方式，从而可靠地加载对应环境的第三方包（如 wx），避免 ModuleNotFoundError。
本文介绍通过直接调用虚拟环境中的 python 解释器来运行子进程，替代简单设置 `virtual_env` 环境变量的方式，从而可靠地加载对应环境的第三方包（如 `wx`），避免 `modulenotfounderror`。
在 Python 中通过 subprocess 调用外部脚本时，仅设置 VIRTUAL_ENV 环境变量并不能真正激活虚拟环境。原因在于：VIRTUAL_ENV 本身只是一个标识路径的变量，Python 解释器并不会自动据此修改 sys.path 或切换依赖包；实际的包加载依赖于当前执行的 Python 可执行文件路径（即 sys.executable）。若子进程仍调用系统默认 Python 或未关联该虚拟环境的解释器，即使 VIRTUAL_ENV 设置正确，import wx 等操作依然会失败。
✅ 正确做法是：绕过环境变量模拟，直接调用目标虚拟环境中 bin/python（Linux/macOS）或 Scripts/python.exe（Windows）来执行脚本。这确保了 Python 运行时完全基于该虚拟环境的 site-packages 和配置。
以下为推荐实现方式（以 Linux/macOS 为例）：
import subprocess
from pathlib import Path
# 指向目标虚拟环境的 Python 解释器
venv_python = Path.home() / ".pyenv/versions/wx/bin/python"
script_path = Path("scripts/foo.py") # 注意：应为 .py 文件，而非 shell 脚本
# 直接调用虚拟环境中的 Python 执行脚本
result = subprocess.run(
[str(venv_python), str(script_path)],
capture_output=True,
text=True,
check=False # 可根据需要设为 True 并捕获异常
)
if result.returncode != 0:
print("Error output:", result.stderr)
else:
print("Success:", result.stdout)
? 关键注意事项：
- 不要依赖 VIRTUAL_ENV + os.environ.copy()：该方式对 subprocess.run() 无效，除非被调用的脚本显式读取该变量并手动 source 激活（不推荐且不可靠）；
- 确保路径正确：venv_python 必须指向真实存在的可执行文件（可通过 ls -l ~/.pyenv/versions/wx/bin/python 验证）；
- 脚本类型需匹配：若原 foo 是 Bash 脚本（含 #!/usr/bin/env python），请将其核心逻辑迁移到 .py 文件中，或改用 subprocess.run([venv_bin_dir / "python", ...]) 显式调用；
- Windows 用户注意路径：应使用 Path(".../Scripts/python.exe")，且建议统一用 str() 转换路径以兼容 subprocess；
- 权限与依赖：确保目标虚拟环境中已安装所需包（如 pip install wxpython），可通过 subprocess.run([str(venv_python), "-m", "pip", "list"]) 验证。
总结：激活虚拟环境的本质是使用其专属 Python 解释器，而非“欺骗”环境变量。这一原则适用于 pyenv、venv、conda 等所有主流环境管理工具。坚持“用哪个环境，就调用哪个环境的 python”，可彻底规避模块导入失败问题。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
