Litestar是一个异步优先、类型提示驱动的Python Web框架，尽管没有广泛的宣传，但作者在实际项目中多次使用后对其非常满意。通过简单的代码示例展示了Litestar的易用性，适合构建异步类型提示驱动的Web应用。

Litestar 值得一试

几年前，我在工作中遇到了一个项目，这让我有机会深入了解新一代的异步优先、类型提示驱动的 Python Web 框架。出于一些今天不再重要的原因，我最终选择了 Litestar，这个框架并没有像其他框架那样被大肆炒作。但我非常庆幸自己做出了这个选择，因为如今我比以往任何时候都更加确信这是正确的决定。在过去的 18 个月里，我所有的新项目都使用了 Litestar。

即使你是以开发 Python Web 应用为生的人，或者你正在构建异步类型提示驱动的 Web 应用，你可能仍然不熟悉这个 Python Web 生态系统中的瑰宝。今天，我想改变这一点。

初体验

以下是一个传统的单文件应用示例：

```python from litestar import Litestar, get

@get("/greet") async def greet(name: str) -> str: return f"Hi, {name}!"

app = Litestar([greet]) ```

你可以将这个代码保存为 app.py，然后使用 litestar run 运行，或者直接将其交给你选择的 ASGI 服务器，它就会启动一个 Web 应用。访问 /greet?name=Bob，它会返回“Hi, Bob!”。如果省略 name 参数，它会返回 HTTP 400 错误，告诉你 name 参数是必需的。

名字的由来

你可能会在一些旧资料中看到 Litestar 被称为“Starlite”，这是它最初的名字。Starlette 是一个用于异步 Python Web 开发的工具包，可以独立使用，也可以作为更复杂库或框架的组件。例如，FastAPI 仍然在底层使用 Starlette。Litestar 最初也是基于 Starlette 构建的，因此被命名为“Starlite”。然而，随着时间的推移，它放弃了 Starlette 依赖，转而使用自己的实现。社交媒体上有人抱怨“Starlite”这个名字容易混淆，尤其是因为 Starlette 已经不再被使用。因此，该项目在 2023 年发布的 2.0 版本中更名为 Litestar，并一直沿用至今。

代码扩展性

“扩展性”通常被认为是指处理越来越多的流量，但这只是技术扩展的一个方面。在这里，我想讨论的是代码库的扩展性：一个 Web 框架如何帮助或阻碍你处理不同规模的代码？

例如，Django 在“缩小”代码规模方面并不擅长。虽然你可以通过一些技巧实现单文件 Django 项目，但这并不是 Django 的自然用法。相反，如果你按照官方教程学习 Django，你会发现即使在你编写任何有意义的代码之前，你已经有了十几个文件，分布在特定的目录结构中。

而“微型”框架则往往有相反的问题：它们非常适合从一个小型的单文件应用开始，但随着代码库的增长和扩展，它们会变得难以管理。例如，FastAPI 的路由装饰器通常绑定到应用对象上，这在多文件应用中会导致循环导入问题。为了解决这个问题，FastAPI 引入了“API 路由器”的概念，而 Flask/Quart 则使用“蓝图”。这些机制虽然解决了循环导入问题，但也带来了新的复杂性。

Litestar 通过让路由装饰器成为独立的函数，而不是绑定到父应用或类似对象上，避免了这些问题。这种设计使得 Litestar 的文档可以更早地引入路由分组结构，并将其作为分层架构/配置概念的一部分，而不是作为避免循环导入的应急措施。

与 Pydantic 的关系

Pydantic 是一个流行的用于定义模式对象的包，它通过 Python 类型提示驱动验证和序列化/反序列化。FastAPI 似乎完全依赖 Pydantic，这既有优点也有缺点。Pydantic 非常有用且功能强大，但它也限制了 FastAPI 的灵活性，尤其是在处理 SQLAlchemy ORM 类时。

Litestar 则支持 Pydantic，但并不紧密耦合。默认情况下，Litestar 允许你使用 Pydantic 模型、dataclasses 或 msgspec 来定义输入/输出模式，并且还提供了插件来支持 attrs 和 SQLAlchemy 模型。此外，Litestar 还提供了自动生成数据传输对象（DTO）的系统，这大大减少了样板代码和手动转录字段时可能出现的错误。

与 SQLAlchemy 的集成

SQLAlchemy 是 Python 中几乎标准的数据库工具包和 ORM。Litestar 使得在应用中使用 SQLAlchemy 变得非常方便。它不仅提供了与 SQLAlchemy 的序列化插件，还提供了管理 SQLAlchemy 引擎和每个请求的 ORM 会话的插件，以及一个集成了所有 SQLAlchemy 插件功能的超级插件。

此外，Litestar 团队还维护着优秀的 Advanced Alchemy 库，它在 SQLAlchemy 的基础上提供了许多有用的功能。Advanced Alchemy 提供了通用仓库实现和服务层抽象，并帮助将它们集成到 Litestar 的依赖注入系统中。

总结

Litestar 还有许多其他功能和便利之处，例如它的认证系统、缓存框架、日志集成、错误处理、指标导出和 HTMX 支持等。虽然你可以在其他微型框架中实现这些功能，但通常需要大量的第三方插件和/或自己编写集成代码。Litestar 在保持“微型框架”感觉的同时，还提供了这些可选的功能，这使它成为一个非常值得考虑的 Python Web 框架。

下次你准备构建一个 Python Web 应用时，不妨考虑使用 Litestar，它可能会带你飞向月球🚀🚀🚀。

评论主要围绕Litestar框架的优缺点、与其他框架（如FastAPI、Starlette、Django）的对比以及实际应用中的体验展开。以下是总结：

1. Litestar的优点

• 高性能与轻量级：多位用户称赞Litestar在性能上优于FastAPI，同时保持轻量级且功能齐全。
  • 引用："Great all-around Python async framework that manages to be fast (faster than FastAPI), lightweight, and still has enough batteries included to host a website with auth, sessions, etc."（intalentive）
• 设计优秀：用户对Litestar的设计表示认可，特别是其Controller类和嵌套路由功能。
  • 引用："I’m a huge fan of the design of Litestar."（ddejohn）

2. 与其他框架的对比

• 与FastAPI的对比：多位用户对FastAPI的文档和实际应用中的不足表示不满，认为Litestar更适合复杂项目。
  • 引用："I wouldn’t recommend it for anything serious. Sure, if you want to build a quick CRUD then go ahead and use SQLModel and FastAPI, but keep in mind that its not built for complex applications."（rmonvfer）
• 与Starlette的对比：部分用户认为Starlette在简单场景下足够使用，而Litestar更接近FastAPI/Django的复杂度。
  • 引用："In comparison Litestar seems closer to fastapi/django in scope."（zokier）
• 与Django的对比：用户对Litestar与Django的选择提出疑问，认为Litestar更适合API后端开发。
  • 引用："How would you decide to use Litestar vs Django on a new greenfield project?"（rick1290）

3. 实际应用中的问题

• 文档不足：部分用户指出Litestar的文档不够完善，特别是“如何做”部分需要改进。
  • 引用："the docs could use some love though. i feel most of it is references, the 'how to's could be better."（thewisenerd）
• 表单支持不足：用户提到Litestar在表单验证和错误处理方面的支持不够完善。
  • 引用："Litestar has no 'true' form support of its own; validation is really intended to flag inbound schema mismatch on API calls, not flag multiple individual error fields."（davepeck）

4. 部署与工具

• 部署问题：用户对Litestar的部署方式提出疑问，特别是与NGINX Unit的集成。
  • 引用："How do people deploy this framework typically - speaking for myself, I found NGINX Unit somewhat fiddly."（cbzbc）

5. 其他观点

• 默认端口选择：用户对Litestar默认使用8000端口表示认可，认为比Flask的5000端口更合理。
  • 引用："Good to see it using port 8000 as default, and not Flasks 5000 (does not work on Mac anymore)."（punnerud）

总结：Litestar因其高性能、轻量级和优秀的设计受到广泛好评，特别是在与FastAPI的对比中表现出色。然而，文档不足和表单支持不够完善是其需要改进的地方。用户对其与Starlette、Django的对比也提出了不同看法，认为Litestar更适合复杂项目，但在简单场景下Starlette可能更合适。