我被一个奇怪的问题困扰了很久

你有没有想过：为什么你的 Python Web 框架花那么多时间在处理那些跟你的业务代码八竿子打不着的事儿？

FastAPI 底层跑着 Starlette，Starlette 跑在 uvicorn 上，uvicorn 又封装了一个 asyncio 事件循环，在 socket 和你的处理器之间来回倒腾。每一个请求——在它真正到达你的业务逻辑之前——要穿越好几层 Python 代码，做序列化，走路由，这些流程对每个请求来说都是一模一样的。

那有没有一种可能，让这一切都变个样？框架那部分——不管你做什么应用都得跑的那些重复代码——能不能全都交给 Rust 来干？Python 就只管那些真正跟你的业务有关的代码？

这就是 JustAPI 这个项目的出发点。折腾了一阵子之后，我觉得这事儿值得好好聊聊，不光是它做了什么，还有它背后的架构思路，说不定对你接下来的项目有启发。

性能数据背后的真相

先别急着看架构，咱们来聊聊数字——因为抛开上下文谈性能，那就是在吹牛，不是工程。

这个项目在最基本的 hello world 测试里跑出了每秒 76.6 万次请求的成绩。路由查找在 500 条路由配置下只需要大约 51 纳秒。改用多线程 Tokio 加上无锁 CPython 之后，异步吞吐量直接翻了 14 倍。

这些数字对你意味着啥？如果你接的 API 每秒要处理几千个请求，这些提升会累积起来。延迟低了，用户等的时间就短。吞吐量高了，服务器能扛的负载就大。但说实话，最关键的不是这些原始数字，而是你不用再操心的那些东西。

不用管 uvicorn，不用管 Gunicorn，不用管半夜三点出问题要去排查的那堆 ASGI 中间件。整条请求链路都在 Rust 里跑，你的 Python 代码就只是……你的代码。

架构思路：Python 是例外，不是默认

请求的路径是这样的：内核（epoll/io_uring）→ Tokio 连接管理器 → rustls 加密层 → Hyper 解析 HTTP → 路由（matchit 基数树）→ 中间件链（认证、CORS、限流）→ 通过 PyO3 跨入 Python → 你的处理器 → Rust 序列化 → 响应。

注意到 Python 从哪儿开始介入了吗？只有在你应用逻辑真正开始的地方。之前的所有环节——那些对每个请求都一模一样的部分——全都是 Rust 在跑。

这个区别很重要。JustAPI 的开发者在开发过程中给自己定了个规矩：一个功能如果能用 Rust 实现，那就必须用 Rust 实现。不是"用 Rust 能更快"，是"能用 Rust 实现"。Python 只用来粘合 Rust 的值和你的处理器。

这条约束贯穿了整个项目，最后做出来的东西跟那些只是把 Rust 片段拼进去的其他 Python 框架确实不太一样。

这对你的开发体验意味着什么

我觉得这个方案对创业公司和成长型团队特别有意思。

你得到的是一个完整的 API 框架——HTTP/1.1 和 HTTP/2、TLS、带参数的路由、JSON 序列化、自动生成 OpenAPI 文档——代码只需要 30 行，看起来就是纯正的 Python：

from justapi import JustAPIApp

app = JustAPIApp()

@app.get("/")
def hello():
    return {"Hello": "World"}

app.run()

但在这层熟悉的外表底下，跑的是一个 Rust 服务器，处理 TLS、管理连接、序列化响应，全程不踏入 Python 半步。开发体验是 Python 的味道，运行时性能是 Rust 的水准。

对于那些现在做 MVP、以后可能需要扩容的团队来说，这很关键。你今天用 Python 写代码。等哪天负载上来了，不用重写任何东西就能获得 Rust 的性能。

AI 这个工程搭档，不是替代者

这个项目是把 AI 当成真正的参与者来做出来的——不是用来补全代码那种，是当工程师搭档用的，帮着设计架构、把决策转成代码、找 bug、写测试。

这事儿值得坦诚聊聊，因为它越来越常见，但很少有人正儿八经说清楚。

开发者把代码库分成三层：完全理解的部分、足够维护的部分、还有 AI 写的、他审查过测试过但没法凭记忆复现的部分。他很坦白地说这就是项目存在的方式。

我觉得这个态度是对的。AI 工具确实在加速复杂项目的开发，装不知道对谁都没好处。关键是要清楚自己掌控了什么、委托了什么——而且要对这二者保持诚实。

说点实在的

像 JustAPI 这样的框架代表了一种思路的转变：Python 在高性能系统里该扮演什么角色。Python 不会消失，它的可读性和生态太值了。但"框架本身必须在 Python 里跑"这个假设正在被挑战。

不管 JustAPI 最后会成为你的下一个框架，还是只是一个有意思的实验，它背后的思路是有价值的：看看你整个技术栈里哪些部分每个请求都在跑一模一样的东西。那大概就该用 Rust。而那些会变化的部分？用什么语言你团队用得顺手就用什么。

"能用"和"用得好"之间的差距一直在缩小。你的用户不会注意到架构，但他们会注意到延迟。

往后看

JustAPI 现在是 2.0.10 版本，功能已经比较齐全了：WebSocket、SSE、后台任务、调度器、通过 SQLx 访问数据库，还有 OpenTelemetry 和 Prometheus 监控这些运维工具。PyPI 上有包，支持 Linux、macOS、Windows 以及无锁 CPython 3.14t 版本。

数据都在仓库里放着，测试都通过了，失败的地方也有文档。这种工程上的透明值得我们多鼓励。

如果你在写 Python API，性能又是你关心的，值得去看看。Python Web 框架的未来，说不定跟你现在用的完全不是一个样。