VSCode的Python调试器能在yield行设断点并暂停，但F11不会进入生成器体，因生成器执行是分段恢复而非重新进入；F10会直接运行到下一yield而非逐行执行；变量可能显示不全，建议提前赋值；异步生成器调试支持有限，需拆分同步/异步逻辑。
断点能停在 yield 行，但 F11 不会“进入”生成器体
VSCode 的 Python 调试器（debugpy）确实能在 yield 行设断点并暂停，但它的单步行为和普通函数不同：按 F11（Step Into）不会跳进生成器函数体内部——因为生成器函数只在首次调用 __next__() 时执行到第一个 yield，后续每次 next() 或 for 迭代才从上次暂停处继续。调试器把这整个过程视为“恢复执行”，而非“重新进入”。
yield 后的变量值在 Variables 面板里可能显示不全
生成器暂停时，局部变量作用域被冻结在 yield 点，但 debugpy 有时无法完整捕获闭包变量或临时计算表达式。常见现象是 Variables 面板里显示 <optimized out></optimized> 或空值，尤其当变量仅在 yield 表达式中出现（如 yield x * 2 中的 x * 2），而未被显式赋值给局部变量。
- 解决办法：提前赋值，比如把
yield x * 2改成result = x * 2; yield result，这样result就能稳定出现在 Locals 里 - 避免在
yield行写复杂表达式，特别是含副作用（如yield func()）——调试器可能在求值前就暂停，导致你无法观察调用过程 - 如果用了
yield from，断点停在该行时，Variables 面板不会显示被委托生成器的状态；要查它，得在那个子生成器内部另设断点
多轮 yield 之间无法用 F10 “逐过程”跳过中间逻辑
F10（Step Over）在生成器里表现反直觉：它不会像普通代码那样“执行下一行”，而是直接运行到下一个 yield 或函数结束。这是因为生成器的执行流不是线性的——两次 yield 之间的代码块，实际是在不同次 next() 调用中分段执行的。
- 想精确控制每一步，必须依赖断点：在每个关键
yield行手动设点，然后用F5继续到下一个 - 不要指望
F10能帮你“跳过循环体里某次迭代”，它会直接跑完整个循环直到下次yield - 若生成器嵌套深（比如递归生成器），
Call Stack面板会显示多个同名帧，但它们对应的是不同暂停点，需靠线程 ID 和暂停位置区分
调试协程（async def + yield）更易出错
带 async 的生成器（即异步生成器，async def + yield）在 VSCode 里支持度有限。debugpy 1.8+ 可识别 yield 行断点，但 F11 进入 await 表达式后，常卡在事件循环调度层，Variables 面板丢失上下文。
立即学习“Python免费学习笔记（深入）”；
- 最稳妥做法：把异步生成器拆成同步部分（纯数据构造）+ 异步部分（
await调用），分别调试 - 避免在
async for循环内直接设断点；改用async with块外加日志点（Logpoint）输出item值 - 确认 launch.json 中
"justMyCode": false，否则 debugpy 可能跳过 asyncio 内部帧，导致断点看似“消失”
生成器调试真正的难点不在断点设置，而在理解调试器如何映射“暂停-恢复”语义到线性步进操作上——你看到的红点是真的，但 F10/F11 的行为逻辑，和函数调用栈那一套根本不是一回事。
