@jtsai 果然对标的只有 C#吗，感觉香是真的香，但是国内也确实冷门了点。

@tabris17 本身语言性能低吧，ASGI 也就比 WSGI 快一倍左右。
倒是 Spring 和 Gin 的跑分很低这件事让我蛮惊讶的。

给注释一个编译期语义真是我见过的最蠢的设计了——什么，是 go 啊，那没事了，挺正常的。

不好说的，主要是因为 m1 的待机功耗实在是太低了，是毫瓦级别的，intel 目前还做不到这么低。

@helloworld000 因为开源产品更不容易做恶吧。

@Tumblr 我投赞成，因为云输入提供的不是一个更大的词库，而是一个简便地跳过拼写生僻名词的方式。

说实话很希望这款输入法能添加云输入功能，我记得安卓上已经有开源输入法支持调用各家的云输入了。

@zyzll1234 embody 对颈椎支撑舒服？它不是没有头枕也没办法装头枕吗…我这边 embody 最多能说让肩膀好受一点。

雅黑比不上苹方我可能还信，比不上思源…中宫大了点就这么不受待见吗

aiohttp 到 fastapi 的重构没啥意义的，除非你原本代码真的稀烂到一点功能都加不进去了。
不然你还是去用 gin 一类的 go 框架重构吧。

@IGJacklove V2EX 的屏蔽词和访问权限是按用户的注册时间等信息去隐藏区分的，并不是全体用户一碗水端平的。

比如我记得 /go/shadowsocks 只允许注册 999 天以后的人访问。

@LeeReamond FastAPI 主要是省事和优雅，它的 API 总体上是 Flask 风格的，可以提供 OpenAPI，也可以用 Pydantic 做自动的输入验证，还可以用依赖注入的方式比较方便地实现鉴权，总的来说就是好用，并且性能代价不高。

不过大型 Web 应用估计还是不适合用 Python，但是能在被迫用 Java 或者 Go 重写之前撑更久。

@LeeReamond 说实话我已经多次和你说去看源码了…
https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/Python/fastapi/fastapi-orjson.dockerfile

不看好，因为请求合并了就意味着无法区分主次，服务器端也需要一口气准备所有数据，这样传输的并行还是查询的并行都更难实现。
更不用说，很多时候服务器端是需要对特定的 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 支持什么的，那些要更吸引人一点。