Flask、Django、FastAPI、Tornado：Python Web框架选型与实战-平芜编程栈

任何人用Python写后端，迟早都会在Flask、Django、FastAPI、Tornado这四个名字里纠结一次。

我在技术社区潜水多年，见过为选型开会吵三天的团队，也见过拍脑袋选了Django之后把接口开发周期拖到崩溃的小组；还有朋友用FastAPI重写旧接口，性能测试数据好到被领导怀疑造假。这四个框架确实没有谁绝对碾压谁，因为它们的“基因”从一开始就不同——它们各自为不同形态的问题而生。

这篇文章不打算给你一个“标准答案”，我想讲的是选型这件事该怎么思考：先看懂每个框架的底层设计逻辑，再用业务和团队的真实约束去匹配，最后结合我自己踩过的坑，帮你避开那些明晃晃的陷阱。正在做技术选型的同学可以重点看第2章和第3章，刚起步不知道从哪里入手的新手，建议把第4、5章也读完，那里有大量用真金白银换来的经验。

1. 从“身世”看框架：四个框架的基因决定了它们擅长什么

1.1 Flask：把“微”字执行到极致的拼装派

Flask在2010年由Armin Ronacher开源，底层站在Werkzeug和Jinja2两个轮子上：Werkzeug负责WSGI协议的路由分发和请求响应封装，Jinja2负责模板渲染。它把“框架”两个字压到最薄，不塞给你ORM、不塞给你表单验证、更不塞给你Admin后台，一切以扩展的方式按需装配。

你写一个接口，可以只依赖Flask本身，十几行代码就能跑起来：

from flask import Flask, jsonify app = Flask(__name__) @app.route("/api/health") def health(): return jsonify({"status": "ok"}) if __name__ == "__main__": app.run(port=8000)

看起来非常清爽，但这种自由是有代价的。项目稍微变大，你就得自己做一堆“选型”：用Flask-SQLAlchemy还是SQLAlchemy原生？用户登录用Flask-Login还是自己写Session？数据迁移用Flask-Migrate还是Alembic？团队里每个人的选择都可能不一样，最后的项目风格全看第一个写核心代码的人习惯用什么。

所以Flask最适合的场景是：中小型服务、快速原型、内部工具、以及那些你心里很清楚“不会长太大”的项目。它的设计哲学就是“我不会替你决定，你自己来”。这既是优点，也是它很难支撑大型复杂项目的根本原因——需要极强的团队自律才能保证项目不散架。

1.2 Django：全家桶不是缺点，是生产力

Django在2005年从一个新闻网站的运营需求中诞生。这个出身非常重要：新闻网站的特点是频繁的内容维护和多角色权限管理，因此Django从第一天起就把Admin后台、ORM、鉴权系统、表单处理、中间件、信号全部内置。它不是一个“由你组装”的框架，而是一个“什么都替你想到”的平台。

假设你要做一个内容管理系统，Django自带Admin后台意味着你几乎不用写管理界面的代码：

# admin.py from django.contrib import admin from .models import Article admin.site.register(Article)

注册完之后，你就能在/admin路径下对Article表做增删改查。这个功能对内部后台、运营系统、MVP产品来说，节省的开发时间是惊人的。我见过一个小团队用Django三个月做出一套让客户满意的管理系统，其中大量页面直接基于Admin改造，核心精力全放在业务模型上。

Django的ORM也是全家桶里的重头戏。它让你可以用Python对象的方式操作数据库，绝大多数场景不用写原生SQL。但ORM用不好就是慢查询制造机，这一点我在第4章会详细展开。

Django的适用场景很明确：内容管理、后台系统、ERP、CRM、以及任何“CRUD密集型”的业务。它是典型的“约定优于配置”，项目结构统一，新成员上手快，招人也好招——Django开发者之间聊起来，目录结构、模型写法都非常接近，这种标准化本身就是生产力。

1.3 FastAPI：用类型标注重新定义API开发

FastAPI是最年轻的主流选择，2018年问世，作者Sebastián Ramírez是Pydantic库的核心维护者。它选了一条跟前辈都不一样的路：以Python类型标注为中心。你只要把接口参数、返回模型的类型写清楚，FastAPI就能通过Pydantic完成数据校验、序列化，并自动生成符合OpenAPI规范的文档。

写一个带参数校验的接口，体会一下这个设计思路：

from fastapi import FastAPI from pydantic import BaseModel app = FastAPI() class Item(BaseModel): name: str price: float @app.post("/items/") async def create_item(item: Item): return {"name": item.name, "price": item.price}

启动后访问/docs，Swagger UI会自动出现，接口参数、请求体结构、返回格式一目了然。开发完接口根本不用单独维护文档，因为文档是代码生成的。这一点在前后端联调、接口交付场景里简直救命。

FastAPI的另一大特色是原生异步。它基于Starlette，运行在ASGI协议之上，不需要像Flask那样借助gevent或额外封装才能处理并发。再加上依赖注入（Depends）机制，使得参数校验、数据库会话管理、鉴权逻辑都可以声明式地写在一起，代码非常干净。

它最适合的是：前后端分离的纯API服务、微服务、AI模型推理服务、实时数据接口。尤其是团队写接口多、需要高性能、又希望代码好维护的场景，FastAPI基本是当前最优解。但它的异步模型对新手有门槛，用得不对反而会拖垮性能，这一点在第4章必须重点讲。

1.4 Tornado：从网络库长出来的非典型框架

Tornado在2009年由Facebook开源，本质上是FriendFeed的异步网络基础设施，Web框架只是它披在外面的壳。它的立身之本是“非阻塞I/O + 事件循环”，早在asyncio还是第三方库的年代，Tornado就已经用自己的事件循环支撑起了大量长连接业务。

用Tornado写一个WebSocket服务几乎是开箱即用：

import tornado.ioloop import tornado.web import tornado.websocket class EchoSocket(tornado.websocket.WebSocketHandler): def open(self): print("connection opened") def on_message(self, message): self.write_message(message) def make_app(): return tornado.web.Application([ (r"/ws", EchoSocket), ]) if __name__ == "__main__": app = make_app() app.listen(8000) tornado.ioloop.IOLoop.current().start()

如果你要做的是聊天室、实时推送、在线协作这类高并发长连接服务，Tornado在很长一段时间里都是Python界少有的成熟选择。放到今天，如果你既要长连接能力，又要现代开发体验，FastAPI加上原生WebSocket也能做到，但Tornado在网络协议层面的打磨仍然值得尊重。

它的短板也很明显：开发范式与同步思维完全不同，生态跟Django比起来小得多，招人也不容易。另外Tornado从6.0版本开始已经把底层事件循环整合为asyncio，跟Python标准异步生态打通了，但项目里老代码的改造仍然是个长周期过程。

2. 选型不是比参数：业务形态和团队结构才是第一权重

2.1 先回答业务这五个问题

选框架之前，先别急着看性能对比表，回到业务本身回答下面五个问题：

业务是内部后台还是外部API？内部后台有大量表格、表单、权限管理页面，Django的Admin能省一半时间；外部API强调性能、文档、联调效率，FastAPI优势明显。
是请求-响应模型还是长连接模型？普通的HTTP接口四个框架都能做，但如果涉及WebSocket、实时推送，优先考虑FastAPI和Tornado。
业务会长多大？很清楚自己就是个几百人用的内部工具，Flask完全够用；如果是正经的对外产品，还是选个有企业级支撑的框架更稳妥。
交付周期多紧？时间紧、需求还在变，Django的全家桶能让你少操心很多基建；团队成员对异步不熟时，别硬上FastAPI的异步开发模式。
未来几年谁维护？招人能招到什么水平的开发者？“Django开发者遍地都是”这句话在招聘市场上仍然成立，而Tornado开发者的招聘难度可能要高出好几个量级。

我见过最典型的选型失误是：团队只有三个人，而且都是Flask老手，却因为某篇文章说FastAPI性能好，就拍板用FastAPI重写核心服务。结果三个人都不熟悉异步调试，线上一个同步数据库调用把事件循环卡死，服务大面积超时。这不是FastAPI的问题，是选型时根本没考虑团队结构。

2.2 团队真实水平比框架流行度更重要

框架再强，也要团队会用。有一个经常被低估的事实：团队的异步编程、类型标注、设计模式功底，决定了框架能发挥出多少实力。

Django是所有框架里对新手最友好的。它的约定非常统一：你照着官方教程建项目、建App、定义Model、写View，基本上就能交付一个规范的服务。即使成员水平参差不齐，Django的结构会强制项目走向一致性，这大大降低了沟通成本。

Flask则刚好相反，它把架构设计的自由权交还给你，同时也把崩溃的权利交还给你。同一个项目交给两个不同的Flask团队做，代码风格可能完全不同。如果团队有一两个经验丰富的主导者，Flask能写出非常优雅的代码；如果全员都是半吊子，项目最后往往是一场灾难。

FastAPI对团队的“类型意识”要求很高。你在路由函数里写item: Item，IDE就能自动提示字段；你随便写个dict，文档和校验功能就废掉大半。团队如果习惯了“能跑就行”，FastAPI的优势会全部失效，只留下异步回调地狱。

2.3 部署环境是常被忽略的隐形约束

有些项目死在选型阶段之后，是因为部署环境根本跑不动。

服务器内存只有512MB，就别硬用Django + uWSGI全家桶；线上环境是Windows Server，就得避开Gunicorn——它在Windows上原生跑不了，FastAPI建议用Uvicorn，Django可以用waitress。如果生产环境是内网隔离、离线安装依赖，那选型时就得考虑框架依赖的第三方包能不能离线拷贝齐全。

还有一点：Python版本。Django 5.0要求Python 3.10以上，FastAPI最新版对Python版本也有要求。如果服务器上只有系统自带的Python 3.6，你又不允许动系统环境，那很多新框架版本根本装不上。阿里云、腾讯云的很多老机器，系统自带Python还停留在3.6，这类环境约束必须在选型之前搞清楚。

3. 一张表看完核心差异：并发模型、生态和开发效率

3.1 同步、异步与性能的真相

先看并发模型这张表，它是四者差异最深层的分水岭：

框架	协议	并发模型	高性能场景定位
Flask	WSGI	同步，多进程/多线程	常规接口够用，长连接吃力
Django	WSGI（ASGI为补充）	同步为主，异步支持仍在成熟	CRUD业务稳定，高并发需外部组件
FastAPI	ASGI	原生异步	高并发IO密集场景优势明显
Tornado	非阻塞I/O	原生异步事件循环	高并发长连接、WebSocket

很多人看到FastAPI性能好就去迁移旧Flask项目，但没有意识到：性能好不等于无脑快。FastAPI的快，是建立在“你愿意按异步方式写代码”的前提上。如果你在async def函数里写了一个阻塞的requests.get，事件循环一样会被卡住，性能还不如同步框架。

Tornado和FastAPI虽然都是异步，但定位不同。Tornado的底子是网络库，处理长连接的成熟度很高；FastAPI的底子是API开发体验，提供了文档、校验、依赖注入这些现代开发体验。选前者是因为你要做网络层面的东西，选后者是因为你要做业务API。

3.2 数据层、Admin、文档能力的差距

再看开箱能力对比，这块直接决定你的“基建工作量”：

能力	Flask	Django	FastAPI	Tornado
内置ORM	无	有，非常强大	无，常用SQLAlchemy	无
Admin后台	无	有，极强	无	无
自动接口文档	无	部分	有，极强	无
表单验证	无	有	有，Pydantic	无
用户认证	无	有	依赖三方扩展	无

数据层这块必须重点说。Django的ORM和Django的Admin是一套组合拳，管理后台几乎能覆盖运营系统80%的界面需求。而Flask和FastAPI通常要自己接SQLAlchemy，Admin后台需要靠Flask-Admin或者自己写一套前端页面，工作量完全不同。

FastAPI在接口文档上的优势是无敌的，启动服务就有/docs和/redoc两个自动生成的文档界面。我在给第三方合作伙伴交付API时，直接把文档URL发过去，对方连问都不用问就能对接。换做Flask，你得靠flask-restx或者手工写Markdown文档，维护成本高一个量级。

3.3 学习曲线与开发效率的真实体感

学习曲线的跨度从“半天上手”到“一个月入门”，差别非常大。

Flask的学习曲线最平缓。你只需要理解路由、请求、响应、模板这四个概念，就能写出能用的服务。但往上走，从“能用”到“架构不乱”之间的跨度其实是最大的，因为没有人告诉你项目该怎么组织。

Django的入门门槛高一些，要理解Model、View、Template、Admin、Migration这套体系，刚接触会觉得别扭。但一旦跨过这道坎，开发CRUD业务的感觉就像在流水线上工作，效率极高。说实话，Django的开发效率在四个里面排第一，这句话我说得很有底气。

FastAPI的入门门槛看起来低——写个接口只要几行代码——但真正的门槛在异步。你得搞清楚async def和def的区别，搞清楚事件循环的阻塞点，否则写出来的服务性能不稳定。好在自动文档和类型提示带来的体验确实好，一旦入了门越写越顺。

Tornado的门槛最高，不是语法难，而是思维模式完全不同，你得时刻想着“我不能阻塞事件循环”。新手如果一上来就学Tornado，很容易被异步概念劝退。

4. 实战中的坑：每个框架最容易翻车的场景

4.1 Flask：循环导入和应用上下文的两大经典问题

Flask项目稍微一大，最常见的翻车现场就是循环导入。app.py里导入models模块，models.py里又想导入app来用db，程序一跑就报ImportError，两个文件互相等对方先加载，谁都没法成功。

解决办法是放弃“在模块顶层创建app”的写法，改用应用工厂模式：

# app/__init__.py from flask import Flask from extensions import db def create_app(config_name="default"): app = Flask(__name__) db.init_app(app) from .routes import api app.register_blueprint(api) return app # run.py from app import create_app app = create_app()

把Flask实例放进create_app函数内部，所有扩展都先初始化为全局对象，再通过init_app绑定到应用上。蓝图（Blueprint）也是Flask项目规范化的关键，项目里只要有三五个以上路由，就别再全部堆在app.py里了。

另一个高频坑是“Working outside of request context”。Flask的request、session这些对象是依赖请求上下文的，离开了请求生命周期去访问它们，就会报这个错。最常见的情况是在普通函数或后台任务里尝试拿request的数据。正确做法是：要么把请求期需要的数据作为参数传入后台任务，要么用app.app_context()手动创建上下文。记住，后台任务不是请求，它不应该依赖request。

4.2 Django：ORM的N+1查询与级联删除陷阱

Django的ORM确实好用，但几乎每个新人都会栽在N+1查询上。看这段代码：

books = Book.objects.all() for book in books: print(book.author.name)

表面上只执行了一次SELECT * FROM book，实际在循环里每访问一次book.author，ORM就执行一次作者表的查询。book有1000条记录，数据库就会被查1001次。修复方法很简单，用select_related或prefetch_related预取：

books = Book.objects.select_related("author").all() for book in books: print(book.author.name) # 这次只有2次查询，主查询 + JOIN

规则很简单：ForeignKey和OneToOneField用select_related，多对多和反向外键用prefetch_related。写Django接口的第一步，就是检查列表和详情接口有没有预取关联数据，这一步能避免90%的慢接口问题。

还有一个特别容易忽略的坑：QuerySet.delete()是批量删除，返回的不是一个数字，而是一个元组(总删除数, {'app_label.Model': 删除数})，而且默认会级联删除所有外键关联的数据。热搜词里正好有“django执行查询-删除对象”，说明踩这个坑的人不少。删除一个作者，他写的所有文章可能全被连带删掉，而且这个过程不可逆。

# 这样删，会级联删除该作者关联的所有文章 Author.objects.filter(name="张三").delete()

如果你只想删除作者、保留文章（把文章挂到其他作者或置空），必须在模型的外键字段上明确设置on_delete的行为，比如on_delete=models.SET_NULL，同时保证该字段可空。设计模型字段时，on_delete的选择绝不是顺手填的，它决定了数据生命周期里最危险的边界行为。

4.3 FastAPI：同步阻塞与热更新不生效

FastAPI性能强大的前提，是你别在异步代码里写同步阻塞调用。看这个反面教材：

@app.get("/data") async def get_data(): result = requests.get("https://external.api/data").text # 阻塞了事件循环！ return {"data": result}

async def跑在事件循环上，里面如果写requests.get这种同步IO，整个事件循环会被卡住。这段代码执行期间，服务器上其他所有请求都得排队等它完成，并发能力直接归零。解决办法有两个：

换成异步HTTP客户端，比如httpx.AsyncClient：

import httpx @app.get("/data") async def get_data(): async with httpx.AsyncClient() as client: resp = await client.get("https://external.api/data") return {"data": resp.text}

如果同步代码很难改，干脆把路由函数定义成普通def，FastAPI会自动把它丢进线程池执行，不会阻塞事件循环：

@app.get("/data") def get_data(): # 这里可以放心用 requests，FastAPI会把它放到线程池 result = requests.get("https://external.api/data").text return {"data": result}

老实说，这两个方案我都在生产环境用过。原则是：异步函数里只放await的异步调用，拿不准的时候就退回到同步def，让框架替你处理线程调度。

热搜里“fastapi启动不热更新”也戳中了很多人的痛点。uvicorn main:app --reload理论上会自动监听文件变化，但不生效的场景很常见。我排查过的案例里，原因集中在几个方向：

代码在Docker容器里，宿主机文件通过卷挂载进去，容器内inotify事件丢失，--reload没反应。
PyCharm或VS Code的“安全写入/原子保存”功能导致文件被替换而不是被修改，监听器没触发。
项目运行目录和代码目录不一致，需要在命令里加--reload-dir ./app显式指定监听目录。

临时解决可以装watchfiles，它是Uvicorn目前依赖的文件监听后端，版本不匹配也会导致热更新失效。升级或固定版本之后，问题通常能解决。但说到底，--reload只是开发期的效率工具，生产环境千万别开，这一点应该成为肌肉记忆。

还有一个值得提的点：Pydantic从v1升级到v2之后，配置项变了。以前模型里的orm_mode = True，现在要写成：

from pydantic import BaseModel, ConfigDict class UserOut(BaseModel): model_config = ConfigDict(from_attributes=True) id: int name: str

用于把SQLAlchemy或Django ORM对象直接序列化成响应模型。很多人升级后接口突然报错，都是踩了这个配置项迁移的坑。

4.4 Tornado：思维不切换，性能就是负的

Tornado的坑，一句话概括：用同步思维写异步框架，性能比同步框架还差。

比如在Tornado的async def get里写time.sleep(1)，这个操作会直接卡住整个IOLoop事件循环，所有连接都会停顿。应该用await tornado.gen.sleep(1)：

class MainHandler(tornado.web.RequestHandler): async def get(self): # 错误：time.sleep(1) 会阻塞所有连接 await tornado.gen.sleep(1) # 正确：异步睡眠 self.write({"msg": "ok"})

只要是涉及IO的操作——文件读写、网络请求、数据库访问——在Tornado里都要用异步版本。文件读写可以用tornado.ioloop.IOLoop.run_in_executor丢到线程池；HTTP请求要用AsyncHTTPClient；数据库要选支持异步的驱动。

如果你手里已经有一套基于Tornado的老系统，评估重构成本时千万别低估工作量。几个半夜处理线上事故的经历告诉我，Tornado项目非常适合“稳定之后就冻结功能”的运营策略，新需求尽量不要往里塞同步逻辑，宁可单独拆一个小服务出来。

5. 热搜背后：环境搭建和部署是最大的拦路虎

5.1 首先搞定Python环境：从虚拟环境到pip换源

热搜榜上“python安装”“python安装教程”“linux系统安装python”反复出现，说明环境问题依然是很多人的第一道坎。我见过太多项目的第一个线上事故，就是因为在系统Python环境里装了乱七八糟的包，把系统依赖搞崩了。

正确做法只有一个：虚拟环境。无论是venv还是conda，核心思想都是把项目依赖隔离起来，不进系统环境。

python3 -m venv venv source venv/bin/activate pip install flask django fastapi tornado

创建虚拟环境之后，环境里的pip就别再直接指向官方源了。国内网络环境下，用清华或阿里云的镜像源，下载速度快几个量级：

pip install -i https://pypi.tuna.tsinghua.edu.cn/simple flask

想一劳永逸，可以修改pip配置文件。Linux和macOS在~/.config/pip/pip.conf，Windows在%APPDATA%\pip\pip.ini，写入：

[global] index-url = https://pypi.tuna.tsinghua.edu.cn/simple trusted-host = pypi.tuna.tsinghua.edu.cn

新装的Python默认版本如果过新，也要注意别乱动系统环境。记住一个原则：系统自带Python是系统的东西，项目代码永远跑在虚拟环境里。这个原则能帮你避开无数坑。

5.2 国产Linux环境下的Django/FastAPI部署要点

“python django 麒麟”出现在热搜里，说明在国产Linux环境下部署Django已经是非常普遍的需求。这类系统有几个共同特点：自带Python版本通常偏老，很多还是Python 3.6或3.7；软件源不如社区发行版全；ARM架构（aarch64）机器越来越多，二进制wheel包缺失的情况很常见。

如果你要在这类环境下跑Django 5或最新FastAPI，第一件事往往是得到一个版本合适、能正常编译第三方库的Python。源码编译时，编译依赖要提前装齐，否则会出现各种奇怪的错误：

sudo apt install -y build-essential zlib1g-dev libssl-dev libffi-dev libbz2-dev libsqlite3-dev

装好后编译安装新Python到指定目录：

./configure --prefix=/opt/python3.11 make -j$(nproc) sudo make install

ARM环境下最棘手的是二进制wheel缺失。Pillow、lxml、psycopg2这些库经常没有aarch64的预编译包，源码安装又需要本地的开发头文件。我的经验是提前打好这块补丁包：libjpeg-dev、libxml2-dev、libxslt1-dev、libpq-dev，缺什么编什么，逐个击破。

部署结构上，Django和FastAPI的生产方案已经非常成熟：

Django：Nginx（静态文件+反向代理） + Gunicorn/uWSGI（应用进程） + 数据库
FastAPI：Nginx（反向代理） + Uvicorn或者Gunicorn的uvicorn worker（应用进程） + 数据库

如果用Gunicorn，需要确认你的代码目录、虚拟环境、启动参数都正确。一个常见的坑是Gunicorn从默认全局Python启动，没有加载项目的虚拟环境。解决办法是直接指定虚拟环境里的Gunicorn路径：

/path/to/venv/bin/gunicorn -w 4 -b 0.0.0.0:8000 myproject.wsgi:application

Nginx配置反代到8000端口后，记得处理好静态文件的alias，Django的collectstatic要执行，否则后台CSS样式全丢，页面难看得让你怀疑是浏览器问题。

5.3 从“ModuleNotFoundError”到PEP 668：常见报错排查

环境问题的表象千奇百怪，本质通常逃不出几类。我直接给一个排查思路表格，这是我在实际支持中反复用到的：

报错现象	常见原因	处理思路
`ModuleNotFoundError: No module named 'flask'`	没装包，或装到了别的环境	先激活虚拟环境再执行`pip list`，确认包确实存在
`error: externally-managed-environment`	新版pip保护系统环境（PEP 668）	永远用虚拟环境，不要用`--break-system-packages`硬装
`pip install xxx`超时或报SSL错误	访问官方源慢或网络受阻	换清华/阿里镜像源，参考5.1节
编译安装时报`No matching distribution`	平台没有对应wheel包	安装编译依赖后源码安装，或降级到有wheel的版本
服务起来了但端口不通	防火墙或绑定了127.0.0.1	绑定`0.0.0.0`，检查云安全组和防火墙规则

关于PEP 668，多说一句。新版的Debian、Ubuntu系统上直接pip install会报externally-managed-environment，这是系统在保护自己，防止pip破坏包管理器维护的Python环境。正确做法是python3 -m venv venv创建并激活虚拟环境，在虚拟环境里装任何包都不会有这个报错。

如果是在Windows上部署Django，Gunicorn用不了，我建议用waitress：

pip install waitress waitress-serve --port=8000 myproject.wsgi:application

Windows上如果遇到端口被占用、路径分隔符导致的配置错误，优先检查settings.py里的路径拼接是否用了os.path.join，而不是硬编码的/或\。这些小细节看着不起眼，线上出问题时的排查成本特别高。

还有一点值得强调：pip freeze > requirements.txt导出的依赖清单，在另一台机器上安装时经常会遇到版本冲突。更可控的方式是使用pip-tools的pip-compile来生成锁定版本的文件，或者直接用poetry、uv这类依赖管理工具。环境一致性这件事，越早重视，后面越省心。

我自己在同时维护Django和FastAPI两套线上服务时，最大的体会是：无论框架选得多好，环境管理不规范都会让每个框架都很难用。先把Python版本、虚拟环境、依赖源、部署脚本这四件事钉死，框架本身的差异才会真正显现出来。

选型这件事，说到底是把你手头的业务翻译成框架擅长的领域。我做技术咨询时很少直接替客户做决定，通常是问清楚业务规模、团队底子、部署约束之后，把四个框架的匹配度摆出来让团队自己感受。如果非要给一个朴素建议：拿不准的时候，花两三个小时把四个框架的最小Demo都跑一遍，感受一下路由、数据模型和接口文档的手感，这种亲身体验比看一百篇对比文章都管用。框架是工具，你拿它的手感顺不顺，只有自己试了才知道。