断点不中断主因是launch.json配置错误：program路径未用${workspaceFolder}、cwd与import路径冲突、justMyCode为true跳过第三方包、attach模式未启动带调试参数的服务，或console/env配置导致输出不可见。
断点不中断，大概率不是代码问题，而是 launch.json 没告诉调试器“该停在哪、怎么停、停给谁看”。
断点变空心圆（灰色）的直接原因
VSCode 里断点显示为空心圆，代表调试器压根没加载到对应源码位置——不是没触发，是根本没识别。常见诱因包括：
-
program字段路径错误：比如写成"./src/main.py"（相对路径不被解析），或漏了.py后缀；正确写法必须是"${workspaceFolder}/src/main.py" -
cwd（工作目录）和实际模块导入路径冲突：若代码用from utils.helper import foo，但cwd指向src/而非项目根目录，Python 就找不到utils包，调试器随之放弃加载相关文件 -
justMyCode设为true（Python 默认值）时，断点打在标准库或第三方包里会被自动跳过，看起来像“不中断” - 使用
request: "attach"却没启动带--debug或--inspect参数的服务进程，VSCode 连都连不上，自然不会中断
launch.json 中 program、args、cwd 三者必须对齐
这三个字段共同决定“程序从哪跑、带什么参数、以什么视角找模块”。错一个，断点就失效。
-
program是入口文件的绝对路径（推荐用${workspaceFolder}变量），不是命令行要执行的字符串 -
args是传给脚本的参数数组，比如--config config.yaml --verbose要写成["--config", "config.yaml", "--verbose"]，不能拼成单个字符串 -
cwd必须设为 Python 能正确解析import的目录。多数项目应设为"${workspaceFolder}"；若入口是bin/run.py且它依赖src/下的包，cwd就得设为"${workspaceFolder}/bin"或配合pythonPath调整 sys.path
console 和 env 配置影响调试可见性
断点中断了，但你看不到输出、读不到环境变量，常被误判为“没中断”。
-
console设为"integratedTerminal"才能把print()、日志、异常堆栈直接打到底部终端；设成"internalConsole"会藏在调试控制台里，容易忽略 -
env和envFile不是互斥项：env用于覆盖或补充，envFile用于加载.env文件；但envFile路径必须是相对于cwd的，否则变量根本读不进来 - Windows 上路径分隔符混用（
\vs/）会导致envFile加载失败，建议统一用正斜杠或双反斜杠
为什么 attach 模式更容易“中断成功”
当你手动启动服务（如 python -m debugpy --listen 5678 --wait-for-client main.py），再用 request: "attach" 连接，反而比 launch 更稳定。
-
attach绕过了 VSCode 启动进程的路径解析逻辑，只要端口通、协议对，就能接管运行时 - 适合框架类项目（FastAPI、Django），它们启动流程复杂，
launch很难模拟完整生命周期 - 注意
port必须和--listen一致；host若在 Docker 或 WSL2 中调试，别写死"localhost"，改用"0.0.0.0"并确认防火墙放行
最易被忽略的其实是 cwd 和 program 的语义差异：前者是“Python 解释器启动时的当前目录”，后者是“Python 解释器要执行的文件路径”——它们可以不同，但必须协同支撑 import 路径。调不通时，先在终端里 cd 到 cwd 值，再手动运行 python program值，能跑通，launch.json 才可能配对。
