FastAPI入门：Python后端开发新手指南
上周五晚上十一点，我蜷在杭州出租屋的沙发上，盯着电脑屏幕上跳动的终端日志。窗外下着小雨，耳机里是老婆刚发来的语音：“你这周又不回来啊？”声音有点闷，带着点委屈。我苦笑了一下，回她：“快搞定了，这个外包项目再跑通就收工，明天一早高铁回南京。”
其实我心里清楚，这个用 FastAPI 写的接口服务还没完全调通——跨域报错、数据库连接池超时、JWT 验证偶尔崩掉……问题一堆。但我不敢说太多，怕她担心。自从去年十月被大厂“优化”之后，我和她就从同城情侣变成了周末夫妻。她在南京做产品经理，月薪15k；我在杭州接外包，收入不稳定，上个月才勉强凑够3500房租加生活费。
那会儿真的很焦虑。被裁那天HR笑眯眯地说“公司感谢你的贡献”，可走出写字楼时手都在抖。投了两个月简历，要么石沉大海，要么面到终面被告知“HC冻结”。直到某个深夜刷 GitHub，看到一个叫 fastapi-tutorial 的仓库，star 数不高，但结构清晰、注释详细。我鬼使神差地 clone 下来，跑了一遍——居然真能跑起来！
那一刻，我突然意识到：也许我不需要等别人给我发 offer，我可以自己造轮子。
FastAPI 是什么？简单说，它是 Python 世界里目前最火的现代 Web 框架之一，主打高性能、自动文档、类型提示友好。如果你写过 Flask 或 Django，会觉得它既熟悉又陌生——熟悉在于路由、中间件这些概念一脉相承，陌生在于它重度依赖 Python 3.7+ 的类型注解（type hints），还内置了 Pydantic 做数据校验。
我第一次上手时也懵了。比如这段代码：
from fastapi import FastAPI
from pydantic import BaseModel
app = FastAPI()
class Item(BaseModel):
name: str
price: float
is_offer: bool = None
@app.post("/items/")
async def create_item(item: Item):
return {"item": item}
看起来平平无奇，但神奇的是：
- 你访问
/docs，自动生成交互式 API 文档（Swagger UI） - 请求体自动校验：如果前端传个字符串当
price，直接返回 422 错误 - 所有参数类型在 IDE 里都能智能提示
这种“写即文档、错即报错”的体验，对我这种接外包的人来说简直是救命稻草——客户改需求像翻书，但只要接口定义清楚，前后端联调几乎零摩擦。
真正让我入坑的，是上个月接的一个小项目：帮一家本地电商公司做商品数据聚合。他们需要从三个竞品网站抓取价格和库存，然后提供统一查询接口。
一开始我用 requests + BeautifulSoup 写了个爬虫脚本，跑得慢不说，还老被反爬。后来一咬牙，干脆用 FastAPI 把整个流程封装成服务：
- 用
aiohttp改写异步爬虫（毕竟 FastAPI 天生支持 async/await） - 用 SQLAlchemy Core 连接 PostgreSQL 存结果
- 用 Redis 缓存热门商品，避免重复抓取
部署那天凌晨三点，我还在调试 CORS 中间件。老婆打来视频，看我黑眼圈都快掉到下巴了，叹了口气：“你这样下去身体要垮的。”我说：“再撑一下，这个项目做完能拿8k，够咱们下个月去三亚了。”她没说话，默默给我点了杯热美式外卖。
其实我知道，她担心的不是钱，是我总把自己逼太紧。但现实是，自由职业没有底薪，每个 bug 都可能意味着退款，每个延期都可能丢掉客户信任。
说到教程，网上 FastAPI 的中文资料其实不少，但质量参差不齐。很多只是照搬官方文档，或者堆砌代码片段，根本不讲“为什么这么设计”。我自己踩过几个大坑，分享出来省你时间：
坑1：别滥用 async
FastAPI 虽然支持异步，但如果你的数据库驱动还是同步的（比如普通 pymysql），那 async def 反而会拖慢性能。正确的做法是：
- 异步用
asyncpg或aiomysql - 同步操作用
loop.run_in_executor包裹 - 或者干脆全同步，FastAPI 也能跑（只是吞吐量低点）
坑2：Pydantic 模型不是万能的 我曾试图用 Pydantic 直接映射数据库 ORM 模型，结果序列化时各种字段冲突。后来学乖了：Pydantic 只用于请求/响应模型，ORM 模型单独定义。两者之间手动转换，虽然啰嗦点，但清晰可控。
坑3：不要忽视测试 外包项目时间紧，很多人跳过测试。但我现在哪怕再急，也会写最基本的 pytest 用例。比如：
def test_create_item():
response = client.post("/items/", json={"name": "foo", "price": 10.5})
assert response.status_code == 200
assert response.json()["item"]["name"] == "foo"
一次测试能省下三小时 debug 时间，血泪教训。
回到那个爬虫项目。最后交付时，客户老板亲自打电话来夸：“你们这接口文档比我们自家系统还清晰！”其实哪有什么魔法，不过是 FastAPI 自动生成的 Swagger 页面做得太好——连非技术同事都能看懂怎么调用。
更关键的是，我把整个项目开源到了 GitHub（当然脱敏了）。仓库地址就不贴了，但搜 fastapi-scraper-template 能找到类似结构。没想到两周后收到个 issue：“大佬，能不能加个定时任务示例？” 我顺手补了个 APScheduler 的集成方案，结果 star 数一夜涨了50+。
那一刻突然有点恍惚。半年前我还是个被裁员后不敢告诉老婆的loser，现在居然有人叫我“大佬”。技术这东西，有时候真的能成为普通人逆风翻盘的杠杆。
写这篇文章的时候，已经是周日晚上。我刚把行李箱塞进南京地铁，手机弹出新邮件：有个海外客户想用 FastAPI 重构他们的内部工具，预算 $3000。我深吸一口气，回复：“可以聊聊需求细节吗？”
老婆在旁边戳我：“又接活了？”
我点点头：“嗯，不过这次我想加个条件——必须允许我远程办公。”
她笑了：“那你以后是不是每周都能回来？”
我没回答，心里却有了答案。
给正在看这篇文章的你几点建议：
- 别等“准备好”再开始。我学 FastAPI 时连 asyncio 都没搞懂，边查边写，三个月后就能靠它吃饭。
- GitHub 不是秀场，是简历。哪怕只写个小爬虫 demo，只要结构清晰、有 README，就比空荡荡的简历强十倍。
- Python 的优势不是语法简单，而是生态强大。FastAPI + Pydantic + SQLAlchemy + Uvicorn，这套组合拳打下来，开发效率吊打很多 Java Spring Boot 项目。
- 外包不是长久之计，但可以是跳板。我现在接的项目越来越偏向架构设计，下一步打算做 SaaS 工具，用 FastAPI 快速验证 MVP。
最后说句实在话：技术永远救不了所有问题。异地、焦虑、收入不稳定……这些不会因为你会写 FastAPI 就消失。但至少，当你深夜面对报错日志时，能对自己说一句：“这玩意儿，我能搞定。”
这就够了。
评论 0