这是一个创建于 77 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
DeWjjj 77 天前
fastapi 不也有 drf 一样的 api 页面么，这俩没什么差别主要是 django 之前不支持 async ，现在不是也可以 async 了。
所以，除了 django 比较重之外没啥别的问题。 |
 |
2
lambdaq 77 天前  3
还以为有什么长篇大论详细说明好在什么地方呢。。。结果。。。。
|
 |
3
summerwar 77 天前 1
fastapi 的优势在于跟他的名字一样，写 API 比较快，然后连文档直接都可以搞定，侧重点不同。
建议两个都搭建起来体验下，立马就懂了 |
 |
4
chenqh 77 天前
因为 django 要学的东西比 fastapi 多,入门比轻型框架难, 就这样..没有什么其他原因.
|
 |
5
albert0yyyy 77 天前
只写过 drf 和 ninja ，现在好像 ninja 给官方收纳了，我用的 ninja 刚出来，我觉得写起来是真的方便真的快。就 drf 输入输出校验就要写好大一串。
|
 |
6
Rebely 76 天前
drf 和 Django 现有生态结合的好，orm ，filters ，form ，权限 等。缺点就是学习成本稍高，包括 view set 和 mixins 这种类视图，对新手有点不好理解， 不像其他两个看点示例就能用的七七八八。
再有就是 drf 的 serializer 对比起 pydantic 是真的难用啊， 还不止是一点半点。 赶紧参考 pydantic 这种设计 replace 了吧 |
 |
7
LeeReamond 76 天前 1
1. 因为 Django 几个版本迭代后的不兼容更新多，维护体验是狗屎。
2. 因为 drf 笨重的生态中的很多实现不是最佳实践。在大多数时候如果我不愿意背着大量我不需要的功能走，那我愿意做那个重新发明轮子的啥 B ，我的轮子比你的圆，我乐意你管得着么。 |
 |
8
Vegetable 76 天前
因为真的两个都用过很多，知道基于 FastAPI 的项目更容易写出易于长期维护的代码
|
 |
9
acerphoenix 76 天前
drf 帮开发者实现的东西太多了. 增加很多学习成本, 不是我不想学, 而是我都有个实现的认知和方法, 再让我换一套, 尤其团队, 生产环境, 挺困难的
|
 |
10
kuituosi 76 天前
因为 python 的框架是典型的重复造轮子
毕竟 python 开发太简单了，不造轮子不舒服斯基 |
 |
11
moonriver00 76 天前
django 限制太多了，其他的灵活的多
|
 |
12
yph007595 74 天前
@albert0yyyy #5 被官方收纳是啥意思
|
 |
13
metavoidx 67 天前
DRF 的 serializers 确实不好用，太啰嗦了，明明 Python 有类型注解的标准，还方便 IDE 提示和补全
FastAPI 我也用过，写接口方便些，但是太薄了，我还是比较喜欢 Django 的模型层和 QuerySet 所以我自己写了一个后端元框架 [UtilMeta]( https://github.com/utilmeta/utilmeta-py)，用 Python 标准的类型声明来处理接口请求和 CRUD ，可以支持 Django 模型接入（后续也考虑其他的 ORM 框架像 SQLAchemy ），也支持其他的框架作为运行时实现，比如 Flask, Sanic, FastAPI |
|
14
metavoidx 67 天前
@metavoidx 看来 v2 的评论并不支持 markdown 也没法编辑，Github 链接在 https://github.com/utilmeta/utilmeta-py
|
Select Language