Python 虚拟环境入门：解决装了包却无法导入的问题

运行一个脚本时提示缺少模块，执行安装后依然报错，常见原因是电脑上有多个 Python：终端安装到了一个解释器，编辑器却使用另一个。解决问题的第一步不是反复安装，而是确认“谁在运行、包在哪里”。

本文面向已经安装 Python 3 的桌面电脑。命令为操作示例，未在读者设备上执行；只对自己信任的项目和软件包使用。虚拟环境隔离的是依赖，不是恶意代码的安全沙箱。

先给每个项目一个独立环境

在一个新建的项目目录中创建 .venv。Windows 可使用已安装的 Python 启动器，macOS 与 Linux 通常使用 python3：

# Windows
py -m venv .venv

# macOS / Linux
python3 -m venv .venv

以上是两套替代命令，不必全部运行。若 py 不存在，先检查安装方式，不要下载来源不明的修复脚本。部分 Linux 发行版把 venv 支持单独打包，应按该发行版官方说明补齐。

环境内有解释器和依赖目录，但你的脚本应放在项目目录中，不能放进 .venv。环境损坏时可以重建，业务代码却不能跟着被清理。Python venv 文档

不激活，也能准确运行

激活环境主要是让终端更方便地找到解释器，并非必需条件。下面的明确路径更适合排查混用问题：

# Windows PowerShell
.\.venv\Scripts\python.exe -c "import sys; print(sys.executable)"
.\.venv\Scripts\python.exe -m pip --version

# macOS / Linux
./.venv/bin/python -c "import sys; print(sys.executable)"
./.venv/bin/python -m pip --version

检查输出路径是否位于当前项目的 .venv。如果编辑器运行结果不同，在编辑器里选择同一个解释器，再重新启动它的运行终端。不要仅凭终端前面出现了环境名称就认定配置正确。

这也避免了 PowerShell 激活脚本被执行策略拦截时，初学者为了赶进度关闭系统限制。直接运行环境内的解释器即可，不必为本教程修改安全设置。

让安装动作和运行位置一致

使用 python -m pip 的思路，是让指定的 Python 调用自己的 pip。项目已有经过审查的依赖文件时，可在确认来源后使用环境解释器运行：

# Windows
.\.venv\Scripts\python.exe -m pip install -r requirements.txt

# macOS / Linux
./.venv/bin/python -m pip install -r requirements.txt

依赖文件不是安全证明。检查包名、版本和下载来源，尤其留意近似拼写的包。不要用管理员权限安装来掩盖路径错误，也不要为了运行普通项目去覆盖操作系统管理的 Python 包。

保存重建线索，而不是复制环境目录

迁移项目时保留源码、依赖清单、Python 版本以及启动说明；在新电脑重新创建环境。可以先把 python -m pip freeze 的输出作为现状记录，但它可能包含间接依赖或本地路径，并不自动构成跨平台可复现的锁文件。PyPA 环境与依赖指南

建议在项目说明中写清：使用哪个 Python 系列、如何创建环境、如何安装已审核依赖、怎样运行一个最小功能检查。不要把 .venv 提交进 Git，也不要把凭证写进依赖文件。

完成后的三个检查

终端与编辑器打印出的解释器路径一致。
pip --version 指向该项目环境，所需模块可以被同一解释器导入。
在另一空目录按说明重建后，最小示例仍能运行。

做到这三点，再去排查程序自身的配置和逻辑。环境明确以后，“装了却找不到”的问题通常会变成一个可以定位的路径差异，而不是碰运气地重装。

延伸阅读

整理项目提交时，可接着阅读Git 暂存与提交检查流程。