fastapi调试断点不命中需改用"module": "uvicorn"模式并指定args为["main:app", "--host", "127.0.0.1", "--port", "8000"]，避免用"program"直接运行main.py导致异步上下文丢失。
FastAPI 调试时断点不命中？检查 launch.json 的 "module" 模式
VSCode 默认的 Python 调试配置用的是脚本路径启动（"program"），但 FastAPI 项目通常靠 uvicorn 启动，直接跑 main.py 会绕过 uvicorn 的生命周期，导致异步上下文丢失、依赖注入失效，断点看似设上了却从不触发。
正确做法是让调试器以模块方式启动 uvicorn：
- 确保项目根目录下有
__main__.py或确认入口是main:app形式（如main.py中定义了app = FastAPI()） - 在
.vscode/launch.json中使用"module": "uvicorn"，而非"program" -
"args"必须显式传入--reload以外的参数，比如["main:app", "--host", "127.0.0.1", "--port", "8000"]；漏掉main:app就等于没指定入口
{
"configurations": [
{
"name": "FastAPI Debug",
"type": "python",
"request": "launch",
"module": "uvicorn",
"args": ["main:app", "--host", "127.0.0.1", "--port", "8000"],
"justMyCode": true
}
]
}
async 函数里打不了断点？确认 VSCode Python 扩展版本和调试后端
旧版 Python 扩展（ptvsd（已弃用）调试器时，对 async/await 的栈帧支持不完整，断点可能停在 await 行但无法进入后续协程体，甚至直接跳过。
必须满足两个条件才能稳定调试异步路由：
- VSCode 安装最新版 Python 扩展（Microsoft 官方，ID：
ms-python.python） - 调试器后端用默认的
debugpy（新版扩展已强制切换，无需手动配） - 避免在
async def函数最外层语句（如第一行print()）打断点——某些 Python 版本+debugpy 组合下，首行断点会失效；移到第二行或函数体内逻辑处更稳
修改代码后热重载失效？别在调试时开双 uvicorn 实例
常见错误：一边用 VSCode 调试（走 uvicorn 模块模式），一边又在终端手动运行 uvicorn main:app --reload。两个 uvicorn 进程争抢 8000 端口，后者失败，前者因没开 --reload 参数而不会响应文件变更。
调试期间要热重载，只做一件事：
- 在
launch.json的"args"里加上"--reload"（注意位置：必须在main:app之后，且不能漏掉引号） - 删掉所有手动启动的 uvicorn 终端进程
-
--reload在 Windows 和 macOS 上正常，在 Linux WSL 中可能需额外装watchfiles（pip install watchfiles），否则提示WatchFiles not available
依赖注入或中间件里断点无效？检查 justMyCode 设置
FastAPI 的 Depends()、中间件、异常处理器常实现在框架内部模块中。默认 "justMyCode": true 会过滤掉所有非工作区代码的断点，导致进不到 dependency.py 或 middleware.py 里。
临时调试这类逻辑，需要放宽限制：
- 把
"justMyCode"改成false（仅调试时改，平时保持true避免进一堆三方库） - 配合
"subProcess": true（如果用了--reload），否则子进程里的断点不会被主调试器捕获 - 改完记得重启调试会话——VSCode 不会热更新 launch 配置
真正麻烦的不是设断点，而是 async + reload + dependency 三层嵌套时，某一层没对齐就全盘静默。多看调试控制台里有没有 Starting debugger process... 和 Connected to pydev debugger 这两行，缺一个基本就是配置漏了。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
