1. 课程导入与工程全景

在真实的 Python 后端项目里，“把代码写完”从来不是终点。一个接口在本地 python app.py 能返回 200，并不代表它能在测试环境稳定通过、能在预发环境承受并发、能在生产环境被安全回滚。测试与部署工程要解决的，正是从“能跑”到“可交付、可观测、可回退”的这段距离。本课程围绕这条主线展开：用测试保证行为正确，用部署保证交付可控，用观测保证问题可定位。

核心目标：三个可验证的工程承诺

我们可以把后端测试与部署的核心目标收敛为三句话。第一，行为可验证：接口的输入输出、边界条件、异常分支都有自动化测试覆盖，而不是依赖人工点页面。第二，交付可重复：同一份代码在开发、测试、生产环境中的构建与启动过程一致，差异只来自显式配置，而非“某台机器上装过什么”。第三，故障可定位、可回退：上线后能通过日志、指标、健康检查判断服务状态，出问题时能快速切回上一个可用版本。

这三条不是口号，它们对应着具体的工程对象。行为可验证对应测试用例、断言、覆盖率与持续集成流水线；交付可重复对应依赖锁定、容器镜像、配置注入与部署脚本；故障可定位对应结构化日志、健康检查端点、版本标记与回滚策略。后续章节会逐一展开这些对象，而本章先建立它们之间的整体关系。

典型工作流：从一次提交到一次可回退的发布

一个典型的 Python 后端交付流程可以这样描述。开发者在功能分支完成代码后提交合并请求，持续集成系统拉取代码，依次执行依赖安装、静态检查、单元测试与集成测试；测试通过后构建产物（例如 wheel 包或容器镜像），打上版本号并推送到制品库；部署阶段从制品库拉取指定版本，注入环境配置，启动服务并执行健康检查；健康检查通过后接入流量，同时记录本次发布的版本与时间；若健康检查失败或错误率超阈值，则触发回滚到上一个版本。

这条链路里有两个容易被忽视的关键点。其一是构建一次、多处部署：测试通过的产物应当就是部署到生产的产物，避免“测试环境用源码跑、生产环境重新打包”导致行为漂移。其二是健康检查要区分存活与就绪：存活检查回答“进程是否还活着”，就绪检查回答“是否已能接收流量”。把两者混为一谈，常见后果是服务还在加载依赖时就被接入流量，产生一批本可避免的 5xx。

工具链概览：按职责理解，而不是背名字

初学者常把工具链记成一串名字，结果换个项目就不知道如何选型。更稳的方式是按职责分层。测试层负责“行为是否正确”，核心对象是测试用例、断言、fixture 与测试替身；构建与依赖层负责“产物是否可复现”，核心对象是依赖锁定文件、镜像与版本标签；部署与运行层负责“服务是否按预期启动并接收流量”，核心对象是进程模型、配置注入与健康检查；持续集成与制品层负责“每次提交是否被自动验证并留下可追溯产物”；观测与回退层负责“上线后是否看得见、出问题是否退得回”。

以依赖锁定为例，如果 requirements.txt 只写 fastapi 而不锁版本，今天构建和下周构建可能拿到不同的小版本，测试通过不代表生产一致。更稳妥的做法是锁定到具体版本，并在流水线中固定 Python 版本。下面是一个最小示例，仅用于说明“锁定”这一动作的形态：

# requirements.txt（示例，版本号仅作演示）
fastapi==0.111.0
uvicorn==0.30.1
pydantic==2.7.1
httpx==0.27.0
pytest==8.2.0

再看健康检查。一个可用的就绪端点通常要检查关键依赖是否可用，而不是简单返回 200。例如应用启动后需要确认数据库连接池已建立、配置项已加载，才把就绪状态置为真。这样部署系统在滚动更新时，只有就绪的实例才会被接入流量，从而减少发布瞬间的错误。

学习路径规划：先打通一条最小闭环

面对测试与部署这两个方向，建议不要并行铺开所有工具，而是先打通一条最小闭环：为一个最小的 FastAPI 应用写一个接口测试，让它在本地通过；然后把它容器化，用环境变量注入配置；接着写一条持续集成流水线，在每次提交时自动跑测试并构建镜像；最后加上健康检查与一个版本标记，模拟一次失败发布并执行回滚。这条闭环走通之后，再逐步加深：测试侧补充边界与异常用例、引入覆盖率门禁；部署侧引入多阶段构建、灰度发布与配置校验；观测侧引入结构化日志与关键指标。