Flask和Django调试断点失效主因是重载与多进程/线程机制导致VSCode未连对目标进程；需禁用--reload/--noreload、--nothreading，配置launch.json环境变量及justMyCode，并确认单进程运行。
Flask启动时加--debug会绕过断点？
不会绕过，但默认用flask run启动时，实际是通过Werkzeug的重载机制起两个进程：一个监控文件变化，另一个才是真正跑应用的worker。断点只在worker进程生效，而VSCode调试器默认连的是主进程——结果就是打上断点也不停。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 改用
python -m flask run --no-reload启动，禁用重载，确保单进程运行 - 或直接运行入口脚本（比如
python app.py），前提是app.run()里显式传debug=False（别留debug=True，它会偷偷启用重载） - 在
.vscode/launch.json里配"module": "flask"时，必须加"env": {"FLASK_ENV": "development", "FLASK_DEBUG": "0"}，否则环境变量仍可能触发重载
Django的manage.py runserver为什么进不了断点？
和Flask类似，runserver默认也开重载（--noreload关掉）+ 多线程（--nothreading关掉）。更隐蔽的是：Django 4.0+ 默认用threading做请求并发，但VSCode Python调试器对多线程断点支持不稳定，常出现“断点灰掉”或“命中但不暂停”。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 启动命令换成
python manage.py runserver --noreload --nothreading -
launch.json中优先选"module": "django"方式，而非"program"指向manage.py，前者能更好捕获Django内部模块加载路径 - 如果用
"program"方式，务必在args里显式写["runserver", "--noreload", "--nothreading"]，别依赖命令行参数自动透传 - 检查
settings.py里DEBUG = True是否被覆盖（比如被python-dotenv或os.getenv动态修改），断点失效有时只是因为Django根本没进开发模式
VSCode调试配置里justMyCode设为false有用吗？
有用，但只在特定场景下才需要调。默认true时，调试器会跳过标准库、第三方包里的代码——这本来是好事；但Flask/Django的路由分发、中间件执行链很深，很多关键逻辑（比如Flask.dispatch_request、Django's base handler）就藏在框架源码里。你断在视图函数却想往上跟请求生命周期，就得关掉它。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 日常调试视图逻辑，保持
"justMyCode": true即可，干净且快 - 排查“请求根本没到我的视图”“中间件提前返回”这类问题时，临时改成
false，再配合Step Into逐层跟进 - 注意性能影响：
false后首次加载会变慢，且所有第三方包的.py文件都会被索引，内存占用明显上升 - 别长期开着——调试完立刻切回
true，否则下次断点可能停在venv/lib/site-packages/werkzeug/...里，徒增干扰
为什么HTTP请求发出去了，VSCode却没响应断点？
最常见原因是调试会话没真正 attach 到处理该请求的进程。尤其当项目用了Gunicorn/Uvicorn（哪怕只是本地开发顺手加了--workers 2），或者Django/Flask配置了use_reloader=True但没彻底禁掉，就会产生多个Python子进程，而VSCode只连了其中一个。
实操建议：
立即学习“Python免费学习笔记（深入）”；
- 启动前先用
ps aux | grep python（macOS/Linux）或任务管理器（Windows）确认只有1个目标进程 - 在
launch.json里加"console": "integratedTerminal"，方便一眼看到启动日志里有没有“restarting”“spawned”这类关键词 - 给入口文件顶部加一行
import time; time.sleep(2)，然后在VSCode里点“暂停”按钮，看是否能手动attach到正在sleep的进程——这是验证attach机制是否正常最直接的办法 - 如果用WSL，确保VSCode是Windows版连WSL，而不是在WSL里开Code Server，后者调试协议兼容性差，断点经常失灵
调试Web框架真正的难点不在设断点，而在确认“此刻正在跑的这行代码，到底属于哪个进程、哪个线程、哪个请求上下文”。其他所有配置，都是为了把这三个变量控制住。
