VSCode 无法单步调试 defer 是因为其执行由 runtime 批量处理且无源码映射；只能通过日志输出与断点组合验证 LIFO 顺序及参数求值时机，无法直观跟踪 defer 调用栈。
VSCode 调试模式下无法直接“单步进入”或“观察 defer 链条的逐个执行”，因为 defer 函数是在函数 return 指令之后、真正退出前由 runtime 批量调用的，不经过用户代码的常规控制流。你看到的断点停在 return 行，但 defer 实际执行发生在那之后，且不对应源码行。
为什么 VSCode 里看不到 defer 的单步执行过程
Delve（VSCode 底层调试器）对 Go 的 defer 处理是“黑盒式”的：它把整个 defer 链的执行包裹在 runtime.deferreturn 内部，而该函数是汇编实现、无 Go 源码映射。你在 VSCode 中设置断点、F10 单步时，会直接从 return 行跳到调用方函数体，中间的 defer 函数调用不会出现在调用栈中，也不会触发断点。
- Delve 不支持在
defer函数注册时设断点（比如defer fmt.Println("A")这行），它只会在函数实际执行时才可能捕获——但此时已脱离用户源码上下文 -
defer函数压栈和出栈都在 runtime 层完成，VSCode 的 “Step Into” 对其无效；按 F11 会跳进fmt.Println，而非“下一个 defer” - 如果你在某个
defer函数内部（比如匿名函数体里）设断点，它只会在该 defer 真正执行时命中——但你无法预知它何时被 runtime 触发，也无法控制执行顺序的单步节奏
如何用 VSCode 验证 defer 执行顺序（LIFO）
不能靠单步，但可以靠日志 + 断点组合验证。核心思路：让每个 defer 输出可区分标识，并在 return 前后插入可控断点，观察输出顺序。
- 在函数开头加
fmt.Println("enter")，在return语句前加fmt.Println("before return")，并在每条defer中打印带序号的字符串，例如defer fmt.Println("defer #1") - 在
before return行设断点，运行到该处后，手动点击 “Continue”（F5），此时会立刻看到 LIFO 顺序的 defer 输出（如defer #3→defer #2→defer #1） - 注意：不要在
defer行本身设断点——VSCode 会停在注册位置，而非执行位置，这容易误判为“先注册就先执行” - 若需确认参数求值时机，把变量修改放在
defer注册之后、return之前（如i := 0; defer fmt.Println(i); i = 42），观察输出是否为0——这能验证“参数在 defer 语句处即求值”
调试 panic 场景下的 defer 执行
panic 时 defer 仍会执行，但 recover 必须在 defer 内调用才有效。VSCode 可以捕获 panic，但要注意：Delve 默认会在 panic 发生时中断，你需要手动 Continue 才能看到 defer 执行。
- 在
panic("boom")行设断点，运行后 F5 继续，VSCode 会停在 panic；再按一次 F5，才会进入 defer 执行阶段 - 如果用了
recover()，确保它写在defer函数体内，而不是外层——写在外层的recover()总是返回 nil - 想验证 defer 是否真在 panic 后执行，可在 defer 里加
fmt.Printf("in defer, recovered: %v\n", recover())，输出应为boom（说明 recover 成功）
真正容易被忽略的不是 defer 会不会执行，而是它的执行时机完全脱离源码行号控制——你无法在 VSCode 里“看到”它一步步出栈。所有验证都得靠输出日志+逻辑推断，而不是单步跟踪。这也是为什么 Go 新手常误以为 defer 是“按书写顺序执行”的根本原因：编辑器没给你看到反直觉的那一面。
