FastAPI、Flask、Django三选一：LLM项目Python后端框架选型指南

做后端这些年，身边越来越多朋友开始把 LLM 接进自己的服务里。聊到技术选型时，三句话绕不开 FastAPI、Flask 和 Django 这三个 Python 后端框架。有人纠结 FastAPI 的 async 到底香不香，有人被 Flask 的自由晃得不知所措，还有人觉得 Django 太重不想背。我自己的经验是，这三个框架没有绝对的好坏，关键看你拿它做什么——尤其是当你准备对接 LLM 接口、做 AI Agent、搭一套能扛住并发和流式输出的服务时，选型思维和传统 Web 开发完全不是一回事。

这篇文章我不会去复读官方的 benchmark 数据，也不会只给你一张特性对比表。我会从实际项目视角出发，拆解三个框架在 LLM 开发场景下的真实表现，包括异步和流式输出的处理方式、项目结构怎么摆、部署时容易踩哪些坑，最后再给一套我整理过的选型决策逻辑。适合刚入门想选方向的新手，也适合已经在做 LLM 应用、想换架构或者给别人做技术方案的开发者参考。

1. 三剑客到底在争什么：先看框架设计哲学

很多对比文章上来就列特性清单，什么支持 GraphQL、有没有 Admin 后台、ORM 好不好用，看得人眼花缭乱。但选型之前，你真正要看懂的是每个框架底层的那套设计哲学——它决定了一个项目随着需求增长会走向哪里，也决定了你在 LLM 应用里最关心的那些环节（异步、流式、长连接）能不能舒舒服服地展开。

1.1 FastAPI：异步原生的 API 工厂

FastAPI 的核心卖点就两个：类型注解驱动的请求校验，加上原生的 async 支持。它从底层就是为构建 API 服务设计的，所以你在写路由时天然就在处理 JSON 请求和 JSON 响应，不需要像 Flask 那样自己拼模板、自己决定要不要返回 HTML。

在处理 LLM 接口时，FastAPI 的优点会非常突出。LLM 服务的典型交互是：客户端发起请求、后端转发给模型服务、模型边生成边返回 token。这个过程中的关键操作是 SSE（Server-Sent Events）或 WebSocket，要求服务器能长时间保持连接、同时处理多个请求。FastAPI 的 async 原生能力让它天生适合这种 I/O 密集型场景，只要你的代码里没有阻塞调用，单机能扛住的并发连接数会明显好于另外两个老框架。

我还特别喜欢它对 OpenAPI 文档的自动生成能力。你在类上标一个 docstring，接口的参数约束、返回模型就自动出现在/docs页面里。调 LLM 接口时，尤其是团队协作时，这个能力能省掉不少沟通成本——前端拿着你生成的文档就能直接联调，省得反复问"这个参数是 string 还是 array"。

1.2 Flask：轻量灵活的最小可行方案

Flask 是我最先接触的 Python Web 框架，也是很多人心中"最简单能跑起来"的代表。它的设计哲学是微内核加扩展，你可以在一个文件里写完所有逻辑，也可以按需引入蓝图（Blueprint）来组织模块，一切全凭自觉。

这种灵活在快速原型阶段很有价值。做个小工具、一个内部面板、几台机器上的简单数据接口，Flask 三五分钟就能开工，没有强制目录结构，没有重量级 ORM 的约束，调试特别直观。

但灵活性是把双刃剑。没有强制纪律，意味着项目越大越容易乱。另外需要特别注意的是 Flask 默认的开发服务器是同步的，处理 LLM 流式输出时，每个请求都要占一个线程，并发一高就容易卡。虽说现在 Flask 2.x 也支持了 async 视图，但它的异步是"打补丁"式的，实际效果和 FastAPI 原生异步有差距。如果项目规模到了要上 WebSocket、多路复用、大量并发连接，Flask 会开始让你觉得哪儿都别扭。

1.3 Django：全家桶式的工程化底座

Django 走的是另一条路线：我全给你配好，你就照着规范写。Admin 后台、ORM、Form 表单、Migration 迁移、用户认证体系一应俱全。这种"全家桶"风格在传统业务系统里是巨大优势，比如内容管理、电商、后台管理系统，你基本上不需要操心基础设施，写业务逻辑就行。

但到了 LLM 场景，Django 的优势和枷锁是同源的。它的 ORM 是同步的，虽然 Django 4.x 开始支持 async 视图，但 ORM 底层还是走同步线程池，处理高并发的流式响应时需要额外设计异步任务队列（比如 Celery），架构复杂度一下就上去了。我一直觉得，如果你的 LLM 项目本质上是一个"AI 网关"或者"实时交互服务"，Django 不是最顺手的工具；但如果你做的是一个以数据管理为核心的业务系统（比如 RAG 知识库后台、Prompt 管理平台、Agent 编排后台），Django 能帮你把 CRUD、权限、后台管理这些脏活全部包干，这种工程化能力是另外两个框架完全比不了的。

2. LLM 项目里真正拉开差距的六个维度

三个框架各有各的性格，那到了 LLM 开发这个具体场景，到底哪些维度最容易翻车？我把这几年实际踩过的坑浓缩成六个维度，你可以拿这张表当选型清单用。

2.1 异步与并发：流式输出的生死线

做 LLM 应用的人都知道，等大模型完整生成完再一次性返回，体验差到没法用。现在主流做法是流式返回，token 一个接一个蹦出来，用户那边像打字机一样实时看到答案。这个场景里，服务器的并发处理能力直接决定你的服务能同时服务多少人。

FastAPI 在这一点上的优势是架构级的。它的请求进来后走的是事件循环，不等 I/O，适合的场景就是"大量请求都卡在网络 I/O 上"——恰恰和 LLM 调用完全匹配。你不需要改代码，写上一个async def的接口，里面用 async HTTP 客户端调用模型服务，整个请求周期内占用的系统资源非常少。

Flask 和 Django 处理流式输出，最常见的做法还是"一请求一线程"，线程一多，上下文切换和内存开销都成问题。不是说完全不能做，我之前也用 Django 做过简单的 SSE，用户量小的时候没事，但一旦同时有几十路对话在跑，CPU 就开始坐过山车了。

2.2 请求生命周期与上下文管理

LLM 应用里有个容易被忽略的技术细节：如何管理每个请求的生命周期上下文。比如当前请求用的是哪个 API Key、走了哪个模型、带了什么 system prompt，这些信息需要在整个请求处理链路里始终可访问。

FastAPI 的依赖注入（Depends）机制在这个场景非常顺手。你可以在依赖函数里初始化一个 LLM Client，然后按请求作用域绑定，请求结束自动释放，不需要全局变量，也不怕并发请求互相污染。这种基于类型注解的依赖系统，是我觉得 FastAPI 和传统框架拉开差距的几个点之一。

Flask 用的是请求上下文栈，request、g这类对象可以直接用，逻辑上够用，但如果你自己管理客户端连接池，就容易写出全局单例，埋下并发隐患。Django 的中间件机制也能做类似的事情，但需要自己写额外组件，而且官方风格更倾向于把状态放进数据库做持久化，不是每个请求内临时状态。

2.3 WebSocket 与实时交互

现在很多 Agent 应用不只做流式输出，还要做实时工具调用、状态回传、多轮对话过程中的中间态展示。这些场景下 WebSocket 几乎是标配。

FastAPI 因为走的 ASGI 协议，WebSocket 支持是内置一等公民，函数签名写清楚websocket参数就能接管连接，消息收发可以用await websocket.receive_json()这类原生写法，非常清爽。我做过一个实时 Agent 控制台，后端用 FastAPI 同时管理多个 WebSocket 连接、往指定会话推送日志，代码量比预期少很多。

Flask 做 WebSocket 必须依赖第三方库（Flask-SocketIO），它能工作，但要兼容 WSGI 服务器，本身就是一个比较大的基础设施复杂度。Django 也有 Channels 这个解决方案，功能强大，可是引进来的概念（Channel Layer、Consumer 等）比较多，学习成本和调试成本都高。如果你的项目核心就是强实时交互，选型时不必纠结，FastAPI 在这条路上最顺手。

2.4 数据建模与状态管理

不是所有 LLM 项目都只做"请求转发"。你做 RAG，要存文档块、向量索引、对话历史；你做的 Agent 要是带用户系统，要管 API Key、配额、账单；你做的运营后台，还要统计 token 消耗、请求延迟、成功率。只要涉及这些存储需求，数据建模能力就成了框架的竞争点。

Django 的 ORM + Migration 机制真的是效率神器。定义模型类、跑一次 migrate，表结构就有了，Admin 后台还能直接看数据。我维护过的 Django 项目，为了改一张表字段跑了多少次makemigrations已经数不清了，但从来没为"迁移能不能成功"操过心。

FastAPI 没有内置 ORM，通常要自己选 SQLAlchemy 或者干脆用 NoSQL。这个灵活是优点，但也意味着你得自己兜底数据层的规范和迁移策略。Flask 类似，甚至更散，常见做法是 Flask-SQLAlchemy 配 Flask-Migrate，用起来问题不大，只是没有 Django 那种"一套体系内全搞定"的统一感。

2.5 中间件、认证与网关能力

LLM 应用经常需要做网关层，统一处理鉴权、限流、日志、多模型路由。这个层面要考的，其实是框架的中间件生态和扩展能力。

FastAPI 基于 Starlette，中间件机制非常清晰，全局中间件、路由级依赖、HTTP 异常处理器一应俱全，做网关相当顺手。再加上它天然生成 OpenAPI 文档，很多人直接把 FastAPI 当 LLM 网关底座用，管理和暴露多个模型接口，一个服务全搞定。我在生产环境里用 FastAPI 做过一个类似功能，几个模型（不同厂商、不同版本）的接口统一挂在一个服务后面，按路由分发、做 key 校验和按量计费，整个过程体验非常顺滑。

Flask 的中间件方案传统但是可行，用@app.before_request和@app.after_request就能做通用逻辑，再配合各种第三方库也能完成网关。Django 有真正意义上的中间件体系，做认证、权限、日志都是配置式的，但它的"重"意味着一些简单的网关场景也要按 Django 的规范来组织。

2.6 部署生态与运维成本

部署这块经常被低估。开发的时候一切都好，一上生产才发现麻烦事全来了。

FastAPI 的标准姿势是uvicorn生产部署（前面套gunicorn也行），配置简单，一台机器上起几个 worker，配合 supervisor 或 systemd 就能长期稳定跑。日志方面要特别注意，后面我在踩坑环节会细讲 uvicorn 日志丢的问题。

Flask 传统部署走 Gunicorn + Nginx，流程成熟但多少年没有太大变化，社区文档虽然多，但碎片化严重，有时候要自己拼配置。

Django 部署相对繁琐，除了 Web 服务本身，还要管理静态文件、Migration 执行、Admin 后台资源等，如果走容器化还好一点，裸机部署会比较折腾。好消息是现在 Docker 化之后，这套差距在缩小，但整体来说，Django 的运维心智成本依然是最高的。

3. 实战对照：用三个框架分别写一个 LLM 对话接口

概念说再多，不如直接看代码。下面我用三个框架分别实现同一个需求：一个接收用户消息并转发给大模型的接口，支持流式返回。先说明，我已经把三方 SDK 的调用抽象成一个假的llm.chat_stream()函数，这样你可以只关注框架本身的差别，不用关心具体厂商的 SDK 细节。

3.1 FastAPI 版本：流式输出两三行搞定

FastAPI 做流式输出有专门的对象StreamingResponse，配合 async generator，代码非常干净：

from fastapi import FastAPI from fastapi.responses import StreamingResponse from pydantic import BaseModel app = FastAPI() class ChatRequest(BaseModel): message: str history: list[dict] = [] def llm_chat_stream(message: str, history: list[dict]): # 这里接入真实的 LLM 厂商 SDK，逐 token yield for chunk in fake_llm_stream(message, history): yield chunk @app.post("/v1/chat") async def chat(req: ChatRequest): return StreamingResponse( llm_chat_stream(req.message, req.history), media_type="text/event-stream" )

写这段代码的时候，你可能注意到所有 I/O 都通过async或者 generator 后退让，整个服务不会因为一个请求的长时间输出而阻塞其他请求。这正是 FastAPI 在 LLM 项目里最大的优势：请求生命周期内几乎不占线程资源。

3.2 Flask 版本：短时间内能用，但要小心线程

Flask 早期版本做流式输出用的是Response配合 generator，逻辑也能写通，但生成器里的time.sleep之类操作会卡住线程，并发一高就露馅。Flask 2.2 之后支持了async视图，不过底层依然依赖 WSGI，异步的收益有限：

from flask import Flask, request, Response import json app = Flask(__name__) @app.route("/v1/chat", methods=["POST"]) def chat(): data = request.get_json() message = data.get("message", "") history = data.get("history", []) def generate(): for chunk in fake_llm_stream(message, history): # 这里往往需要考虑线程锁、队列等额外机制 yield f"data: {json.dumps({'delta': chunk})}\n\n" return Response(generate(), mimetype="text/event-stream")

如果只是给自己写个本地调试工具，Flask 完全够用。但坦白讲，在真实生产环境里，这种写法大概率会遇到连接超时、worker 阻塞、扩展困难这些问题。有时候你甚至会怀疑是不是自己的代码写错了，其实问题就出在框架的并发模型上。

3.3 Django 版本：StreamingHttpResponse 与异步改造

Django 做流式输出不是不行，用的是StreamingHttpResponse，逻辑思路和 Flask 类似：

from django.http import StreamingHttpResponse import json def chat_view(request): if request.method != "POST": return JsonResponse({"error": "method not allowed"}, status=405) data = json.loads(request.body) message = data.get("message", "") history = data.get("history", []) def generate(): for chunk in fake_llm_stream(message, history): yield f"data: {json.dumps({'delta': chunk})}\n\n" return StreamingHttpResponse(generate(), content_type="text/event-stream")

这个能跑。但你要记住一个隐藏问题：Django 的 ORM 和绝大多数数据库驱动都是同步的，一旦你的视图里需要操作数据库（比如记录一条对话日志），整个异步链路就被打断了。所以我见到的 Django + LLM 生产项目，往往会在前面加一层 Celery 或者独立的异步服务，把实时转发和高耗时任务分离开，架构上绕一圈才回到正轨。

3.4 三个版本对比后的几条结论

代码看下来，几个结论非常明显：

1. FastAPI 的结构天然贴合 LLM 请求的处理模型，代码量少、语义清晰、并发表现好。
2. Flask 和 Django 都能做流式，但更像是"功能上支持"，不是"设计上原生"。
3. FastAPI 和 Pydantic 的搭配在做请求/响应模型声明时省下大量重复代码。
4. 实际生产项目中，Flask/Django 的 LLM 服务往往需要额外套一层异步框架，与其这样，不如直接把底座换成 FastAPI。
5. 不过注意，代码示例不等于项目最终评判。你的业务如果严重依赖 Django ORM 和 Admin，那就算它处理流式没那么优雅，Django 仍然是整体最优解。

4. LLM 选型决策指南：什么样的项目选什么框架

前面讲完了各自的优劣势，那到底怎么选？我这里不给你万能答案，因为每个项目的约束条件不同。但我会给你一套决策逻辑，按项目形态、团队规模和部署环境三个角度拆解，你对照自己的情况挑最合适的。

4.1 按项目形态选型

先看你要做的东西长什么样，这是最直接的分类方式。

如果你的项目是一个纯粹的 AI 网关、模型代理层、实时对话服务、Agent Runtime，核心诉求是并发、流式、多路复用，那我建议直接选 FastAPI。这类项目的本质是"计算发生在远端，本地只是转发和编排"，FastAPI 的异步模型简直为此量身定制。我做 AI 网关的几年经验也验证了这一点：FastAPI 在这种场景下不仅写起来快，运行时的资源占用也明显舒服。

如果你的项目是一个以数据为核心的业务系统，比如知识库后台、模型配置管理平台、Prompt 仓库、运营数据分析后台，那 Django 是更强的选择。你需要的是一套可靠的模型层、一套现成的后台管理界面、完善的数据迁移工具，这些 Django 全都内置了。核心业务是用 AI 能力做增强，那 Django 的工程化底座能帮你稳定落地。

如果项目介于两者之间，或者只是个人项目、小工具、快速 Demo，Flask 是最平衡的选择。它上手快、资源占用低、可塑性高，适合验证想法。但如果你预测项目会长大，建议趁早切换到 FastAPI 或 Django，避免后续重写成本。

我整理了一张决策速查表，可以直接收藏：

4.2 按团队规模选型

团队情况往往是选型时更现实的约束条件。

三人以下小团队，或者个人开发者，我倾向于推荐 FastAPI。它没有强制规范，团队怎么习惯怎么来，又能覆盖 LLM 项目的核心需求。学习成本也低，Python 基础好一点的同学一天之内就能上手写接口。其次是 Flask，适合已经熟悉它的人，但新建项目我一般建议直接用 FastAPI 而不是再开一个 Flask 老项目。

中等团队，五六人到十几人，有明确分工、需要并行开发多个模块，Django 的强制规范反而成了优点。它约定俗成的 MTV 结构、App 划分、Migration 机制，能让新人快速找到代码位置，降低沟通成本。FastAPI 也适合，但需要团队自行制定一定的项目结构和约定。

大团队、分布式系统架构，通常不会只用单一框架。常见组合是 FastAPI 做网关层，Django 做业务中台，中间用消息队列或事件总线连接。不要试图让一个框架包打天下，各取所长才是正道。

4.3 按部署环境选型

部署环境这块很多人忽略，但它其实影响最终体验。你的服务是部署在 Kubernetes 集群里做微服务，还是部署在几台虚拟机上跑单体，决策方向完全不同。

容器化、微服务架构，FastAPI 是最省心的。它镜像轻、启动快、健康检查配置简单，配合 K8s 的横向扩展能力，几乎不需要额外适配。我们线上一个 FastAPI 服务镜像才一百多 MB，滚动发布十几秒就完成。

虚拟机部署单体应用，Django 的配套更完善。它的管理命令、自定义命令、静态文件处理流程都有成熟方案。Flask 居中，部署也不难。但注意一点，不管选哪个，生产环境都建议在前面放一层 Nginx 做反向代理和 TLS 终止。

如果你要部署在边缘设备或者资源受限的环境中，FastAPI 反而是更好的选择。Uvicorn 本身很轻量，内存占用比 Django + Gunicorn 的组合低很多，在小内存机器上也能跑得动。

5. 实操中踩过的坑：日志丢失、SSE 中断、并发瓶颈

纸上谈兵容易，真实现场才见鬼。这一节我把自己做 Python LLM 服务时踩过的坑整理出来，尤其是热词里提到的 "uvicorn fastapi 日志丢失问题"这类高频问题，希望能帮你绕过去。

5.1 uvicorn 日志丢失问题：别让日志在系统里蒸发

我先说一个很多人都会碰到的诡异问题：FastAPI 项目部署到生产环境后，日志变得不完整，有时候请求日志直接消失，有时候 error 日志找不到。排查了很久才发现，这往往是日志输出级别和 handler 配置的问题，不一定是框架 bug。

常见原因有三个：一是 uvicorn 的日志配置只覆盖了它自己的 logger，你自己项目里的 logger 没有配 handler；二是多个 worker 同时写同一个日志文件时产生竞争，日志被覆盖或者吞掉；三是日志轮转（rotation）配置不当，磁盘满了后旧日志被清理，新日志写不进去。

我的建议是，生产环境不要把日志全寄托在 uvicorn 的默认输出上。用标准的logging.config.dictConfig配置自己的 logger，设清楚 handler、formatter、rotation 策略。多 worker 场景下，要么让每个 worker 写独立日志文件，要么干脆把日志转发到集中式日志系统，从根源上避免混乱。

另一个容易被忽略的点：你在async视图函数里直接用print()或者logger.info()是没问题的，但如果你在某个后台任务里想再次获取 request 对象，很可能拿到的是None，导致日志里缺少上下文信息。解决办法是在请求进来时就把关键信息绑定到contextvars或依赖注入的对象里，避免在异步链路中丢失上下文。

5.2 SSE 连接中断：不是框架的锅，但框架能帮你缓解

流式输出最怕连接中途断掉。调试时看不到完整的响应，用户那边体验也崩了。很多人以为这是 python-web 框架的问题，实际上攻击面在多个层面。

如果用了 Nginx 做反向代理，必须先检查 proxy 的缓冲设置。SSE 要求实时推送，Nginx 默认会缓冲响应，就会导致客户端迟迟收不到数据。你需要把proxy_buffering off打开，同时设置合适的超时参数：

location /v1/chat { proxy_pass http://backend; proxy_buffering off; proxy_cache off; proxy_read_timeout 3600s; proxy_send_timeout 3600s; }

后端为了让连接别被意外中断，可以周期性发送心跳注释行（SSE 协议里以冒号开头的行），比如每 15 秒发一个: keepalive。这个和框架没关系，但在 FastAPI 里写起来最简单，一个async for循环的事。

还有一点提示：如果服务运行在容器里，注意负载均衡器的空闲连接超时设置。很多云厂商默认超时只有 60 秒，对话一长连接就被断，你还以为是自己代码的问题。

5.3 Django 同步 ORM 阻塞：异步视图里的隐形地雷

前面提过 Django 的 ORM 是同步的。如果你在 async 视图里直接访问 ORM，Django 会用同步线程池去执行，这会导致两个问题：一是每个 ORM 操作都要额外切换线程，性能开销大；二是在高并发情况下线程池被耗尽，整个服务响应变慢。

这个坑最常见的出现场景是：你用 Django 做了一个接收 LLM 响应的 API，同时想把 token 消耗记录到数据库。每次请求都写库，数据库操作越来越慢，你的"异步"服务最终变得和同步一样卡。

解决方案有几种：把 ORM 操作拆出去，用 Celery 异步任务去处理；或者干脆把 LLM 网关部分独立成 FastAPI 服务，Django 只管业务数据和后台管理，中间通过 Redis 或消息队列通信。这是我在生产环境里用得最稳的架构方案——两边各干各擅长的，不强求一个框架覆盖所有职责。

5.4 Flask 部署并发上不去：换个跑法，别硬扛

Flask 开发服务器（app.run()）只适合本地调试，这个已经是老生常谈。但还有很多人用 Gunicorn 部署 Flask 时，并发依然上不去，主要原因是 worker 配多了反而互相抢资源，或者配少了扛不住。

我见过一个经典失误：服务器的 CPU 是 4 核，Gunicorn 的 worker 类型用的是默认的同步 worker，还配了 16 个进程，结果 16 个进程互相争抢 CPU 和内存，请求延迟反而更高。

针对 Flask + LLM 接口这种 I/O 密集型场景，可以试试 Gunicorn 的gthreadworker 类型，配置适当的线程数，而不是一味增加进程数：

gunicorn -w 4 --threads 8 app:app -b 0.0.0.0:8000

这样每个进程内能并发处理更多请求。但如果你的服务核心就是流式转发、长连接多，那我还是建议尽早切到 FastAPI，而不是在 Flask 的并发模型上反复做文章。

5.5 常见问题速查表

6. LLM 开发中的高级话题：网关网关、Token 语义与框架无关的通用能力

最后聊几个和框架选择无关，但在 LLM 后端开发中绕不开的通用话题，它们是决定你后端服务智商上限的关键。

6.1 Token 的"三个点"：Key、Query、Value

热词清单里有个很形象的提法：Token 的三个点是 Key（我是谁）、Query（我在找什么）、Value（我能提供什么）。这句话原本是讲 Attention 机制里 QKV 的语义，但在做 LLM 后端时，它也提醒我们注意数据流的设计。

你做 LLM 网关时，每个请求里应该带清楚身份信息（Key），说明意图（Query），以及对应的上下文或数据内容（Value）。在 FastAPI 里可以设计一个统一的请求头结构，比如把X-User-ID作为 Key，把系统 Prompt 和用户消息作为 Query，把 RAG 检索结果作为 Value，这样一套标准化的数据结构可以让模型更好地理解请求，也方便你做日志和分析。

6.2 LLM 网关的设计模式

如果你要做一个对外提供统一接口的 LLM 网关，建议围绕三个功能来设计。第一是模型路由，根据请求参数或用户配置，把请求转发给不同的模型服务商；第二是鉴权与计量，每个请求都要确认 API Key 合法性，同时记录 token 消耗；第三是降级与重试，当某个模型服务不可用时，能自动切换到备用模型，或者按指数退避策略重试。

FastAPI 的依赖注入机制特别适合实现这种网关模式。你可以把鉴权、计量、模型选择分别写成依赖函数，路由里一行声明就能组合起来。如果一个依赖校验失败，整个请求立刻返回 401 或 403，不需要在业务代码里散落判断条件。

6.3 可观测性：别等出了事故再找日志

LLM 应用的可观测性比传统 Web 服务更重要，因为模型输出不稳定，token 消耗有成本，而且链路很长（前端 -> 网关 -> 模型服务 -> 工具调用 -> 返回）。

我的建议是每个请求都在网关层生成一个 trace ID，贯穿所有日志、指标、调用链。无论后续使用哪个框架，都要保证这个 ID 能在日志中随时检索。实际操作上，FastAPI 中可以用中间件给每个请求生成uuid4然后放进请求上下文，Flask 用g对象，Django 用中间件也能实现。

技术选型从来不是选一个最好的框架，而是选一个和你的业务模型最匹配的框架。个人接触 LLM 应用到现在，最有体感的一条经验是：优先看项目的 I/O 特征，再看团队熟悉度，然后才是框架生态。如果你擅长把请求转发、流式输出、高并发生存这些事放在首位，FastAPI 大概率是不会让你后悔的选择；如果你要管的数据和后台很多，Django 的工程化能帮你稳住现场。最后再分享一个小细节：做 LLM 服务时，建议把模型厂商 SDK 的调用单独封装到一个 service 层，别散落在路由函数里。这样无论框架怎么选，后续换模型、换版本、加功能，都只需要动一个文件，这个习惯我从 Flask 用到 FastAPI，再从 FastAPI 用到 Django，一直觉得很值。