应按状态生命周期统一收口：局部变量→实例属性→ContextVar/threading.local→外部存储；避免混用机制，异步必用ContextVar且设默认值，复杂场景交由SQLite/Redis等专用系统。
状态散落在多个地方，怎么统一收口？
Python 里状态管理变复杂，往往是因为 self._cache、thread_local、全局字典、甚至环境变量混着用。这不是设计选择，是演进中没及时收敛的痕迹。
真正该做的，是明确「谁拥有这个状态」和「生命周期归谁管」：
- 如果只在单次函数调用内有效 → 用局部变量，别提“状态”两个字
- 如果跨方法但不跨实例 → 放
self上，且命名带语义（比如self._pending_requests，而不是self._state） - 如果跨实例但同线程 → 明确用
threading.local()，初始化逻辑写在<strong>init</strong>或首次访问时，别在模块顶层赋值 - 如果真要跨线程/进程 → 别硬扛，直接切到
multiprocessing.Manager或外部存储（Redis、SQLite），Python 的内置机制不适合这种场景
常见错误：把 threading.local() 实例挂到模块变量上，结果每次 import 都新建一个，线程隔离失效。
用 dataclass 或 pydantic 模型替代手工维护的状态类？
能用就用，但得看场景。不是所有状态都需要验证或序列化。
立即学习“Python免费学习笔记（深入）”；
dataclass 适合结构固定、无副作用、纯数据承载的状态容器：
- 开启
slots=True能省内存，尤其状态字段多、实例量大时 - 加
unsafe_hash=True只有在你要放进set或当 dict key 时才需要，别默认开 - 别在
__post_init__里做 IO 或发请求，那已经超出“状态定义”的职责
pydantic.BaseModel 更重，适合：
- 外部输入（如 API 请求体）必须校验类型和范围
- 状态要导出为 JSON、要支持嵌套模型、要自动转换（比如
datetime字符串转对象）
容易踩的坑：把 BaseModel 当普通类频繁实例化，又不做缓存——它的验证开销比 dataclass 高一个数量级，压测时容易暴露。
异步环境下状态管理为什么总出错？
根本原因是：async 函数不等于新线程，threading.local() 在协程切换时完全不生效。
典型现象：contextvars.ContextVar 没设默认值，然后在某个 await 后读不到之前 set 的值，报 LookupError。
正确姿势：
- 所有异步上下文相关状态，必须用
contextvars.ContextVar - 初始化时务必传
default=...，哪怕只是None，否则第一次 get 就崩 - 不要在
<strong>init</strong>里直接self._ctx.set(...)，而应在进入 async 上下文（比如 middleware、decorator 或 task spawn 时）统一 set - 别试图把
ContextVar和threading.local混用——它们解决的是不同维度的问题，强行桥接只会增加理解成本
性能提示：ContextVar.get() 很快，但频繁 set() + reset() 会有开销，尽量复用 context，避免在循环里反复切换。
什么时候该放弃 Python 自建状态管理？
当出现以下任一信号，说明你在用 Python 做它不擅长的事：
- 你开始写单元测试专门 mock 状态变更路径
- 你加了
@synchronized或手动Lock来保护状态读写 - 你发现不同模块对同一份状态的“预期格式”不一致（比如 A 认为
status是字符串，B 当成整数用） - 日志里频繁出现 “state mismatch”、“unexpected None in cache” 这类模糊错误
这时候，不是代码写得不够好，而是抽象层级错了。该交出去的就交出去：
- 会变化、需查询、要持久 → 用 SQLite（轻量）或 PostgreSQL（并发高）
- 临时、高速、可丢 → 用 Redis，配合
redis-py的连接池 - 纯配置类状态 → 提前加载进
pydantic.BaseSettings，启动时校验，运行时只读
状态管理本身不该是业务逻辑的焦点。它应该像电源插座——插上就能用，坏了才有人注意。
