不看好，因为请求合并了就意味着无法区分主次，服务器端也需要一口气准备所有数据，这样传输的并行还是查询的并行都更难实现。
更不用说，很多时候服务器端是需要对特定的 crud 做优化的，需求放这么开的话这种优化也更困难了。

@LeeReamond 另外这个泄露的问题如果用 uvloop 是不会出现的，同时只能通过重写 asyncio 解决，而重写现在还在进行中。

@LeeReamond Django 系的 orm 大多数时候够用了，可以不用去手写 crud 的，除非你用到了很复杂的用法或者特殊的函数。totorise 作为 django orm 的残品其实也勉强够用，觉得遗憾的地方只是没有新东西，没有 flask 到 fastapi 的那种换代感。
另外你倒是看一下源码啊。

另外 asyncio 应该是大势所趋了，生态在逐步完善，但是距离 wsgi 时代还是有差距的，然而依旧是好兆头。
其实单说 fastapi 也是问题多多的，缺少 session 支持是一个，不完全遵守 asgi 是一个，中间件还有闭包引用不可靠的问题，自带路由是遍历而不是树优化也是一个问题。但即使如此，fastapi 的设计也依然是比 flask 好一些的。
而且其实更大的坑是 orm，gino 和 tortoise 都有各自的坑，django 的 async orm 还在难产，我这边项目用的 tortoise，设计上基本就是抄 django 了，没什么创新点。

另外 techempower 里的 fastapi 代码是有轻微作弊的，主要是 ujson，不过也不严重，你甚至可以用 orjson 跑的更高一点。

我的观点是常量级差距都不用太在意的，fastapi 还有完善的 openapi 支持什么的，那些要更吸引人一点。

fastapi 不是要用 gunicorn 套 uvicorn 吗？ techempower 是开源的，可以去看他们的部署和代码。

用下来的感觉的话，确实 Python 是最方便的，FastAPI 够用而且好用，缺点是一些基础工作涉及底层的话需要对 ASGI 有点了解，比如它没有一个 PHP 式的 Session 支持，还有路由匹配是遍历，没有树优化。

我的建议是即使不要过早优化，也不要去选择性能过低的框架（对，点名 Laravel 、RoR 和 Flask ），同时如果写着费力的话换一个可能比抓着旧工具更实际。

同时你也稍微考虑一下扩张需求，总有一天你需要找人帮你写一部分代码，那时候如果你招聘要求太古怪是不好招人的，所以一些招聘网站上搜不到的框架尽量还是先回避。

标准库都难读的话 ranges 岂不是更魔法文字…

你们不知道甚至 Windows Update 在 win10 下都会带 P2P 上传加速吗…

祝公司的业务稳步前进，收益和全体员工的生活一样幸福美满。

这个主要取决于你经常吃的方便面碗口有多大。

膜主要还是为了滑吧，再加上如果有手机翻扣在桌上的习惯的话，没个膜分分钟刮成花脸，深加工一下去换屏又很不道德，并且只有两次机会。

啊这，没恶意不过你选题这么水的吗，最起码也要去实打实来个注意力模型的行人检测吧。
以及显卡的话拿 colab 跑就行了。

这么大的猫了，应该发二手区。

@murmur Designed By Apple In California，定价高，但赔钱。

如果你确实想搞点有趣的东西的话，试着做个网页游戏怎样？类似泥巴的那种。

@zictos 我是说你取文字图层，填充 backdrop 的马赛克或者高斯模糊就完事了