Python 后端开发：从虚拟环境、pip、requirements.txt 到项目启动

Python 开发：从虚拟环境、pip、requirements.txt 到项目启动

• • [Python 虚拟环境到底是什么](#Python 虚拟环境到底是什么)
  • [pip 和 requirements.txt 到底是什么关系](#pip 和 requirements.txt 到底是什么关系)
  • 运行脚本为什么是最后一步
  • 把整个流程串起来看
  • [从 Java 角度怎么理解](#从 Java 角度怎么理解)
  • 最后总结

很多刚从 Java 转到 Python 的同学，最容易困惑的往往不是语法，而是一个项目到底怎么跑起来。

在 Java 里，这套流程通常比较清晰：拉代码、用 Maven 下载依赖、配置项目、启动 Spring Boot。可到了 Python 项目里，常常一上来就看到这样几条命令：

python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
python app.py

或者是：

. .venv/bin/activate
python lanhu_mcp_server.py

这时候很多人都会冒出一连串问题：.venv 是什么？为什么要先 activate？pip 到底干嘛的？requirements.txt 又是什么？为什么不是直接 python app.py 就结束了？

其实，把这些概念串起来看，Python 项目的启动流程并不复杂。一个典型的 Python 后端项目，本质上就四件事：准备独立环境、安装依赖、记录依赖、启动代码。对应到你看到的这些关键词，就是虚拟环境、pip、requirements.txt 和运行脚本。

可以把它理解成这样：虚拟环境负责给项目准备一个独立的运行空间，pip 负责把第三方包装进这个空间，requirements.txt 负责记录项目需要哪些依赖，而运行脚本则是真正把程序启动起来。看懂这四者之间的关系，Python 项目怎么跑基本就通了。

Python 虚拟环境到底是什么

先说虚拟环境。它的本质，就是给当前项目单独创建一套 Python 运行空间。这样做的原因很简单：不同项目依赖的包版本可能不一样，如果大家都装在系统全局环境里，就很容易冲突。

比如一个项目可能需要较早版本的 FastAPI，另一个项目却依赖更新版本；如果全装在同一个地方，后面维护起来会很乱。所以 Python 里很常见的做法就是，每个项目一个独立环境。

通常创建方式是：

python -m venv .venv

执行后，当前目录下会生成一个 .venv 文件夹。这个目录里包含了当前项目专属的 Python、pip，以及激活脚本。你可以把它理解成这个项目自己的"小房间"，这个房间里安装什么依赖，不会影响别的项目，别的项目里的依赖也不会反过来污染它。

但仅仅创建 .venv 还不够。创建出来之后，通常还要先激活它：

source .venv/bin/activate

或者简写成：

. .venv/bin/activate

这一步的作用，是让你当前终端后续输入的 python 和 pip，优先指向 .venv 里的版本，而不是系统全局版本。也就是说，激活之后你再执行安装依赖、启动程序，实际上都是在当前项目自己的环境里进行的。

这就是为什么很多 Python 项目在运行前，都先要求你执行 activate。因为如果不先切进项目环境，后面你装包可能装错地方，运行时也可能因为 Python 版本不对或依赖没装在当前环境里而报错。

pip 和 requirements.txt 到底是什么关系

理解完虚拟环境，再来看 pip。很多初学者会混淆 python 和 pip，其实它们根本不是一回事。python 是用来运行代码的，pip 是用来安装第三方库的。

比如你想安装 FastAPI，可以写：

pip install fastapi

想安装 requests：

pip install requests

如果你已经激活了虚拟环境，那么这些包默认会被安装到 .venv 里，而不是系统全局环境。换句话说，虚拟环境负责隔离，pip 负责往这个隔离出来的空间里放东西。

不过，项目开发通常不会让你一个一个手动安装依赖，而是会提供一个 requirements.txt 文件。这个文件的作用，就是把项目需要的第三方包及其版本记录下来。例如：

fastapi==0.115.0
uvicorn==0.30.6
pydantic==2.8.2
sqlalchemy==2.0.35

有了这个文件，别人拿到项目以后，不需要猜作者电脑里装过什么，只需要执行：

pip install -r requirements.txt

就可以把项目依赖一次性装好。

所以这两者的关系其实很简单：pip 是安装工具，requirements.txt 是安装清单。

一个负责"怎么装"，一个负责"装什么"。

如果继续打比方，可以把 pip 看成采购员，把 requirements.txt 看成采购单。执行 pip install -r requirements.txt，本质上就是让采购员按清单把东西一次性配齐。

运行脚本为什么是最后一步

依赖都准备好了，最后才轮到真正启动项目。这一步通常就是：

python app.py

或者：

python main.py
python lanhu_mcp_server.py

这类命令的本质，就是让 Python 去执行某个入口文件。这个文件可能是启动一个 Web 服务，可能是启动一个 MCP Server，也可能是执行某个脚本任务。无论名字是 app.py、main.py 还是 lanhu_mcp_server.py，本质都一样：它是项目运行的起点。

这里有一个关键点，如果你前面已经激活了 .venv，那么此时命令里的 python 实际上用的是 .venv/bin/python。也就是说，运行脚本时会自动使用当前项目自己的 Python 和依赖环境。这就保证了代码运行时，能正确找到 FastAPI、SQLAlchemy、requests 这类项目依赖。

很多人会问，为什么不能直接上来就 python app.py？其实不是不能，而是前提必须满足：当前 Python 版本正确、依赖已经安装好、运行环境就是这个项目该用的环境。如果这些条件不满足，最常见的结果就是报错，例如：

ModuleNotFoundError: No module named 'fastapi'

这往往并不意味着代码有问题，而是说明环境和依赖还没准备好。所以 Python 项目的启动逻辑通常不是"上来直接运行"，而是"先环境，再依赖，最后运行"。

把整个流程串起来看

如果把前面这些概念收拢起来，一个 Python 后端项目最常见的启动流程其实就是下面这几步：

python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
python app.py

第一步创建项目专属环境，第二步切换到这个环境，第三步根据依赖清单安装项目所需的包，第四步启动项目入口文件。拿到一个新的 Python 项目时，你大多数情况下都可以先按这个思路去理解。

你前面提到过的这两条命令：

. .venv/bin/activate
python lanhu_mcp_server.py

其实就是这个完整流程的后半段。它默认省略了前置步骤：虚拟环境已经创建过了，依赖也已经装好了，所以现在只需要进入项目环境并启动服务即可。换句话说，这不是"第一次运行项目"的完整命令，而更像是"环境准备完成后的日常启动方式"。

从 Java 角度怎么理解

如果你是从 Java 后端转过来的，可以用一种更熟悉的方式去理解。

在 Java 世界里，你会有 JDK、Maven、pom.xml 和程序入口；而在 Python 世界里，对应地就会有 Python + .venv、pip、requirements.txt 和入口脚本。

当然，这不是完全一一对应，但足够帮助你快速建立认知。你可以先这么记：

• .venv 更像项目自己的运行环境
• pip 是安装依赖的工具
• requirements.txt 是依赖清单
• python app.py 是启动程序

理解了这一层，很多 Python 项目在你眼里就不再神秘了。

最后总结

一个 Python 项目的启动过程，说到底并不复杂。核心就是四件事：先创建虚拟环境隔离项目，再用 pip 按 requirements.txt 安装依赖，最后通过 Python 运行入口脚本。

用最标准的一组命令来表示，就是：

python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt
python main.py

以后你再拿到一个 Python 后端项目，无论它是普通脚本、FastAPI 服务、MCP Server，还是 AI Agent 项目，都可以先按这条线去理解。只要搞清楚环境、依赖、清单和入口文件这四者之间的关系，项目是怎么跑起来的，你基本就能看明白了。