Shift+F11 是“跳出当前栈帧”而非简单退出函数，它依据调用栈的 return address 执行，不受源码行数影响，在异步、递归、高阶函数中精准作用于当前帧。
Shift+F11 单步跳出（Step Out）只在函数体内有效
按 Shift+F11 的前提是当前调试暂停点必须在一个函数内部——比如你正停在 processUser() 的第 5 行，此时按它会立刻执行完剩余代码，并停在调用 processUser() 那一行的下一行。如果当前不在任何函数体中（例如停在模块顶层、或 main() 函数外），Shift+F11 会无响应，也不报错。
常见误操作：
- 在异步回调里按
Shift+F11，结果没跳出：因为 JS/TS 中的回调常被包装成匿名函数或微任务，调试器可能不将其识别为“可跳出的函数上下文” - 在 C++ 模板实例化函数里按，却跳到了上层调用者之外：编译器内联或符号缺失时，调试器无法准确定位“当前函数边界”，
Shift+F11会退化为类似F10的行为 - 刚启动调试就按，没反应：必须先触发断点或暂停（如 F5 启动后自动停在入口、或手动打了断点），否则快捷键不生效
为什么不用连按 F10 代替 Shift+F11
F10 是“单步跳过”，每次只走一行；Shift+F11 是“跳出当前函数”，无论函数还有 2 行还是 200 行，都直接执行完并返回。两者逻辑完全不同：
- 深嵌套函数中连按 10 次
F10容易漏行或误判，尤其当某行是条件分支或循环时，实际执行路径可能跳转 -
Shift+F11不受源码行数干扰，只认栈帧——它看的是 call stack 里当前帧的 return address，不是编辑器里的换行符 - 在 Python 或 Node.js 中，
Shift+F11能正确跳出async函数体；而F10在await行只会发请求就走，根本不会等 resolve
断点位置影响 Shift+F11 的实际效果
Shift+F11 的“当前函数”由调试器根据符号信息和栈帧动态判断，不是靠光标所在函数名硬匹配。这意味着：
- 如果断点打在
if块第一行，但该if属于handleRequest()，那么Shift+F11会跳出handleRequest()，不是跳出if - C++ 项目中若未开启
-g编译选项，或launch.json里miDebuggerPath指向错误的 GDB 版本，Shift+F11可能直接跳到main()结束，而不是预期的上层调用处 - Node.js 项目若
launch.json没设"sourceMaps": true，且.js文件来自 TypeScript 编译，Shift+F11会按生成后的 JS 函数边界跳出，和源码结构不一致
真正容易被忽略的细节
很多人以为 Shift+F11 是“退出函数”，其实它退出的是“当前栈帧”。这个区别在异步、递归、高阶函数场景下特别关键——比如你停在一个被 setTimeout 包裹的箭头函数里，Shift+F11 会跳出那个箭头函数，但不会跳出 setTimeout 的宿主环境；再比如递归调用中，每层 fib(n) 都是一个独立栈帧，Shift+F11 只跳出当前这层，不是所有递归层。
