2019年 FastAPI 横空出世，靠着类型注解自动生成文档、Pydantic 数据验证、异步支持，几乎在一夜之间成为 Python 后端开发者的首选。

然后到了2023年，有人悄悄把一个叫 Starlite 的框架彻底重写，改了个名字：Litestar。

它的口号很直接：

比 FastAPI 快，功能比 FastAPI 多，设计比 FastAPI 更规整。

这不是标题党——基准测试数据就摆在那里，序列化速度约是 FastAPI 的 2 倍，内存占用更低，启动更快。更重要的是，那些你在 FastAPI 里需要找第三方库才能解决的问题，Litestar 直接内置了。

Litestar 是什么？从哪来的？

Litestar 的前身叫 Starlite，和 Starlette（FastAPI 的底层框架）名字像但完全不是一回事。

一开始 Starlite 也是基于 Starlette 构建的。但随着开发深入，团队发现 Starlette 的架构限制了他们想做的事——于是干脆把 Starlette 依赖完全移除，从头重写了底层，发布 2.0 版本时同步改名为 Litestar。

它的定位不是微框架，也不是全栈框架，而是"电池充足的高性能 ASGI 框架"：

• 轻量级框架的性能
• 全栈框架的功能覆盖度
• 企业级项目的架构规范支持

目前 GitHub 星标超过 5000，社区在快速增长，核心维护者代码质量要求极高，贡献门槛比 FastAPI 更严格。

为什么比 FastAPI 快？核心在序列化

FastAPI 深度绑定 Pydantic，请求进来、响应出去，都要经过 Pydantic 的验证和序列化流程。

Pydantic v2 已经很快了，但它是一个通用验证库，本质上验证和解码是两个分开的步骤。

Litestar 的默认序列化引擎是 msgspec——一个专门为序列化设计的库，核心逻辑用 C 写的，验证在解码的同时完成，不是两步而是一步。

实测对比数据：

当然，Litestar 也支持 Pydantic——如果你的项目已经大量使用 Pydantic，可以无缝接入，不用改数据模型，只是不启用 msgspec 的速度优势。

最简单的起步：和 FastAPI 长得像

pip install litestar

Hello World：

from litestar import Litestar, get@get("/")async def index() -> dict:    return {"message": "Hello, Litestar!"}app = Litestar(route_handlers=[index])

启动：

litestar run# 或者uvicorn app:app

乍一看和 FastAPI 差别不大，注意两个细节：

第一，@get 是独立函数，不是 app.get 绑定方法。 这让路由定义可以写在任意文件里，不依赖 app 对象，项目规模变大后拆分模块更自然。

第二，路由处理器通过列表传入 Litestar()，不是自动注册。 显式优于隐式，路由关系一目了然。

Controller：大项目的救星

这是 FastAPI 用户最容易羡慕 Litestar 的地方。

FastAPI 没有原生 Controller 概念，想把相关路由组织在一起，要么靠 APIRouter（功能有限），要么装第三方包 fastapi-utils。

Litestar 内置了 Controller 类，写法和 Java Spring MVC 或 C# ASP.NET 的风格很像：

from litestar import Litestar, Controller, get, post, put, deletefrom litestar.dto import DTOConfigfrom dataclasses import dataclass@dataclassclass User:    id: int    name: str    email: strclass UserController(Controller):    path = "/users"        # 统一在 Controller 层配置鉴权、内容类型等    # 所有子路由自动继承，不用每个路由重复写        @get("/")    async def list_users(self) -> list[User]:        # 返回用户列表        return [User(id=1, name="张三", email="zhangsan@example.com")]        @get("/{user_id:int}")    async def get_user(self, user_id: int) -> User:        return User(id=user_id, name="张三", email="zhangsan@example.com")        @post("/")    async def create_user(self, data: User) -> User:        # 创建用户逻辑        return data        @put("/{user_id:int}")    async def update_user(self, user_id: int, data: User) -> User:        return data        @delete("/{user_id:int}")    async def delete_user(self, user_id: int) -> None:        # 删除用户逻辑        passapp = Litestar(route_handlers=[UserController])

优势非常明显：

所有 /users 前缀的路由集中管理，鉴权配置、Content-Type 设置、依赖注入写一遍，全部子路由自动继承。不用复制粘贴，不用担心漏配某个路由的权限。

内置功能对比：FastAPI 需要找第三方的，Litestar 自带了

这是 Litestar 最有底气说的一点：

几个例子：

限流，3行搞定：

from litestar import Litestarfrom litestar.middleware.rate_limit import RateLimitMiddlewareapp = Litestar(    route_handlers=[...],    middleware=[RateLimitMiddleware(("per-minute", 60))])

JWT 鉴权，内置工具不依赖第三方：

from litestar.contrib.jwt import JWTAuth, Tokenfrom litestar.connection import ASGIConnectionasync def retrieve_user_handler(token: Token, connection: ASGIConnection):    # 从 token 里取用户信息    return await get_user_from_db(token.sub)jwt_auth = JWTAuth[UserModel](    retrieve_user_handler=retrieve_user_handler,    token_secret="your-secret-key",)app = Litestar(on_app_init=[jwt_auth.on_app_init])

响应缓存，装饰器一行：

from litestar import getfrom litestar.config.cache import CacheConfig@get("/expensive-query", cache=60)  # 缓存60秒async def expensive_endpoint() -> dict:    result = await slow_database_query()    return result

依赖注入：比 FastAPI 更结构化

FastAPI 的依赖注入用 Depends()，写法直觉，但规模大了会变成"依赖套依赖"的噩梦。

Litestar 的依赖注入更接近企业级框架的风格，通过 dependencies 参数在应用、路由、Controller 不同层级显式声明，层级关系清晰：

from litestar import Litestar, get, Controllerfrom litestar.di import Provide# 定义依赖async def get_db_session():    session = create_session()    try:        yield session    finally:        await session.close()async def get_current_user(db: AsyncSession) -> User:    # 从 session 获取当前用户    return await db.get(User, user_id)# Controller 层声明依赖，所有子路由自动获得class UserController(Controller):    path = "/users"    dependencies = {        "db": Provide(get_db_session),        "current_user": Provide(get_current_user),    }        @get("/me")    async def get_me(self, current_user: User) -> User:        return current_user        @get("/")    async def list_users(self, db: AsyncSession) -> list[User]:        return await db.execute(select(User)).scalars().all()

依赖在哪个层级声明，就在哪个层级生效，不会意外污染其他路由。

同步 + 异步，Litestar 都能跑

很多框架选边站——要么全异步（aiohttp）、要么不支持异步（Flask 原生）。

Litestar 做到了真正的双模式：

from litestar import get# 异步路由@get("/async")async def async_handler() -> dict:    result = await some_async_operation()    return {"data": result}# 同步路由——Litestar 会把它放进线程池执行，不阻塞事件循环@get("/sync")def sync_handler() -> dict:    result = some_blocking_operation()    return {"data": result}

同步路由被自动放进线程池，不会阻塞异步事件循环。这意味着你可以平滑地把现有的同步代码迁移到 Litestar，不用一次性重写成异步。

实战：一个带缓存和限流的完整 API

把上面的特性整合成一个可运行的例子：

from dataclasses import dataclassfrom litestar import Litestar, Controller, get, postfrom litestar.middleware.rate_limit import RateLimitMiddlewarefrom litestar.config.cache import CacheConfigfrom litestar.stores.redis import RedisStore@dataclassclass Product:    id: int    name: str    price: float# 模拟数据库PRODUCTS = [    Product(id=1, name="商品A", price=99.0),    Product(id=2, name="商品B", price=199.0),]class ProductController(Controller):    path = "/products"        @get("/", cache=30)  # 缓存30秒，高频请求不重复查库    async def list_products(self) -> list[Product]:        return PRODUCTS        @get("/{product_id:int}")    async def get_product(self, product_id: int) -> Product | None:        return next((p for p in PRODUCTS if p.id == product_id), None)        @post("/")    async def create_product(self, data: Product) -> Product:        PRODUCTS.append(data)        return dataapp = Litestar(    route_handlers=[ProductController],    middleware=[        RateLimitMiddleware(("per-minute", 100))  # 每分钟最多100次    ],)

启动：litestar run，访问 http://localhost:8000/schema，Swagger 文档自动生成，开箱即用。

什么时候选 Litestar，什么时候还是用 FastAPI

Litestar 没有"碾压" FastAPI，它们适合的场景有差异：

选 Litestar 的理由：

• 项目对性能要求高，需要最大化压榨吞吐量
• 企业级项目，需要 JWT、限流、缓存、WebSocket 这类功能内置支持
• 团队有 Java Spring / C# ASP.NET 背景，习惯 Controller 风格
• 不想强绑 Pydantic，需要灵活选择数据模型方案

继续用 FastAPI 的理由：

• 项目已经在生产，迁移成本不划算
• 团队规模小，需要靠 FastAPI 庞大的社区和 Stack Overflow 问答快速解决问题
• 大量使用 FastAPI 生态的第三方包，换框架等于重写集成层

一句话总结：

FastAPI 是 Python API 框架的"现任王者"，Litestar 是最有可能取而代之的挑战者。 如果你在启动一个新项目，Litestar 值得认真评估；如果你在维护存量项目，FastAPI 依然是安全选择。

官网：litestar.dev GitHub：github.com/litestar-org/litestar

你现在的 Python 后端用的哪个框架？遇到过 FastAPI 解决不好的痛点吗？评论区聊聊。