Python课程设计-Windows 下别再复制 venv 文件夹了!用 requirements.txt 迁移

一、你在 Windows 上遇到的典型“翻车”场景

场景 1： 在实验室电脑上，项目路径为 D:\GraduationProject，虚拟环境是 D:\GraduationProject\venv。你把整个文件夹复制到笔记本的 C:\StudentWork\GraduationProject，然后用 命令提示符（cmd） 激活：

场景 2（最离谱）： 你把这个复制后的文件夹拷回实验室电脑的原位置，居然也报错了，原来能跑的环境彻底“坏掉”。

所有这些问题的根源都是一样的：Windows 下的 venv 内部使用了绝对路径，并且这些路径在文件夹被移动或复制后不会自动更新。

二、深入底层：为什么 Windows 下的 venv 不可移动？

Python 官方文档明确指出：虚拟环境是不可移动、不可复制的。 在 Windows 上，这个限制尤其严格，原因有三：

1. 激活脚本中“写死”了原始路径

打开 venv\Scripts\activate.bat（用于 cmd），你会看到：

set "VIRTUAL_ENV=D:\GraduationProject\venv"

当你把文件夹移动到 C:\StudentWork 后，激活脚本仍然会去 D:\GraduationProject 找环境。于是：

• 环境变量指向了错误的路径

• pip 和 python 可执行文件会依据这个错误路径去加载库，自然什么都找不到

2. pip 和 python 的可执行文件内嵌了绝对路径

Windows 下的 venv\Scripts\pip.exe 和 venv\Scripts\python.exe 并不是普通的 EXE，它们是 Python 启动器（py.exe）的包装。这些二进制文件内部保存了原始 Python 解释器的完整路径。当你移动文件夹后，它们仍然尝试去原路径找 python.dll 和 site-packages，失败后就会直接报错：

Fatal error in launcher: Unable to create process using '"D:\GraduationProject\venv\Scripts\python.exe" ...'

3. pyvenv.cfg 中的 home 指向了原解释器

在虚拟环境根目录下有一个 pyvenv.cfg 文件，内容类似：

home = C:\Python39version = 3.9.13include-system-site-packages = false

其中 home 字段记录了创建这个虚拟环境时使用的基础 Python 安装目录。当你换到另一台电脑，那台电脑的 Python 很可能装在 C:\Python39 吗？不一定，甚至可能根本没装 Python 3.9。于是虚拟环境彻底失效。

总结：Windows 下的 venv 是一个“硬链接”式的快照，而不是一个独立容器。

你无法通过简单的文件复制来迁移它——就像你不能把一棵栽在土里的树连根拔起后，插到另一个花盆里还指望它立刻成活。

三、正确的迁移方法（标准做法）

Python 社区为了解决这个问题，已经给出了成熟的方案：只迁移依赖清单 requirements.txt，在新机器上重新构建虚拟环境。

第 1 步：在原电脑上导出依赖列表

假设你的项目已经在实验室电脑上跑通，并且虚拟环境（venv）已激活。打开 命令提示符（cmd），进入项目目录，执行：

pip freeze > requirements.txt

numpy==1.24.3pandas==2.0.2requests==2.31.0

第 2 步：把 requirements.txt 和代码拷到新电脑（不要拷 venv 文件夹）

第 3 步：在新电脑重建环境（cmd 执行）

1. 下面指令分别为新建虚拟环境，激活，在虚拟环境下安装依赖。

2. 也可只执行3，则直接在系统Python环境下安装。

python -m venv venv  venv\Scripts\activate.batpip install -r requirements.txt