asyncio中禁用time.sleep()而应使用await asyncio.sleep()；apscheduler需用asyncioscheduler并正确绑定事件循环；动态增删任务须显式指定唯一job id；阻塞io必须通过异步库或线程池处理。
asyncio 里直接用 time.sleep() 会阻塞整个事件循环
这是新手最常踩的坑：在 async def 函数里写 time.sleep(5)，结果所有并发任务都卡住。因为 time.sleep() 是同步阻塞调用，它会让整个 event loop 停摆。
正确做法是用 asyncio.sleep() —— 它是协程，会主动让出控制权，其他任务才能继续跑。
- ✅ 正确：
await asyncio.sleep(5) - ❌ 错误：
time.sleep(5) - ⚠️ 注意：
asyncio.sleep()的单位是秒，支持浮点数（如0.1），但底层精度受系统调度限制，别指望毫秒级严格准时
用 apscheduler 的 async 模式要小心 event loop 绑定问题
APScheduler 默认用 threading，想在 asyncio 环境下跑得加 AsyncIOScheduler，但它对 event loop 的绑定很敏感——尤其在非主线程、Jupyter 或某些测试框架里容易报 RuntimeError: There is no current event loop in thread。
关键不是“装了就能用”，而是确保 scheduler 启动时所在线程有且仅有一个 running loop。
- ✅ 推荐启动方式：
asyncio.run(scheduler.start())，或在已有 loop 中用asyncio.create_task(scheduler.start()) - ❌ 避免在子线程里手动调
AsyncIOScheduler.start() - ⚠️ 如果用 FastAPI/Starlette，别在模块顶层 start scheduler；应在 lifespan 事件中启动/关闭，否则可能和框架 loop 冲突
需要动态增删任务？别依赖 APScheduler 的 add_job() 返回值
add_job() 返回一个 Job 实例，但它的 id 是字符串，且默认自动生成（如 'job_12345'），不保证唯一性或可预测性。如果你靠这个 id 去 remove_job()，很可能删错或删不掉。
真正可控的方式是显式指定 id 参数，并配合 jobstore（比如用 MemoryJobStore 或 SQLAlchemyJobStore）做持久化管理。
- ✅ 显式赋 id：
scheduler.add_job(func, 'interval', minutes=5, id='daily_cleanup') - ✅ 删除时：
scheduler.remove_job('daily_cleanup') - ⚠️ 注意：如果多个 scheduler 实例共享同一个 jobstore（比如分布式部署），
id必须全局唯一，否则冲突
定时任务里调用阻塞 IO（如 requests、sqlite3）会拖垮整个异步服务
哪怕你用了 AsyncIOScheduler，如果任务函数里直接调 requests.get() 或 conn.execute()，照样会阻塞 event loop。这不是 scheduler 的问题，是你没把阻塞调用“搬出去”。
解决方案只有两个：要么换异步库（aiohttp、aiosqlite），要么用 asyncio.to_thread()（Python 3.9+）或 loop.run_in_executor() 把阻塞操作扔到线程池。
- ✅ 异步 HTTP：
await aiohttp.ClientSession().get(url) - ✅ 同步库转异步（推荐）：
await asyncio.to_thread(requests.get, url) - ⚠️ 别用
asyncio.run_in_executor(None, ...)在任务里反复创建 executor，应复用或设为全局实例
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
