用yield重构回调不是语法替换，而是将事件驱动的离散跳转重构成线性状态流；需配合事件泵、状态快照和yield-aware日志，并采用渐进式兼容策略。
直接用 yield 替换回调不是“平滑重构”的做法——它本质是把同步阻塞式状态流，转为可中断、带上下文的生成器流程。关键不在语法替换，而在**将事件驱动的离散跳转，重构成按时间/状态顺序展开的线性逻辑**。
先理清原逻辑痛点
典型长连接状态监测（如 WebSocket 心跳、设备在线状态轮询、MQTT 订阅流）往往依赖多层嵌套回调：
- 连接建立后注册 on_message / on_ping 回调
- 每个回调里触发状态判断 → 更新本地缓存 → 发出通知 → 可能再发起子请求
- 错误分支分散在各回调中，重试逻辑重复、超时难统一、状态流转不清晰
这种结构导致调试困难、测试覆盖低、新增状态分支易遗漏边界条件。
用 yield 抽象出“状态流”主干
把整个生命周期看作一条可暂停的执行链：连接 → 认证 → 订阅 → 持续接收 → 异常恢复 → 重连。每一步都是确定性动作，中间插入 yield 表达“等待下一个事件到达”：
- yield 不返回具体值，而是返回一个**事件类型标识符**（如 'PING_RECEIVED', 'DATA_TIMEOUT', 'CONNECTION_LOST'）
- 外部调度器（如 asyncio loop 或专用事件泵）负责监听真实 I/O 事件，并调用生成器的
send(event)将其注入 - 生成器内部用
while True:+yield构建状态机循环，每次收到事件就推进到下一状态
示例骨架：
def state_machine():
yield 'WAITING_CONNECT'
conn = yield 'CONNECTING'
if not conn: yield 'CONNECT_FAILED'; return
yield 'AUTHENTICATING'
auth_ok = yield 'AUTH_RESULT'
if not auth_ok: yield 'AUTH_FAILED'; return
yield 'SUBSCRIBING'
sub_ok = yield 'SUBSCRIBE_ACK'
while True:
event = yield 'WAITING_DATA'
if event == 'HEARTBEAT_TIMEOUT':
yield 'RECOVERING'
continue
elif event == 'NEW_MESSAGE':
yield 'PROCESSING'
# 处理业务逻辑
yield 'IDLE'配套重构三件套
单靠 yield 不足以落地，需搭配：
-
事件泵（Event Pump）：统一接收原始网络事件（如 socket.recv、asyncio.Queue.get），解析为标准化事件对象，再
gen.send(event)注入生成器 - 状态快照机制：生成器每次 yield 前，自动保存关键变量（如 last_heartbeat_ts、retry_count），崩溃重启时可从最近 yield 点恢复，而非从头连接
- yield-aware 日志：日志中记录当前 yield 位置（如 "at SUBSCRIBING, waiting for SUBSCRIBE_ACK"），避免传统回调日志中“谁触发了谁”难以追溯
过渡期兼容策略
老系统无法一次性全量切换，推荐渐进式：
- 新功能模块完全使用生成器状态流
- 旧回调中封装一层
asyncio.create_task(run_generator(...))，让生成器在后台运行，只通过简单队列与主回调通信 - 保留原有回调接口，但内部转发给生成器实例，实现“对外回调，对内生成器”
这样既不打断现有流程，又让新增逻辑天然具备可测性与可追溯性。
