asyncio.sleep()不可替代time.sleep()，后者会阻塞整个事件循环；cpu密集型任务需用线程池执行；await未完成future易卡住，须设超时并响应取消信号。
asyncio.sleep() 不能替代 time.sleep()
直接在协程里写 time.sleep(5) 就等于给整个事件循环“打麻醉针”——所有其他协程立刻冻结，直到它醒来。这不是慢，是彻底卡死。
必须改用 await asyncio.sleep(5)，它是可等待对象，执行时会主动让出控制权，事件循环才能调度别的任务。
- 错误写法：
time.sleep()、os.system()、同步数据库驱动（如 sqlite3 原生模块） - 正确替代：
await asyncio.sleep()、aiofiles.open()、aiosqlite、aiohttp.ClientSession - 注意：
asyncio.sleep()只模拟等待，不解决真实 CPU 密集型任务
CPU 密集型操作必须移交线程池
哪怕没调任何阻塞函数，纯计算（比如解析大 JSON、图像缩放、MD5 计算）也会饿死其他协程——因为 Python 的 async/await 不自动切片 CPU 时间，只要你不 await，事件循环就插不进调度点。
唯一可靠解法是把计算丢给线程池：loop.run_in_executor(None, cpu_heavy_func, arg)。
Python 3.14.2是Python编程语言在2025年12月5日发布的稳定版本，属于3.14系列的第二个维护更新。该版本包含了18项修复，重点解决了多进程、数据类及正则表达式等模块的回归问题，并修复了CVE-2025-12084等安全漏洞。此版本标志着自由线程模式（移除GIL）正式获得官方支持，是Python发展的重要里程碑。
- 别用
await asyncio.sleep(0)强行让出：这是 hack，不可靠且增加调度开销 - 优先选
concurrent.futures.ThreadPoolExecutor，不是ProcessPoolExecutor（后者在 Windows 上超时响应滞后） - 若频繁调用，建议复用 executor 实例，避免反复创建开销
await 未完成的 Future 会静默卡住
表面写了 await，实际可能陷入无限等待。常见有两类：
- 误写成
await my_coro（漏括号），触发TypeError: object can't be used in 'await' expression；如果异常被静默吞掉，后续逻辑就停摆 - 调用外部服务时，底层 socket 卡在 SYN 阶段（如 DNS 慢、防火墙拦截），
asyncio.wait_for(..., timeout=5)无法真正中断，该协程和连接池都可能被拖垮
对策很明确：所有外部调用必须设超时，且优先用已封装超时逻辑的异步客户端（例如 aiohttp.ClientSession(timeout=...)），而不是裸写 wait_for。
超时后任务仍在后台跑，资源可能泄漏
asyncio.wait_for() 超时抛出 asyncio.TimeoutError，但原协程未必真正终止——它只是被取消（cancellation），若协程内部没响应取消信号，就会继续运行并占用资源。
- 必须在协程里定期检查：
if asyncio.current_task().cancelled(): return - 避免在
try/finally外层做清理；推荐用async with或async for等支持取消的异步原语 - 对嵌套任务，外层超时不会自动传播到内层；需统一用
contextvars或显式传递取消 token
最易被忽略的是：协程取消 ≠ 系统级资源释放。文件句柄、数据库连接、HTTP 连接池这些，必须在取消路径里显式 close，否则很快耗尽。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
