Dapr CLI运行FastAPI应用启动后立即退出如何解决

这个问题的核心逻辑是：Dapr sidecar 进程的生命周期和它绑定的业务进程强绑定，只要业务进程没有正常常驻运行，Dapr 进程就会在启动后直接退出，不会单独挂着。按以下顺序排查即可：

• 先校验 dapr run 命令写法是否正确
  最常见的错误是漏写业务启动命令、漏传--app-port参数，正确的启动命令参考：

  dapr run --app-id fastapi-demo --app-port 8000 -- uvicorn main:app --host 0.0.0.0 --port 8000
  

  注意三个必填规则：
  • --app-port 的值必须和 FastAPI 实际监听的端口完全一致，和后面uvicorn指定的--port参数值对齐
  • Dapr 参数和业务启动参数之间的--分隔符不能省略，分隔符后面写你平时正常启动FastAPI服务的完整命令
  • 不要把业务进程的启动参数写到分隔符前面，否则Dapr不会拉起对应的业务进程，自然启动完就直接退出
• 脱离Dapr验证FastAPI本身是否能正常常驻
  直接在命令行执行你的FastAPI启动命令（比如上面的uvicorn main:app --host 0.0.0.0 --port 8000），看服务能不能正常挂住：
  • 如果直接启动就退出，先解决FastAPI本身的问题：常见原因包括启动入口文件路径错误、app实例名拼写错误、启动阶段抛出未捕获异常、端口被其他进程占用、代码里主动调用了进程退出逻辑
  • 如果直接启动能正常常驻、访问接口正常，再回到Dapr参数层面排查
• 开调试日志定位具体报错
  在dapr run命令里加--log-level debug参数打印全量日志，重点排查两类报错：
  • Dapr sidecar本身的报错：比如端口监听失败、应用健康探测失败、配置文件加载错误
  • 业务进程拉起时的报错：比如Python依赖缺失、文件权限不足、环境变量未配置导致FastAPI启动失败
• 高频踩坑点核对
  • 调试时如果给uvicorn加了--reload热重载参数，部分低版本Dapr CLI和热重载的子进程拉起逻辑存在兼容问题，验证时可以先去掉--reload参数，生产环境本身也不建议开启热重载
  • 启动命令里不要加后台运行符号（比如Linux/macOS下的&），会导致Dapr检测不到业务进程的常驻状态直接退出
  • Windows环境下如果遇到命令解析问题，直接用python -m uvicorn main:app --host 0.0.0.0 --port 8000作为业务启动命令，不要嵌套使用PowerShell的进程启动指令

内容的提问来源于stack exchange，提问作者AmineBA