greenlet中抛出的异常在gevent中默认静默丢失，需主动检查greenlet实例的.exception属性并手动处理，否则异常将“蒸发”。
greenlet 里抛出的异常在 gevent 中会丢失 traceback
greenlet 自身不维护完整的异常传播链，当在 gevent.spawn 启动的 greenlet 中抛出异常但未被显式捕获时，gevent 默认会静默吞掉它——你既看不到报错，也收不到通知。这不是 bug，是 greenlet 的设计使然：它的异常只在同一线程内、同一调度上下文中传播。
- 典型现象：
gevent.joinall([gevent.spawn(bad_func)])执行完无任何输出，但bad_func实际已崩溃 - 必须主动检查：
g.exception（g是Greenlet实例），否则异常就“蒸发”了 - 推荐写法：
g = gevent.spawn(bad_func) g.join() if g.exception: raise g.exception - 不建议依赖
gevent.sleep(0)或gevent.idle()来“触发”异常浮现——它们不改变异常捕获时机
gevent.monkey.patch_all() 后，原生 try/except 对 greenlet 异常仍然有效
patch 后 Python 的异常机制本身没变，try/except 在当前 greenlet 内依然能捕获同步抛出的异常；但跨 greenlet 的异常不会自动冒泡到父 greenlet，这点和线程不同。
- 常见误用：在主 greenlet 里
try: gevent.spawn(f).join() except Exception as e:—— 这捕不到f里的异常，因为join()不 re-raise - 正确做法是检查
.exception属性，或改用gevent.spawn_later(0, f)+join()组合后手动处理 - 注意：
gevent.Timeout是特例，它继承自BaseException，普通except Exception:捕不到，得写except BaseException:或明确except gevent.Timeout:
使用 gevent.pool.Pool 时，异常会统一收集在 Pool.close() / .join() 之后
Pool 不会在任务失败时立即中断，而是等所有任务结束才批量暴露异常，这容易让人误以为“没出错”。实际异常对象被封装在 Greenlet 实例里，需遍历检查。
- 典型陷阱：
pool.map(func, items)中某个func抛异常，返回结果列表里对应位置是None，但异常藏在pool.greenlets[i].exception - 安全做法：
pool = gevent.pool.Pool(10) jobs = [pool.spawn(func, x) for x in items] gevent.joinall(jobs) for j in jobs: if j.exception: print("failed:", j.exception) - 性能提示：频繁检查
.exception几乎无开销，但别在循环里反复调用j.get()—— 它会阻塞并可能重复抛异常
从 greenlet 切换到 gevent 时，不能直接复用裸 greenlet.spawn
gevent 的调度器接管了 greenlet 创建逻辑，直接调用 greenlet.greenlet(func).switch() 会绕过 gevent 的事件循环，导致 I/O 不被监听、超时失效、甚至死锁。
立即学习“Python免费学习笔记（深入）”；
- 错误示例：
g = greenlet.greenlet(some_io_func); g.switch()—— 即使some_io_func用了gevent.socket，也会卡住 - 必须用 gevent 提供的构造方式：
gevent.spawn()、gevent.spawn_later()、pool.spawn() - 兼容旧代码？可封装一层：
def safe_spawn(func, *a, **kw): return gevent.spawn(lambda: func(*a, **kw))，但别试图 patchgreenlet.greenlet类本身
最易被忽略的一点：gevent 的异常传播不是“自动连通”的，它依赖你主动拉取每个 greenlet 的 .exception。没人替你扫雷，写了 spawn 就得配 join 和 if g.exception —— 少一步，问题就埋进日志死角里了。
