项目一换电脑就跑不起来？Python 虚拟环境和依赖清单的用法

每次换一台电脑，或者把项目发给同学一起调试，Python 项目最常见的翻车现场就是：代码明明一行没动，一跑就报 ModuleNotFoundError；好不容易把包装上，又因为库的版本对不上，冒出各种奇怪的兼容问题。其实解决办法并不复杂：给每个项目一个独立的虚拟环境，再留一份随时更新的依赖清单，就能少踩很多坑。

第一：虚拟环境是给项目的「隔间」，不是可有可无的形式

Python 的包默认装在系统环境里，项目一多，版本冲突迟早找上门：这个项目要老版本，那个项目要新版本，装谁都会打破另一个。虚拟环境的作用，是给每个项目开一个独立的隔间，包只装进项目自己的目录，彼此互不干扰。

创建和进入只需要两条命令：

python3 -m venv .venv
source .venv/bin/activate   # Windows 下用 .venv\Scripts\activate

激活成功后，命令行前面会出现 (.venv) 标记，之后 pip install 装的包都只进这个环境，退出用 deactivate。两个提醒：一是 .venv 目录不要提交到 Git，它动不动就几百兆，而且和操作系统强相关，提交了也用不了；二是编辑器里记得把解释器切到 .venv 里的那个，在哪个环境装包，就用哪个环境的解释器运行，不要一半一半混着来。

第二：依赖清单要在「装完包」的那一刻顺手更新

环境建好只是第一步。项目真正能搬走的，是这份清单：

pip freeze > requirements.txt

它会把当前环境里的包连同精确版本号全部列出来。换一台机器时，只需要：

python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

环境就能原样复现出来。关键的习惯是：每装一个新包、每升级一次版本，就顺手重新生成一次清单，并且和代码一起提交进 Git。几个月之后，当你在一台新机器上三条命令把项目跑起来时，会感谢当初多敲了那一行命令的自己。

第三：两个最常见的坑

坑一：pip 明明装了，python 却说找不到。 多半是 pip 和 python 不属于同一个环境，包装到了别处。用 python -m pip install 包名 代替单独敲 pip install，能保证包装到当前解释器名下，这一个小习惯就能消掉一大半「装了却没有」的灵异事件。再用 which python 和 python -c “import sys; print(sys.executable)” 确认一下解释器路径，心里就彻底有数了。

坑二：清单里混进了一堆无关的包。 pip freeze 会列出环境里的全部包，包括你随手试装、后来又忘掉的东西。清单越干净，复现越可靠。拿不准某个包要不要留时，可以先在新环境里按清单装好、把主要功能跑一遍，缺什么再补什么，比留着一堆来历不明的包更稳妥。

小结

• 每个项目一个 .venv，环境目录不进 Git。
• 装包用 python -m pip，装完立刻更新 requirements.txt 并提交。
• 换机器时三步复现：建环境、激活、按清单安装。

环境问题最磨人的地方在于，它和代码逻辑毫无关系，却能把一下午耗光。把虚拟环境和依赖清单变成固定动作，项目就能从「在我电脑上能跑」，变成实实在在的「在哪都能跑」。