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

Python 开发从虚拟环境、pip、requirements.txt 到项目启动Python 虚拟环境到底是什么pip 和 requirements.txt 到底是什么关系运行脚本为什么是最后一步把整个流程串起来看从 Java 角度怎么理解最后总结很多刚从 Java 转到 Python 的同学最容易困惑的往往不是语法而是一个项目到底怎么跑起来。在 Java 里这套流程通常比较清晰拉代码、用 Maven 下载依赖、配置项目、启动 Spring Boot。可到了 Python 项目里常常一上来就看到这样几条命令python-mvenv .venvsource.venv/bin/activate pipinstall-rrequirements.txt python app.py或者是..venv/bin/activate python lanhu_mcp_server.py这时候很多人都会冒出一连串问题.venv是什么为什么要先 activatepip到底干嘛的requirements.txt又是什么为什么不是直接python app.py就结束了其实把这些概念串起来看Python 项目的启动流程并不复杂。一个典型的 Python 后端项目本质上就四件事准备独立环境、安装依赖、记录依赖、启动代码。对应到你看到的这些关键词就是虚拟环境、pip、requirements.txt 和运行脚本。可以把它理解成这样虚拟环境负责给项目准备一个独立的运行空间pip 负责把第三方包装进这个空间requirements.txt 负责记录项目需要哪些依赖而运行脚本则是真正把程序启动起来。看懂这四者之间的关系Python 项目怎么跑基本就通了。Python 虚拟环境到底是什么先说虚拟环境。它的本质就是给当前项目单独创建一套 Python 运行空间。这样做的原因很简单不同项目依赖的包版本可能不一样如果大家都装在系统全局环境里就很容易冲突。比如一个项目可能需要较早版本的 FastAPI另一个项目却依赖更新版本如果全装在同一个地方后面维护起来会很乱。所以 Python 里很常见的做法就是每个项目一个独立环境。通常创建方式是python-mvenv .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可以写pipinstallfastapi想安装 requestspipinstallrequests如果你已经激活了虚拟环境那么这些包默认会被安装到.venv里而不是系统全局环境。换句话说虚拟环境负责隔离pip 负责往这个隔离出来的空间里放东西。不过项目开发通常不会让你一个一个手动安装依赖而是会提供一个requirements.txt文件。这个文件的作用就是把项目需要的第三方包及其版本记录下来。例如fastapi0.115.0 uvicorn0.30.6 pydantic2.8.2 sqlalchemy2.0.35有了这个文件别人拿到项目以后不需要猜作者电脑里装过什么只需要执行pipinstall-rrequirements.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 namedfastapi这往往并不意味着代码有问题而是说明环境和依赖还没准备好。所以 Python 项目的启动逻辑通常不是“上来直接运行”而是“先环境再依赖最后运行”。把整个流程串起来看如果把前面这些概念收拢起来一个 Python 后端项目最常见的启动流程其实就是下面这几步python-mvenv .venvsource.venv/bin/activate pipinstall-rrequirements.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-mvenv .venvsource.venv/bin/activate pipinstall-rrequirements.txt python main.py以后你再拿到一个 Python 后端项目无论它是普通脚本、FastAPI 服务、MCP Server还是 AI Agent 项目都可以先按这条线去理解。只要搞清楚环境、依赖、清单和入口文件这四者之间的关系项目是怎么跑起来的你基本就能看明白了。