VS Code“一行一行运行”本质是调试而非执行，需配置语言扩展、launch.json及有效断点；启用stopOnEntry和justMyCode可实现首行暂停；F10跳过函数、F11进入函数、Shift+F11跳出函数；空心断点多因路径错误、语言模式不匹配或语法问题。
VS Code 里“一行一行运行”本质是调试，不是执行
VS Code 没有真正意义上的“单行运行”命令（比如像 Jupyter 的 Shift+Enter 那样直接求值），所谓“一行一行运行”，实际是进入调试会话后，用单步控制让代码停在每行开头再继续——它依赖断点 + 调试器，不是快捷键触发的独立功能。
这意味着：没配好调试环境，F10 或 F11 按了也没反应；语言没装对应扩展（比如 Python 缺 ms-python.python），连断点都点不亮。
- 必须先安装对应语言的官方调试扩展（如 Python →
ms-python.python，Node.js →ms-vscode.node-debug2） - 必须有有效的
launch.json配置（哪怕只选“Python File”自动生成） - 断点必须设在可执行语句上（空行、注释、函数定义行无法设断点，点了也不生效）
怎么让代码真正在第一行就停下？用 justMyCode 和入口断点
很多人按 F5 后程序直接跑完，根本没停——这是因为默认调试器会跳过库代码和启动逻辑，而你的代码可能还没开始执行就结束了。想让控制权第一时间交到你手上，得主动干预启动行为。
- 在
launch.json的配置中加入"stopOnEntry": true，它会让调试器在入口文件第一行就暂停（适合想从头看清流程） - 同时确保
"justMyCode": true（默认开启），否则调试器可能卡在import或__init__.py里出不来 - 如果用的是 Python，且主文件靠
if __name__ == "__main__"触发，断点必须打在这行之后的实际语句上，否则stopOnEntry停住时，__main__块根本没进
F10 vs F11：别按错，它们行为完全不同
调试面板上的“下一步”按钮看着一样，但键盘快捷键背后逻辑差很远——按错一个，可能突然跳进 requests.get() 源码里卡半天。
-
F10（Step Over）：执行当前行，遇到函数调用不进去，直接跳到下一行。适合快速过掉已确认无问题的封装逻辑 -
F11（Step Into）：执行当前行，遇到函数调用就钻进去。适合排查函数内部逻辑，但进了标准库或第三方包容易迷失 -
Shift+F11（Step Out）：从当前函数里立刻跳出，回到调用它的地方。当你误点F11进太深时，这是唯一能快速撤退的方式
举个例子：
result = calculate(x, y) # 光标在这行，按 F11 → 进入 calculate() 定义；按 F10 → 直接执行完这行，光标停在下一行
为什么有时断点红点是空心的？常见三类失效场景
断点显示为空心红圈（或压根点不亮），代表调试器无法在此处中断——这不是 UI bug，而是配置或语法层面被拒绝了。
-
路径没对齐：
launch.json中的"program"指向的是相对路径（如"${file}"），但你在未保存的临时文件或非工作区打开的文件里设断点，调试器找不到上下文 -
语言模式错误：文件右下角显示的是
Plain Text或JavaScript，但你写的是 Python —— 断点只对当前语言模式有效，点击右下角手动切到正确语言 -
异步/顶层代码陷阱：在 Python 中，
async def函数体外直接写await xxx()是语法错误；在 JS 中，顶层await只在模块内有效。这类错误会导致调试器加载失败，断点全失效
最省事的验证方式：按 Ctrl+Shift+P 输入 Debug: Toggle Auto Attach 关掉自动附加，再手动 F5，看终端是否报出 ModuleNotFoundError 或 SyntaxError —— 很多“断点不生效”其实是代码根本没跑起来。
调试不是魔法，它只忠实地反映你配置的路径、选择的解释器、以及当前文件的真实状态。哪一环松了，整条链就断了。
