FastAPI单元测试必须用TestClient，压测必须用Locust——二者定位不同，Postman或手点无法覆盖并发、校验尖刺、异常路径等真实问题；TestClient绕过网络直接调ASGI，Locust模拟用户行为链路并需关注host、token、wait_time、阶梯加压及环境隔离。
FastAPI 的单元测试必须用 TestClient，压测必须用 Locust —— 二者定位完全不同，混用或跳过任一环节，线上崩得毫无预兆。
为什么不能只靠 Postman 或手点接口做验证
Postman 只能验证“单次请求通不通”，但无法覆盖：并发场景下数据库连接池耗尽、Pydantic 模型校验在高负载时的 CPU 尖刺、异常路径（如 404/422）是否被正确捕获并返回结构化 JSON。这些只有自动化测试能暴露。
常见错误现象包括：本地跑通所有接口，上线后 500 Internal Server Error 频发，日志里却只看到 asyncio.TimeoutError 或 ConnectionRefusedError —— 这往往不是代码 bug，而是没做过真实流量压力下的边界验证。
用 TestClient 写单元/集成测试的实操要点
TestClient 是 FastAPI 官方提供的同步 HTTP 测试客户端，它绕过网络栈，直接调用 ASGI app，速度快、可控性强，适合验证逻辑和数据流。
立即学习“Python免费学习笔记（深入）”；
- 不要在测试中启动 uvicorn：直接传
app实例给TestClient(app)，否则会引入进程、端口、异步事件循环等干扰因素 - 路径前缀要对齐真实路由：如果用了
app.include_router(router, prefix="/api")，测试时 URL 必须写成client.get("/api/items/123")，否则返回404 - 测试异常响应要显式检查：比如
response.status_code == 422且"detail" in response.json()，不能只断言response.status_code == 200 - 数据库操作必须隔离：用内存 SQLite 或 pytest 的
tmp_path创建临时 DB 文件；避免测试间共享真实 MySQL 表，否则会出现IntegrityError: UNIQUE constraint failed
示例（验证登录失败）：
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
from fastapi.testclient import TestClient
from app.main import app
<p>client = TestClient(app)</p><p>def test_login_missing_password():
response = client.post("/api/login", json={"username": "test"})
assert response.status_code == 422
assert "password" in response.json()["detail"][0]["loc"]用 Locust 做接口压测的关键配置项
Locust 不是“多开几个 requests.Session 就行”的玩具工具，它模拟的是真实用户行为链路，核心在于 TaskSet（或新版本的 SequentialTaskSet）和 wait_time 的设置是否贴合业务。
-
host必须填完整 URL（含协议和端口），比如https://api.example.com，不能只写api.example.com，否则GET请求会拼出错误地址 - 带 token 的请求，要在
on_start中登录一次并存为实例变量：self.token = response.json()["token"]，后续请求用headers={"Authorization": f"Bearer {self.token}"} -
wait_time = between(1, 3)比constant(1)更真实：真实用户不会每秒精准发请求，随机等待能避免请求脉冲打垮服务 - 阶梯加压必须用
--step-load启动参数，而不是手动改users数字：命令形如locust -f locustfile.py --step-load --step-users 50 --step-time 180
示例（关键片段）：
from locust import HttpUser, task, between
<p>class ApiUser(HttpUser):
wait_time = between(1, 3)</p><pre class='brush:python;toolbar:false;'>def on_start(self):
# 登录拿 token
with self.client.post("/api/login", json={"u": "t", "p": "123"}, catch_response=True) as resp:
if resp.status_code != 200:
resp.failure("login failed")
self.token = resp.json().get("token")
@task
def get_orders(self):
self.client.get("/api/orders", headers={"Authorization": f"Bearer {self.token}"})容易被忽略的压测准备细节
很多人跑完 Locust 报告就以为结束了，但以下三点不确认，压测结果基本无效：
- 被测服务必须关闭
debug=True和reload=True：这两项会让 uvicorn 启动多个 worker 并监听文件变化，严重干扰性能指标 - 数据库连接池大小要匹配压测并发数：比如 Locust 设了 400 用户，而 MySQL 连接池
maxconnections=10，那 90% 请求会卡在POOL.connection()等待，报出大量TimeoutError，但这不是 API 层问题 - 压测机和被测服务不能跑在同一台机器上：CPU、网络、磁盘 IO 会互相争抢，
RPS和P95 延迟数据完全失真；至少分开部署，最好用云厂商不同可用区的两台 ECS
真正决定压测价值的，从来不是脚本写了多少行，而是你有没有把 TestClient 的边界 case 覆盖全、有没有让 Locust 的请求节奏贴近真实用户、有没有把基础设施的配置瓶颈提前揪出来。
