asyncio.wait_for 不中断任务的根本原因是被等待协程未响应取消信号；其取消依赖协程主动检查 cancellederror 或在 await 点让出控制权，若存在阻塞调用、死循环或同步库（如 requests、time.sleep），则无法真正中断。
asyncio.wait_for 为什么有时不中断任务
根本原因不是 asyncio.wait_for 失效，而是被等待的协程没响应取消信号。Python 的 async 取消依赖协程主动检查 asyncio.CancelledError 或在 await 点让出控制权。如果协程里写了死循环、阻塞调用（比如 time.sleep(10)）、或用了未适配 asyncio 的库（如 requests），wait_for 就只能干等超时，无法真正“中断”。
- 确认目标协程内部没有
time.sleep、while True无 await 等阻塞写法 - HTTP 请求必须用
aiohttp或httpx.AsyncClient，不能用requests.get - 文件读写要用
asyncio.to_thread包装同步操作，否则取消无效 - 自定义协程中，在长耗时逻辑间隙加
await asyncio.sleep(0)，给事件循环插入取消检查机会
timeout 参数传 float 还是 int？精度怎么选
asyncio.wait_for 的 timeout 参数只接受 float 或 None，传 int 会被隐式转成 float，但语义上它表示“秒级浮点精度”。实际使用中，小于 0.1 秒的 timeout 很难稳定生效——受事件循环调度延迟、系统时钟精度影响，可能刚进协程就超时了。
- 网络请求类场景，设
timeout=5.0比timeout=5更明确，避免误读为整数语义 - 本地计算型协程，若预期耗时几十毫秒，用
timeout=0.1即可；低于0.01就容易误触发 - 不要用
timeout=0期望“立即取消”，它等价于“不等待”，直接抛TimeoutError
捕获 TimeoutError 后，原任务还在跑吗
是的，原任务默认继续运行。asyncio.wait_for 超时时只会 raise TimeoutError，不会自动清理底层 task。这容易造成资源泄漏或重复处理——比如你发起一个上传，超时后又重试，结果两个上传同时进行。
- 必须手动 cancel 原 task：用
asyncio.create_task()显式创建 task，再在 except 块里调task.cancel() - 更稳妥的做法是用
asyncio.shield()包裹关键 cleanup 逻辑，防止 cancel 波及资源释放步骤 - 注意：cancel() 是异步通知，真正结束仍需 await，所以 cleanup 最好也设计成可 await 的
替代方案：asyncio.timeout 上下文管理器更简洁
Python 3.11+ 引入了 asyncio.timeout，比 wait_for 更轻量、语义更清晰，且能自动处理 task 生命周期。它本质是上下文管理器，进入时启动计时，退出时自动 cancel 未完成的协程。
- 写法更直白：
async with asyncio.timeout(3.0): await fetch_data() - 无需手动 try/except
TimeoutError，异常类型一致，但不用管 task 清理 - 低版本 Python（async_timeout 第三方包模拟，API 几乎一致
- 注意：它不能像
wait_for那样返回结果值，只做超时控制，适合“执行即忘”类逻辑
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
