sched模块适合单次延迟执行或小规模非长期调度，不适合周期性任务；它本质是阻塞式优先队列调度器，仅适用于一次性轻量延时场景，如3秒后回调、5秒后重试，不支持自动循环、cron表达式及运行中取消任务。
sched 模块适合做「单次延迟执行」或「小规模、非长期运行」的定时调度，不适合替代 schedule 或 APScheduler 做周期性任务。
什么时候该用 sched？
它不是为“每天 8 点发邮件”这类需求设计的，而是为“3 秒后执行一次回调”“5 秒后重试一次请求”这种一次性、低延迟、轻量级的延时场景准备的。
- 你只需要在当前进程里延时执行一个函数（比如等资源就绪后再调用）
- 任务数极少（通常 ≤ 5 个），且不需重复触发
- 不想引入第三方依赖，纯标准库方案即可满足
- 能接受
scheduler.run()是阻塞调用——它会一直卡在那里，直到所有已安排事件全部执行完
sched 的核心限制：不能自动循环、不支持 cron、无法取消已入队任务
它本质是个优先队列 + 手动驱动的事件调度器，没有后台线程、没有心跳检测、也没有“下次执行时间”的计算逻辑。
-
scheduler.run()一调用就阻塞，不会返回；想再调度新任务，得重新创建scheduler实例 - 没有
every().minutes.do()这类语法，所有时间都靠delay参数硬算（比如“每天 10 点”得自己算出距现在秒数） -
enter()后无法取消任务，除非你在action函数里加判断逻辑提前 return - 所有任务默认串行执行，一个任务耗时 10 秒，后面所有任务都会顺延——它不提供并发控制选项
和 schedule 的关键区别在哪？
别被名字误导：sched 和 schedule 完全是两种设计哲学。
-
sched是“事件驱动式延时器”，类似 JavaScript 的setTimeout -
schedule是“语法糖式轮询器”，靠while True+time.sleep(1)不停比对时间 -
sched不依赖循环，但必须显式调用run()；schedule必须手动写循环，否则啥也不干 -
sched的时间精度取决于timefunc（推荐用time.monotonic），而schedule默认用time.time()，可能受系统时间跳变影响
容易踩的坑：sleep 误用、优先级混淆、时间函数选错
常见报错如 RuntimeError: cannot schedule new events after scheduler.run() is called，或者任务根本没触发，往往源于这几个点：
立即学习“Python免费学习笔记（深入）”；
- 用了
time.sleep当delayfunc，但在主线程里又自己写了time.sleep()——造成双重阻塞 - 设了相同
delay但不同priority，结果发现高优先级任务反而后执行（注意：数值越小优先级越高） - 用
time.time()作timefunc，结果系统时间被 NTP 校准导致任务提前/跳过 - 把
sched当成APScheduler用，试图让它每分钟跑一次——它根本不支持周期性自动重入
sched 就不该是第一选择。它的价值只在“够轻、够可控、够标准库”。一旦需求超出单次延时，就得换工具。 
