f10跳过函数调用执行，f11进入可调试函数体；shift+f11跳出依赖调用栈完整性，装饰器可能干扰返回位置；ctrl+f10仅对当前作用域可执行语句生效；f11无效多因justmycode、sourcemaps或skipfiles配置不当。
断点停住后，F10 和 F11 到底在“跳”什么
F10（Step Over）和 F11（Step Into）不是按“行号”移动，而是按“执行单元”推进。当前行是否调用函数、该函数是否可被调试器解析，共同决定下一步停在哪。
常见错误现象：在 result = fetch_data() 行按 F11，却直接停在下一行——说明 fetch_data 要么是内联函数、要么没 source map、要么定义不在当前工作区路径中（比如来自 site-packages）。
- F10 遇到任何函数调用（
print()、json.loads()、你自己写的process()），都只执行完它，停在调用行的下一行 - F11 只有在函数体可定位、且未被
skipFiles屏蔽时，才会真正进入；否则行为等同于 F10 - 异步调用如
await api_call()按 F10 不会等待响应，只是挂起并继续跑后续同步代码
Shift+F11 跳出函数时，为什么有时不回到预期位置
Shift+F11 的目标是“执行完当前函数剩余部分，返回到它的直接调用者”，但它依赖调用栈的完整性。一旦栈帧被装饰器、@wraps 或优化覆盖，返回位置就可能偏移。
典型场景：多层装饰器（@auth @cache @log）嵌套下，按下 Shift+F11 后停在最外层 wrapper 的 return 后，而非原始函数调用处——因为调试器看到的“当前函数”其实是 wrapper，而原始函数名已被 @wraps 伪装。
- 验证方法：暂停时看“调用堆栈”面板，确认顶部帧是否为你预期的 wrapper，而不是被重命名后的原函数名
- 想精准跳出到某一层，得提前在那层 wrapper 内设断点，再手动用
Shift+F11 - Python 中若
justMyCode为true（默认），第三方装饰器（如@lru_cache）根本进不去，Shift+F11也就无从谈起
Ctrl+F10 “运行到光标处”不是万能快捷键
Ctrl+F10 看似方便，但它本质是“临时加一个一次性断点”，不解决底层执行逻辑问题。
容易踩的坑：光标放在 for item in data: 这类语句上，按 Ctrl+F10 后程序可能直接跑完循环——因为该行本身不执行迭代，只是声明入口；真正可中断的是循环体内的第一行。
- 它只对**当前作用域内已加载、且可执行的语句**生效；放在
def、class、空行、注释行上无效 - 不会触发变量初始化或闭包捕获逻辑，所以悬停查看变量时可能仍是旧值
- 在异步函数里慎用：光标放在
await行下方，但当前 await 尚未 resolve，Ctrl+F10会直接跳过整个 await 链
跳入失败时，先查 launch.json 里的三个关键项
跳不进去不是快捷键失灵，而是调试器压根没拿到可跳的源码。90% 的“F11 无效”问题出在配置层面。
打开 .vscode/launch.json，重点核对：
-
"justMyCode": true—— Python 默认开启，会跳过所有非工作区代码；调试装饰器或 requests 内部时需设为false -
"sourceMaps": true—— TypeScript / Webpack 项目必须开，否则断点漂移到编译后代码，F11 找不到对应源文件 -
"skipFiles"数组 —— Node.js 项目若漏配"<node_internals>/**"</node_internals>，F11 会频繁卡在fs或events内部
改完必须重启调试会话，热重载不生效。
