曾经的我，把数据库当成了魔法盒子。
教程都千篇一律：先创建个 engine，再搞个 session factory，然后写个依赖把 session yield 出去。用起来没毛病，于是我就到处复制粘贴。但为啥要这么做？其实我也没搞明白。
直到有一天，轮到我写后台任务（background worker），这些套路突然就“不灵光”了。我盯着自己的代码，脑袋一片浆糊：
- 为啥数据库 engine 要一直留在内存里不放？
- 为啥每个请求都得新建 session？
- 既然 API 要“无状态”，我们还保存啥东西啊？
- S3 算无状态还是有状态？Redis 又算啥？
总感觉哪儿不对劲。
那个挥之不去的矛盾
大家都说：“API 就得无状态！”
但现实中的后端，总有点啥东西是要保留住的：
- 数据库 engine 一跑就常驻内存
- Session factory 藏 app 状态里
- S3 客户端塞在 context 里
- Redis 连接全局共享
这到底是无状态，还是有状态？
很长一段时间，我的脑子就把这归为：“反正大家都这么写。” 其实就是：“虽然我没懂，但用了也没出啥大问题，先不管。”
一张图，理清一切
后来，我终于找到了让一切豁然开朗的心智模型。
想象一下，你的系统被一条横线切成两半：
横线以上：请求处理器和后台任务
- 表现得很“无状态”
- 每次请求都是全新的一轮工作
- 不会偷偷带着上次的数据过来
横线以下：数据持久化世界
- Postgres 的表和行
- S3 的桶和对象
- Redis 的键值对
- 这些地方，才是真正的“状态长存”
横线上：连接两个世界的“桥梁”——客户端对象
- 数据库 engine 和它的连接池
- S3 客户端以及配置
- Redis 客户端和连接管理
- 它们是你无状态代码和有状态世界之间的桥梁
一旦按这张图理解，所有迷雾都消散了。
你的代码并没有“耍赖”，只是合理地维护了访问有状态世界的通道。
为什么数据库看起来“格外隆重”？
说实话，数据库的“仪式感”明显比 S3、Redis 这种服务高多了。这事儿其实有原因。
连接池，绝对不能马虎
把数据库想象成一家只有 100 个餐桌的餐厅。
如果每个顾客（请求）都自己扛一张桌子进来还不带走，分分钟桌子堆满餐厅。更惨的是，20 个服务员（worker），每人每秒再带 10 张桌子……餐厅直接变桌子批发市场。
正确姿势是这样的：
- 餐厅自带一波桌子（连接池/engine）
- 顾客吃完就撤，桌子轮着用
- 下一个顾客直接坐现成的桌子
代码里也是：
- 每个进程一个 engine，内部管理连接池
- 每个请求从池子里借一根连接
- 请求完活儿，连接还回池子
这不是写法风格，这是“活命法则”。
事务，得有自己的“小黑屋”
数据库的 session 不只是连接，更是“事务边界”。
想象 session 是你专用的小本本，想改啥就先写上。最后决定“提交”，就把本本交上去；要是“反悔”，直接撕掉。
如果把本本给所有人轮流写，A 以为刚下好订单，B 又觉得刚取消了，最后数据库懵圈：你们到底想干嘛？
所以 session 必须一请求一份，专人专用，开始到结束都干净利落。
S3 又是个啥角色？
S3 的存在感有点特殊，和数据库不太一样。
S3 也保存数据啊，今天传个文件，明天还能下回来，妥妥的有状态。
但关键区别在于：你和 S3 是通过 HTTP 打交道的。每次上传、下载，都是独立的一锤子买卖。没有“事务”什么的，没有哪个本本帮你记着还没提交的改动。
拿个生活例子：
- 数据库：你进档案室，手里拿着本子修修改改，写完决定存档还是作废。
- S3：你寄快递，每次都是独立一件，快递公司不会帮你记着上次的内容。
虽然 S3 也有“状态”，但数据库因为连接和事务的存在，需要更多的“仪式感”。
“无状态”到底是啥意思？
谜底揭晓时刻到了。
大家说“无状态 API”，其实不是说你啥都不能放内存里。
真正的意思是：每个请求都不依赖于上一个请求的“隐形”状态。
也就是说：
- ❌ 别让数据库 session 跨请求存活
- ❌ 别把“当前用户”写进全局变量
- ❌ 别靠某个会变的全局对象来传递数据
- ✅ 可以共享 engine、客户端、配置等基础设施
- ✅ 每个请求新建 session 或 context
- ✅ 状态的读写交给数据库、缓存、存储等外部系统
共享对象只是“工具”，真正的业务状态应该留在分界线下。
背景任务里，分界线最关键
这些理论，等你写后台 worker 的时候才会真切体会。
用 Web 框架时，框架会帮你把 session 的创建和销毁都打点得妥妥的。你只管写业务逻辑就行。
但一旦到后台 worker，轮到你自己决定：
- 什么东西是整个 worker 共享的？
- 什么东西是每个任务独立新建的？
这就是分界线的选择题。
一个干净的套路如下：
# worker 初始化时（长生命周期）
context["db_session_factory"] = SessionFactory(engine)
context["s3_client"] = S3Client(config)
# 每个任务中（短生命周期）
async def process_document(context, document_id):
session = context["db_session_factory"].create()
s3 = context["s3_client"]
# 用全新 session 干活
# session 自己管理事务
# 用完就丢
工厂和客户端常驻边界，session 和业务逻辑则在分界线上方，各干各的井水不犯河水。
为什么这个心智模型很重要？
说实话，没碰过坑之前我也是“教程怎么写我就怎么抄”。
FastAPI 教程说：“这样写。”我就跟着写。Litestar 文档说：“放这儿。”我就塞这儿。
但一旦你开始：
- 多 worker 协同
- 写后台任务
- 混用数据库、S3、Redis、消息队列
- 调试奇怪的连接问题
这时候，复制粘贴就救不了你。你得明白为啥要这么设计。
对我来说，真正的转折点是看清了这条分界线：
- 分界线下：持久化系统（Postgres、S3、Redis），业务状态的老巢
- 分界线上：客户端对象（engine、session factory、S3 client），桥梁
- 分界线上方：无状态（ish）请求处理器，只管干活儿
一旦你脑子里有了这张图，很多“神秘套路”其实都是有理有据的设计选择。
你不是因为 Python 的什么 bug 才一直留着 engine，而是因为连接池很贵，只能共享。
你不是因为教程让你每次新建 session 就照做，而是因为事务必须有干净的边界，连接池也需要反复利用连接。
你不是在“自相矛盾”地把 S3 client 共享、数据库 session 独立，而是认清了不同系统的交互模式各不相同。
总结一下（TL;DR）
如果你以后忘了细节，只想回来看核心观点：
无状态不是“啥都不能共享”，而是“每个请求都不依赖以前的隐形状态”。
分界线心智图：
- 下方：持久化系统（数据库、S3、Redis）
- 线上：客户端基础设施（engine、session factory、client）
- 上方：每请求独立的业务逻辑（session、service、handler）
数据库之所以显得特殊，是因为：
- 连接池有硬性上限
- 事务要求干净的边界
- session 记录着变更，直到 commit/rollback
实践中：
- 共享：engine、客户端、配置、工厂
- 独立新建：session、请求上下文、事务边界
以后再看到 engine、sessionmaker、Session 或 s3_client，你就知道它们该在架构的哪一层，为什么要那样设计。
这些不是魔法套路，而是你有意识地划清了你和有状态世界之间的那一道线。
（本文由人类撰写，部分内容借助 AI 优化。）