异步代码调试失灵的根本原因是协程未被事件循环调度，breakpoint()在未await的协程中不生效；需启用PYTHONASYNCIODEBUG=1捕获静默错误，并在VS Code中设"justMyCode": false以跟踪await调度。
异步代码难调试，根本原因不是语法复杂，而是执行流脱离了线性认知——协程不 await 就不真跑，断点设错位置就等于没设。
为什么breakpoint()在async函数里经常“失灵”
你在async def函数第一行加breakpoint()，运行后根本不停；或者停了但变量全是None、堆栈显示不到协程内部。这不是 IDE 问题，是事件循环还没调度它。
- 协程对象（
coroutine object）创建即返回，本身不执行——只有被await或asyncio.create_task()提交给事件循环后才可能运行 -
breakpoint()在未进入事件循环上下文时触发，会中断主线程而非挂起当前协程，容易卡死整个 loop - PyCharm/VS Code 默认断点行为依赖调试器对
await语句的识别能力，若没配好或版本旧，就退化成同步式打断
用PYTHONASYNCIODEBUG=1暴露隐藏问题
这个环境变量本质是让asyncio开启深度日志和运行时检查，不改代码就能发现三类典型静默失败：
- 出现
RuntimeWarning: coroutine 'xxx' was never awaited→ 你调了协程函数但忘了await或create_task() - 看到
Executing长期不完成 → 某个await卡住（比如未响应的 HTTP 请求、死锁的asyncio.Lock） - 报
Event loop is closed→ 你在 loop 关闭后还试图await或提交任务（常见于atexit或测试 teardown 阶段）
启用方式很简单：PYTHONASYNCIODEBUG=1 python your_script.py（Linux/macOS）或set PYTHONASYNCIODEBUG=1 && python your_script.py（Windows）。
vscode 调试 async 函数必须配"justMyCode": false
VS Code 默认只调试用户代码，而await、asyncio.run()等底层调度逻辑在 asyncio 内部，不打开这个开关，断点会跳过await之后的关键调度点，看起来就像“断点跳过了”。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
在.vscode/launch.json的配置里加这一行：
{
"configurations": [
{
"name": "Python: Current File",
"type": "python",
"request": "launch",
"module": "asyncio",
"args": ["-m", "your_module"],
"justMyCode": false
}
]
}
否则即使你把断点打在await some_api()后面那行，调试器也可能直接跑到下个await去，中间逻辑像被“剪掉”了一样。
别信print()在 async 里的输出顺序
你以为print("start"); await asyncio.sleep(1); print("done")一定按顺序输出？不一定。尤其在多任务并发时，print本身不是原子操作，缓冲区、线程切换、stdout 重定向都可能导致乱序。
- 真正可靠的观察手段是
logging+asyncio.current_task()：用logging.debug(f"[{asyncio.current_task().get_name()}] msg")标出归属 -
print()只适合单任务简单验证；一旦有asyncio.gather()或create_task()，就别靠它判断执行流 - 更隐蔽的问题：某些日志 handler（比如写文件）本身是阻塞的，会拖慢 event loop，让问题表现得更随机
最常被忽略的一点：async 调试失效往往不是因为工具不行，而是你没确认协程是否真的被调度——先看PYTHONASYNCIODEBUG有没有报“never awaited”，再设断点，顺序错了，所有后续操作都是在调试一个根本没跑起来的函数。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
