yield本身无错，错误源于调用方传入不兼容值导致崩溃；每个yield隐含类型契约，需在赋值后立即校验输入类型并设兜底策略，避免裸奔式连续yield，强调发送方守约与接收方设防的双向契约。
这个问题很实际——不是 yield 本身出错，而是外部调用 next() 或 send() 时传入了不兼容的值（比如该收数字却收到字符串），导致后续计算崩溃，甚至整个生成器卡死或抛出未捕获异常。
关键：yield 不是“被动接收”，而是“主动协约”
每个 yield 表达式都隐含一个类型契约和执行上下文。连续多个 yield 并不自动构成安全流水线；它像一串没有防护栏的传送带——前一环掉进错误数据，后一环就可能直接翻车。
- 第一次
yield返回值后，函数暂停，等待下一次恢复 - 恢复时若用
send(x)，x 会直接赋给当前yield左侧变量（如data = yield中的data） - 如果 x 类型不符（比如期待
int却收到None或str），后续运算（如除法、索引、方法调用）立刻崩
在 yield 前加类型守门人
别等错误流到计算逻辑里才处理，而是在每次 yield 暂停后、真正使用传入值之前做校验。
- 用
try/except包裹 yield 赋值后的第一行业务逻辑 - 对关键字段做显式类型检查，比如
if not isinstance(received, (int, float)): - 配合默认值或降级策略：类型不对就跳过、重试、或返回提示性 yield（如
yield "error: expect number"）
用 send() + throw() 组合实现可控中断
当检测到非法输入，不要硬扛，而是主动触发异常并让调用方感知——这比静默失败更可靠。
- 在生成器内部，
gen.throw(TypeError("bad input"))可由外部注入，但你也可以自己 raise 后由框架捕获 - 更推荐：在 yield 后立即做断言或转换，失败就
raise ValueError，让异常自然冒泡到调用层 - 调用方应配套 try/catch，而不是假设“send 一定成功”
避免裸奔式连续 yield
多个 yield 紧挨着写（比如 yield a; yield b; yield c）看似简洁，实则把所有状态耦合在一起，无法单独校验每个环节。
- 把每个 yield 封装成有明确输入契约的小单元，例如：
yield handle_step_one(received) - 用状态机模式管理流程阶段，每步 yield 都对应一个明确状态（
"waiting_for_count","validating_config"） - 这样既能日志追踪，也能在任意阶段拦截非法输入
本质上这不是 yield 的缺陷，而是协程通信中责任划分的问题：发送方要守约，接收方要设防，中间不靠信任，只靠契约和兜底。
