这是一个很尖锐的问题，也是面试官特别喜欢追问的。我会帮你理清思路，让你在面试时能从容应对。
一、先承认，再反转：FastAPI 到底“弱”在哪，强在哪？
面试官说它“功能最弱”，通常是指它自带的东西少：
- Django 自带 ORM、后台管理系统、用户认证、表单验证，开箱即用。
- Flask 虽然轻量，但有大量成熟的第三方扩展。
- FastAPI 几乎什么都没有，只有一个核心的 HTTP 框架。
但它最强的两点恰恰是其他框架的短板：
- 原生异步支持：Flask 是同步的，Django 的异步支持是后来加的，用起来别扭。FastAPI 从设计之初就是异步的，与 Python 的
async/await完美融合。 - 自动生成 API 文档：写完代码就有 Swagger UI，前端开发者和测试人员可以直接在浏览器里调接口，非常方便。
二、为什么我的系统选 FastAPI？三个核心原因
原因一：场景匹配——大量 I/O 密集型操作
我的系统有大量耗时操作：启动浏览器、等待页面加载、调用大模型 API、读写文件。这些操作本身快不了，但如果用同步框架，服务器在等待这些操作完成期间，完全无法处理任何其他请求。用异步框架，等待的时候服务器可以去处理别的请求，不浪费时间。
一句话总结：我的系统瓶颈不是计算，是等待。FastAPI 的异步能力让服务器在等待时不至于完全瘫痪。
原因二：接口数量少，不需要 Django 全家桶
我的系统只有 5 个 API 接口。没有数据库、没有用户系统、没有复杂权限管理。如果用 Django，我需要配置 ORM、settings、admin、middleware……这些对我来说都是多余的。FastAPI 让我只需要关注接口逻辑本身，代码简洁，开发快。
一句话总结：对于一个毕设系统来说，5 个接口就用 Django 全家桶，像用大炮打蚊子。
原因三：API 文档自动生成，前后端联调效率高
我写完后端接口，FastAPI 自动在 /docs 路径生成一个 Swagger UI 页面。前端同学可以直接在上面看到所有接口、参数格式、返回示例，还能在线发请求测试。这比手动写文档、或者在 Postman 里一个个配置要快得多。
一句话总结：开发效率高，调试方便，适合快速原型开发和小团队协作。
三、为什么不选其他框架？
| 框架 | 为什么没选 |
|---|---|
| Django | 太重了。自带 ORM、模板、用户系统，我的系统没有数据库和复杂页面，用 Django 要关掉一堆默认功能，反而麻烦。异步支持也不是原生级的。 |
| Flask | 太同步。Flask 是 WSGI 框架，虽然可以通过扩展做异步，但体验不自然，而且性能远不如原生异步的 FastAPI。 |
| Tornado/Sanic | 太小众。社区生态、文档、第三方库都不如 FastAPI 丰富，遇到问题不好找资料。 |
四、面试回答模板
面试官：FastAPI 功能最弱，你为什么选它？
你：确实，FastAPI 自带的功能少，但我的系统场景恰好不需要那些重量级功能。我的系统只有 5 个 API 接口，没有数据库、没有用户系统，Django 全家桶对我来说是负担，反而增加开发成本和启动时间。
最关键的是，我的系统有大量 I/O 密集型操作——Selenium 操控浏览器、调用大模型 API、文件读写。FastAPI 原生异步支持让我可以用
async/await和asyncio.to_thread把这些操作异步化，服务器在等待时不会阻塞，能继续处理其他请求。Flask 做同步没问题，但做异步很别扭，Django 的异步支持也是后来才加的。另外，FastAPI 自动生成 Swagger API 文档，前端和测试人员可以直接在浏览器里调接口，开发效率非常高。所以综合场景匹配、异步性能、开发效率三个维度，FastAPI 是我最合适的选择，而不是功能最弱。
贡献者
freeway348