Shift+F5是最可靠的调试中断方式，它通知调试器主动断开并清理资源，而Ctrl+C仅作用于终端而非被调试进程，无效。
调试中按 Shift+F5 是最可靠中断方式
VSCode 调试器接管了进程控制权，Ctrl+C 对终端发信号但不作用于被调试进程，所以无效。Shift+F5 是调试会话的“优雅终止”指令，它会通知 debugpy（Python）、cppvsdbg（C++）或 node-debug（Node.js）主动断开并尝试清理资源——比如释放端口、关闭文件句柄、触发 atexit 注册函数。
常见误操作：
- 点终端右上角垃圾桶图标 → 只关标签页，进程仍在后台跑
- 在非调试终端里按 Ctrl+C → 信号根本没发给 debuggee 进程
- 调试卡死时反复按 F5 或 Pause → 不会中断，可能加重阻塞
如果 Shift+F5 按下后无响应（比如断点停在 native code 或系统调用里），先执行 Debug: Disconnect（Ctrl+Shift+P 输入），再手动杀进程。
红色 Stop 按钮和调试工具栏位置要认准
调试启动后，顶部会出现一行调试控制条，其中红色方块按钮就是 Stop。它和 Shift+F5 功能完全等价，但容易被忽略，因为：
- 它只在调试活动时显示，暂停/继续状态切换时图标不变
- 如果同时开了多个调试会话，每个会话有独立的 Stop 按钮，必须点当前正在运行的那个
- 某些扩展（如 Jupyter）会覆盖该区域，导致按钮被遮挡
验证是否真中断：看调试面板左上角状态是否从 “Running” 变成 “Not connected”，且终端不再输出新日志；若程序监听端口（如 :3000），可用 lsof -i :3000（macOS/Linux）或 netstat -ano | findstr :3000（Windows）确认端口已释放。
为什么不能依赖 Ctrl+C 中断调试中的 Python/Node.js
因为调试模式下，VSCode 启动的是带调试代理的子进程（如 python -m debugpy --listen ... --wait-for-client），原始脚本进程已被 debugpy 接管。此时 Ctrl+C 发给的是外壳终端，不是 debugpy，更不是你的 app.py。
典型现象：
- 按 Ctrl+C 后光标回到终端提示符，但进程仍在后台跑（
ps aux | grep python还能看到） - 端口持续占用，重启调试报错
EADDRINUSE - 变量修改未生效，因实际运行的还是旧进程
例外情况：如果你是用终端直接运行 python app.py（没走 F5 调试），那 Ctrl+C 就有效——但这不属于“调试过程中”的场景。
条件断点或 Logpoint 能减少中断频次，但不能替代 Stop
频繁中断常源于循环内打普通断点。这时应改用高级断点功能，而不是反复点 Stop：
-
Hit Count：设为100，跳过前 99 次循环，第 100 次才停 -
Expression：写i == 99或"admin" in user.roles，只在满足条件时中断 -
Log Message：写Batch {i}: loss={loss:.4f}，不中断、纯打印，避免打断训练流
注意：Expression 必须是纯表达式，不能含 print()、if、赋值语句，否则断点变空心且永不触发。
真正难处理的，是调试器本身卡死在底层（比如 Windows 上 attach 到挂起的进程），这时候没有快捷键能救，只能关 VSCode 再开——别硬等。
