Python 虚拟环境排错：先确认解释器，再检查依赖
pip 提示安装成功，程序却说找不到模块，很多时候不是包消失了，而是安装和运行使用了不同的 Python。虚拟环境的价值是为项目建立独立依赖目录，但它不会替你决定 IDE、终端、计划任务到底调用哪个解释器。本文先用 Linux 或 macOS 演示，再补充 Windows 的路径差异。
AI生成概念配图：不同项目的依赖被放入各自独立的环境，仅辅助理解，不代表真实界面或实测结果。
用明确路径创建和运行
python3 -m venv .venv .venv/bin/python -m pip --version .venv/bin/python -m pip install -r requirements.txt .venv/bin/python app.py
这里假定项目已有经过审查的 requirements.txt 和 app.py。将 pip 作为所选解释器的模块运行，比单独敲 pip 更容易确认安装目标。若系统提示缺少 venv 支持，应按发行版官方说明补齐对应组件，不要用 sudo pip 把项目依赖塞进系统 Python。依赖安装本身会执行包相关代码，来源与版本仍需要信任。
Windows 通常使用 py -m venv .venv 创建环境，运行路径改为 .venv\Scripts\python.exe。使用完整路径时不需要激活脚本，因此也无需为了运行项目随意修改 PowerShell 的执行策略。不同平台生成的环境不能直接当作可移植压缩包互换。
用一组检查解决“装了却不能导入”
.venv/bin/python -c "import sys; print(sys.executable); print(sys.prefix); print(sys.base_prefix)" .venv/bin/python -m pip --version .venv/bin/python -m pip list .venv/bin/python -m pip check
先看 sys.executable 是否指向预期环境，再看 pip 报告的安装位置。对普通 venv，sys.prefix 与 sys.base_prefix 不同可用来判断解释器是否处于虚拟环境。pip check 检查已安装依赖之间的声明兼容性，但它不会验证应用逻辑，也不会发现所有动态导入错误。检查完成后仍需运行测试或最小导入用例。
如果终端正常而 IDE 失败，应在 IDE 中选择同一个解释器；如果手动执行正常、服务失败，就检查服务命令与工作目录。还有一种容易忽略的情况：项目中有 json.py、typing.py 或与第三方包同名的文件，遮住了本应导入的模块。应查看异常栈中的实际文件路径，再决定是否重装依赖。
激活只是便利，不是隔离开关
source .venv/bin/activate 主要调整当前 shell 的 PATH，让 python 等命令优先指向环境。它不会改变已经启动的进程，也不会自动影响另一个终端。部署脚本、定时任务与 CI 使用明确解释器路径，通常比依赖“之前激活过”更容易复现。虚拟环境也不是安全沙箱，不能因此运行来源不明的代码。
把环境当作可重建产物
.venv/bin/python -m pip freeze > requirements.snapshot.txt # 在新的验证目录或环境中重建后，再运行项目测试 python3 -m venv .venv-verify .venv-verify/bin/python -m pip install -r requirements.snapshot.txt
pip freeze 记录当前安装情况，不会替你计算完整的跨平台锁定方案，也不等于构建已经可重复。还要记录 Python 版本、操作系统与架构，并关注本地路径、可编辑安装、私有源和系统库等条件。快照文件应检查后再提交，避免无意公开本地目录或私有仓库信息。
不要把 .venv 放进 Git，也不要移动目录后指望所有脚本仍可运行，因为环境中的入口脚本可能保存绝对解释器路径。项目迁移时重新创建环境、安装依赖并执行测试，通常比修补旧环境更清楚。最终要保存的是重建方法和验证证据，而不是一份只在当前电脑上能用的目录。
