asyncio.wait_for直接取消任务而非返回超时结果，因其设计逻辑是“超时即中止”：超时后抛timeouterror并调用task.cancel()触发cancellederror，强制中断协程执行，而非提供默认值或静默返回。
asyncio.wait_for 为什么会直接取消任务而不是返回超时结果？
因为 asyncio.wait_for 的设计逻辑是：超时即中止，不是“等待结果或超时”，而是“等待成功或强制终止”。一旦超时，它会向目标协程抛出 asyncio.TimeoutError，同时触发协程内部的取消逻辑（比如 Task.cancel()），导致任务状态变为 cancelled，后续再 await 就会立刻 raise CancelledError。
常见错误现象：RuntimeError: Task is already cancelled 或协程中途退出却没拿到任何返回值。
- 如果你只是想“知道超时了”，别用
wait_for包裹整个协程，改用带超时控制的执行器或手动轮询 - 如果必须用
wait_for，得在被包裹协程里加try/except CancelledError捕获，并确保能安全退出（比如释放资源、返回默认值） -
timeout=None不代表“不限时”，而是禁用超时机制——但要注意这会让wait_for失去作用，等同于直接 await
如何让超时任务不被取消，还能拿到中间状态或 fallback 值？
核心思路是把“超时判断”和“任务执行”解耦。不要让 wait_for 直接控制业务协程生命周期，而是用 asyncio.create_task 启动它，再用 asyncio.wait 配合 return_when=asyncio.FIRST_COMPLETED 来监听完成或超时信号。
示例场景：调用一个可能卡住的 HTTP 请求，希望 3 秒后不管成没成都继续往下走：
task = asyncio.create_task(fetch_data())
done, pending = await asyncio.wait([task], timeout=3.0, return_when=asyncio.FIRST_COMPLETED)
if task in done:
result = await task # 正常完成
else:
task.cancel() # 主动取消残留任务，避免僵尸协程
result = {"status": "timeout", "data": None}
- 注意
pending里可能有未完成的 task，必须显式 cancel，否则它会在后台继续跑，消耗资源甚至引发竞态 - 不能直接对
task调用result()—— 它还没 finish，要先 await 或检查task.done() - 这种写法兼容 Python 3.7+，但在 3.11+ 可用
asyncio.timeout()上下文管理器替代部分逻辑
asyncio.timeout() 在 Python 3.11+ 中为何仍可能触发 CancelledError？
asyncio.timeout() 是上下文管理器，它内部依然依赖任务取消机制。只要退出 with 块时协程还没结束，就会 cancel 对应 task。这不是 bug，而是设计使然——它只保证“块内最多运行指定时间”，不承诺“超时后给你一个 fallback 值”。
SkillSub Pro - Python 题解与代码注释双功能技能功能概述SkillSub Pro - Python 题解与代码注释双功能技能是一项面向实际任务的技能，主要用于SkillSub Pro 是一个 Python 题解生成与代码注释的 双功能合体技能 ，专为学生、算法学习者和开发者设计；✅ 一个技能，两种用途 ：；核心要点📝 题解模式 ：输入题目/题号，自动生成完整 Python 题解（含详细注释、解题思路、复杂度分析）；💬 注释模式 ：输入 Python 代码，自动添加详细中。它将相关步骤、
容易踩的坑：
- 写成
async with asyncio.timeout(2): result = await slow_func()，一旦超时，result根本不会被赋值，后续代码直接报UnboundLocalError - 在 timeout 块里启动多个协程，只有一个受保护；其余不受控，可能泄漏
- 嵌套使用
timeout时，内层 cancel 可能被外层忽略，导致行为不可预测
正确做法是把可能超时的逻辑封装进单独函数，并在外部处理异常：
try:
async with asyncio.timeout(2):
result = await fetch_with_retry()
except asyncio.TimeoutError:
result = {"error": "fetch timeout"}
为什么 loop.run_in_executor 中的阻塞调用超时后无法被及时中断？
因为线程池里的阻塞操作（如 time.sleep、requests.get、sqlite 查询）不受 asyncio event loop 控制。即使你用 wait_for 包裹 loop.run_in_executor，超时只会 cancel asyncio 层的任务对象，而线程仍在跑，资源不会释放。
后果很实际：CPU 占用高、连接不关闭、数据库锁不释放。
- 对 requests 等库，优先用其原生 timeout 参数（如
requests.get(url, timeout=5)），而非靠 asyncio 包裹 - 对纯计算型阻塞，考虑改用
concurrent.futures.ProcessPoolExecutor配合 signal 处理，或拆分 chunk + 进度检查 - 绝对不要在 executor 里做无超时保护的
time.sleep(3600)类操作——asyncio 拿它完全没办法
真正难处理的是那些不响应中断的 C 扩展或系统调用，这时候只能靠进程级隔离或预设硬性超时（比如用 subprocess.run(..., timeout=...)）。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
