Uvicorn不提供实时请求状态面板，需通过日志调试、进程监控或外挂APM工具（如OpenTelemetry+Jaeger）实现请求状态追踪，因其多进程无状态设计导致单worker日志无法反映全局请求队列。
Uvicorn 本身不提供实时请求状态面板
Uvicorn 是一个 ASGI 服务器，它不内置类似 Nginx 的 stub_status 或 Django 的调试面板。你无法通过访问某个 URL（如 /status）直接看到当前活跃请求数、排队数或 worker 负载——它默认不暴露这类运行时指标。
想看请求是否在处理中？靠日志 + 外部工具定位
Uvicorn 默认只输出访问日志（INFO 级别）和错误日志，不记录“请求开始但未结束”的中间状态。要确认某个请求是否卡住或正在处理，得组合以下手段：
Uvicorn 0.52.1
下载
Uvicorn 0.52.1 是 Python ASGI Web 服务器，提供异步应用服务及 WebSocket 支持，常用于 FastAPI、Starlette 等应用的开发和部署。本下载为官方 PyPI 通用 wheel 包，可使用 pip 安装，并由包管理器处理所需依赖。
- 启用详细访问日志：
uvicorn main:app --log-level debug，会打印started和completed时间戳 - 在业务逻辑里加
logging.info("enter /api/xxx")和logging.info("exit /api/xxx")，注意异步函数要用await asyncio.sleep(0)让日志及时刷出 - 用
ps aux | grep uvicorn查看 worker 进程 CPU/内存占用，高 CPU 可能卡在计算；高 RSS 但低 CPU 可能卡在 I/O 或死锁 - 对长耗时接口，加超时控制（如
asyncio.wait_for(..., timeout=30)），避免请求无限挂起
多 worker 场景下，“当前请求”归属不可靠
每个 uvicorn worker 是独立进程，共享内存不互通。你在 Worker-1 打印的 request_id，在 Worker-2 的日志里根本看不到。这意味着：
- 不能靠单个 worker 的日志推断全局请求队列长度
-
--workers 4时，ps显示 4 个进程，但无法知道哪个正处理你的请求（除非加 trace ID 并统一收集到 ELK/Prometheus） - 用内存 dict 做任务状态缓存（如
task_status = {}）会导致404：因为 POST 提交进 Worker-1，GET 查询可能落到 Worker-2
真正能查“当前请求状态”的方案只有两个
一个是侵入式埋点：在 FastAPI 的依赖或中间件里记录进入/退出时间，并写入 Redis 或内存映射文件（如 /dev/shm），再提供一个 @app.get("/debug/requests") 接口聚合查询；另一个是外挂 APM 工具，比如用 opentelemetry-instrument 启动：opentelemetry-instrument uvicorn main:app，再连 Jaeger 查 span 生命周期。前者轻量但需自己维护，后者开销大但覆盖全链路——多数人卡在这一步，不是不会写代码，是没意识到 Uvicorn 的“无状态”本质决定了它不负责状态可视化。
