VSCode按F11没反应是因为未启动调试会话，必须先按F5或点击“开始调试”进入调试模式；F11仅在有可调试函数调用时才步入，否则等效于F10，且受sourceMaps、内置函数限制及异步边界影响。
VSCode调试时按F11没反应？检查调试器是否已启动
断点必须在调试会话中才有效，直接运行代码（Ctrl+F5 或点击“运行”按钮）不会进入调试模式。务必先点击绿色三角形旁的下拉箭头，选择正确的环境（如 Python、Node.js），再点击“开始调试”（或按 F5）——只有这时，F11、F10 等快捷键才会生效。
常见错误现象：
– 在非调试状态下按 F11，编辑器无响应或只触发了系统快捷键（比如音量调节）；
– 调试器启动后仍无法单步，可能因未加载 sourcemap（尤其 TypeScript/前端项目），需确认 launch.json 中 sourceMaps 设为 true，且构建产物含正确映射。
F11 是单步跳入，但为什么有时直接跳过了函数？
F11（Step Into）本意是进入当前行调用的函数内部，但它受三类限制：
- 目标函数不可调试：比如内置函数（
console.log、Array.prototype.map）、压缩后的第三方库、或未生成调试信息的 C++ 扩展模块 —— 此时 VSCode 会自动“跳过”，行为等效于F10； - 源码缺失：调用了一个有符号但无对应
.ts或.js源文件的函数（例如只引用了node_modules里的.d.ts），VSCode 无法跳入； - 异步边界：在
await行按F11不会跳进 Promise 内部，而是暂停在 await 完成后的位置（这是设计使然，不是 bug）。
实操建议：想强制跳入某函数，可右键该函数名 → “Go to Definition”，确认能打开源码后再设断点；若仍跳不进去，改用 F10（Step Over）绕过，或在目标函数第一行手动加断点。
区分 F10（跳过）、F11（跳入）、Shift+F11（跳出）的实际效果
三个快捷键对应不同控制粒度，容易混淆的是 F10 和 F11 在“当前行无函数调用”时表现一致（都执行并停在下一行），但一旦有调用，差异立刻显现：
-
F10（Step Over）：执行整行，包括所有函数调用，但不进入其内部 —— 停在下一行； -
F11（Step Into）：若有可调试的函数调用，进入其第一行；否则等同F10； -
Shift+F11（Step Out）：跳出当前函数，回到它的调用者处 —— 注意不是“返回上一步”，而是运行完剩余逻辑后，在调用点暂停。
示例场景（JavaScript）：
function inner() { return 42; }
function outer() { console.log(inner()); } // 光标在此行
// 按 F11 → 进入 inner() 函数体
// 按 F10 → 直接执行 inner() 并打印，停在 outer() 的下一行
// 在 inner() 中按 Shift+F11 → 跳出到 outer() 中 console.log(...) 的下一行
Python/Node.js/Chrome 调试器对单步的支持差异
不同调试器对“单步”的实现深度不同，直接影响 F11 是否可靠：
-
Python（ptvsd / debugpy）：支持纯 Python 函数跳入，但跳不进 C 扩展（如numpy底层）；async def函数内await行按F11会停在协程恢复点，非 await 表达式内部； -
Node.js（node --inspect）：可跳入 JS 模块，但跳不进原生模块（fs.read等）；ESM 动态import()需确保resolve后的路径可访问源码； -
Chrome DevTools（通过 Debugger for Edge/Chrome 扩展）：支持跳入 sourcemapped 的 TypeScript、JSX，但若webpack配置了devtool: "hidden-source-map"，则跳入失败 —— 必须用"inline-source-map"或"eval-source-map"。
真正容易被忽略的一点：单步执行依赖调试器与运行时的实时通信带宽。大型循环里狂按 F11 可能卡顿甚至断连，此时应改用断点 + 条件断点，而非依赖单步。
