vscode直接f5调试flask报keyboardinterrupt或卡住，根本原因是调试器与werkzeug重载器信号冲突；正确做法是终端执行flask run（推荐）或代码中app.run(debug=true, use_reloader=false)配合f5，禁用重载器以确保调试器稳定接管主进程。
VSCode 运行 Flask 应用不需要插件堆砌，核心是让 python 能正确执行 app.run() 且不被调试器阻塞或误判为脚本异常。
为什么直接按 F5 启动会报错 KeyboardInterrupt 或卡在调试器？
VSCode 默认 Python 调试器（ptvsd 或 debugpy）会在主进程退出时强制中断，而 Flask 的 app.run(debug=True) 内部会启用重载机制并监听文件变化——这会导致调试器误认为程序“未正常结束”，进而触发 KeyboardInterrupt 或反复重启。
- 根本原因不是 Flask 写错了，而是调试器与 Werkzeug 重载器的信号处理冲突
-
debug=False时看似能跑，但失去热重载和错误页面，开发效率断崖下跌 - 不推荐用
launch.json中加"justMyCode": false强行绕过，治标不治本
最简可靠的启动方式：用终端 + flask run
Flask 官方推荐、VSCode 原生支持、零配置冲突。前提是项目根目录下有 FLASK_APP 环境变量或 .flaskenv 文件。
- 在 VSCode 集成终端（
Ctrl+`）中执行：flask run（默认http://127.0.0.1:5000） - 指定端口：
flask run --port 8080 - 启用调试模式（含重载）：
flask run --debug（注意：不是--debugger） - 若提示
Could not locate a Flask application，先运行：export FLASK_APP=app.py（Linux/macOS）或$env:FLASK_APP="app.py"（PowerShell）
想用 F5 调试？必须改写 app.run() 启动逻辑
直接在代码里调 app.run() 是调试器友好型写法，但需关闭 Werkzeug 重载器，否则仍会冲突。
- 在
if __name__ == "__main__":块中写：app.run(debug=True, use_reloader=False) -
use_reloader=False是关键——它禁用子进程重载，让调试器能完整接管主进程 - 此时 F5 启动可打断点、看变量、单步执行；热重载功能由 VSCode 的
Python Extension的文件保存自动重启（需开启"python.defaultInterpreterPath"正确指向虚拟环境）补偿 - 避免写
app.run(host='0.0.0.0', port=5000)——生产环境暴露地址会引发警告，开发时也无必要
launch.json 配置要点：只对真正需要调试入口的场景
仅当你有复杂初始化逻辑（如数据库连接、配置加载）且必须在调试器中逐步验证时，才值得配 launch.json。
- 模板配置（放在
.vscode/launch.json）：
{
"version": "0.2.0",
"configurations": [
{
"name": "Python: Flask",
"type": "python",
"request": "launch",
"module": "flask",
"args": ["run", "--no-debugger", "--no-reload"],
"env": {
"FLASK_APP": "app.py",
"FLASK_ENV": "development"
}
}
]
}
--no-debugger 和 --no-reload 是必须项，否则调试器无法稳定 attachenv 中的 FLASK_APP 必须是文件名（如 app.py），不能带路径或后缀以外的扩展env 变量可能被忽略，优先用 CMD 终端或改用 .flaskenv
真正的难点不在怎么启动，而在于区分「调试逻辑」和「服务运行」——前者要让代码停得住，后者要让服务活得久。很多人卡在反复修改 debug 开关却没意识到，Werkzeug 的重载器和 VSCode 的调试器本质上是两个独立的进程管理器，硬凑一起只会互相掐架。
