延迟执行函数不加括号，加括号会立即执行；传参应使用functools.partial而非Lambda以防闭包陷阱；async函数必须await调用，且需在async上下文中用asyncio.sleep。
延迟执行函数该不该加括号？
调用时加不加 ()，直接决定是“拿函数本身”还是“立刻执行并取返回值”。这是最常踩的坑——尤其在传参给 threading.Timer、schedule.every().do() 或回调注册场景里。
- 写
func（无括号）：传递函数对象，等后续被调用 - 写
func()（有括号）：立刻执行，把返回值传过去；如果func有副作用或报错，这时就崩了 - 典型反例：
timer = threading.Timer(5, my_task())——my_task()在创建 timer 时就执行了，不是 5 秒后 - 正确写法：
timer = threading.Timer(5, my_task)，注意没括号
lambda 包一层就能解决所有延迟传参问题？
不能。它只是绕过了参数绑定时机问题，但会掩盖真正的设计缺陷，还可能引入闭包陷阱。
- 常见误用：
schedule.every().do(lambda: send_email(user_id))—— 看似延迟，实则每次调度都用当前循环中最后一次的user_id值 - 真正需要的是参数固化，推荐用
functools.partial：from functools import partial; schedule.every().do(partial(send_email, user_id=123)) -
lambda在循环中捕获变量时，多数人没意识到它捕获的是引用而非值，python 3.12 也没改这点 - 性能上，
partial比lambda略快且语义更清晰；调试时也更容易 trace 到原始函数
async/await 场景下，await 一个未 await 的协程会发生什么？
不会报错，但会漏掉异步行为——你拿到的是个 coroutine 对象，不是结果，后续代码照常往下跑，就像什么都没发生。
- 错误写法：
result = fetch_data()（而fetch_data是async def定义的） - 现象：程序不卡、不报错，
result是<coroutine Object fetch_data at></coroutine>，后续用它做计算会 TypeError - 必须显式
await：result = await fetch_data()，且所在函数得是async def - 同步代码里想调异步函数？别硬套
asyncio.run()在热路径上，开销大；优先重构为全异步链路
延迟执行选 time.sleep 还是 asyncio.sleep？
看上下文是否在 Event loop 里。混用会导致线程阻塞或 RuntimeError，不是“差不多能用”的事。
立即学习“Python免费学习笔记（深入）”；
- 在
async def函数里写time.sleep(1)：整个协程挂起，其他任务全卡住，异步白写了 - 在普通函数里写
await asyncio.sleep(1)：直接RuntimeError: no running event loop - 判断依据很简单：当前函数有没有
async关键字？有就用await asyncio.sleep()；没有就用time.sleep() - 跨线程调度异步任务？用
asyncio.to_thread()（3.9+）或loop.run_in_executor()，别自己手撸线程 + sleep 组合
事情说清了就结束。最麻烦的从来不是语法对不对，而是哪段逻辑本该异步却同步卡着，哪次传参看着像延迟其实早执行了——这种问题只在特定数据流和并发节奏下才暴露。