都 20xx 年了，为什么你开始选择 Django？

在经过长达一年的「躺平期」后我在 2023 年 11 月份入职到了深圳的一家初创公司担任 Python 开发工程师，彼时部门规模不大，正处于对 AI 产品的 POC 阶段（Proof of Concept，概念验证），根据前期讨论的需求很快便开始进入到 MVP 的开发阶段。

由于项目并不是传统的 Web 应用，作为后端只需要提供对应的 API 给安卓端调用即可，那么毫无疑问我选择了目前最流行的 FastAPI。（之所以没有选择 Flask 主要还是因为 FastAPI 自带了基于 Pydantic 的类型校验和 API 文档，而使用 Flask 还需要额外配置插件）

开发的进展很快，一直以「Ship fast and iterate」的节奏在持续推进，但随着多次需求的修改逐渐向一个中型项目倾斜，项目的 Python 代码库已经快接近 1w 行。开发体验上的问题也随之显现：

1. 我们需要经常地对一个 SQLAlchemy 的 ORM 模型结果编写对应的 Pydantic 模型进行转化，虽然 FastAPI 的作者正开发 SQLModel 来填补这一空缺，但就目前进度而言很难在生产环境上使用；
2. 在前期开发阶段，我们会经常需要对数据库架构进行调整，包括字段的调整、表的增删改，使用 Alembic，除了要进行配置之外，还需要自己维护一个数据库迁移脚本；
3. 为了应对不同开发需求或开发需要，我们需要一个统一的命令行管理工具，不希望我写 Makefile，而另一个同事编写 Python 脚本或 Shell 命令，而就得额外安装一个 Click 或者是 Typer，Python 自带的 argparse 又太过原始，得额外封装；
4. ……

为了解决上述开发体验上的痛点，我们不得不安装一个又一个依赖并进行额外的配置。

但对使用 Python 开发的朋友们来说这些场景却又再熟悉不过了，因为解决方案的线索似乎都指向了它——Django。

于是在我的推特上我发表了如下感言：

公司的项目用 FastAPI 写了快一年，看着它从简单的小项目逐渐变成 Django 的模样，我就知道为什么 Django 的含金量还在上升。

因为在 Django 及其生态中：

1. 用 django-rest-framework 来实现 ORM 和校验模型的转换，不需要再重复编写字段；
2. Django 本身就自带了 ORM 及模型迁移管理，可以无缝使用 ORM，所以也不需要额外安装 SQLAlchemy 以及 Alembic 了（顺便吐槽一句 SQLAlchemy 的文档是最难读懂的），也不需要再 SQLAlchemy Core 以及 SQLAlchemy ORM 两种风格种切来切去了；
3. Django 提供了一种简单快速地方式让你自定义命令，然后在运行时自动帮你将命令注册到 manager.py 并用它统一管理。

况且，Django 的生态是无敌的。

也许有人诟病 Django 的性能问题，但在大多数时候可能对小公司来说性能往往都遥不可及，在日活连 1000 都不到、QPS 不过半百的阶段下空谈性能问题完全是杞人忧天，何况要进行性能优化时数据库、网关这类基础性的东西反而才是首要，而作为应用层来说编程语言永远屈居末位。

于是我开始重新审视 Django、PHP 的 Laravel、Ruby 的 Ruby on Rails 以及 Java 的 Spring 等这些全栈式框架的意义以及它们在如今时代里的价值所在。

并且我打算重新开始学习如何使用 Django。

一方面我本身就以 Python 为主，但最开始并没有深入去了解如何使用 Django；另一方面根据费曼学习法我打算通过「教」会别人来让自己掌握如何使用 Django。

在这个过程中我将结合这么多年 CRUD 的经验来学习它并记录下一系列的学习教程，而不是完全照搬 Django 官方的文档内容，希望能对其他像我一样学习全栈式框架的朋友们有所帮助。

需要说明的是，本教程可能仅适用于已经有了其他 Web 开发经验或者 Python 开发经验的朋友；对于初学者而言，我更推荐你先看看 Django 的官方文档，然后再去看看一位名为 Matt Layman 的外国友人所写的 Django 教程。最后如果有兴趣了再回头来看看我写的东西，就当个快速查阅的学习小册。

让我们开始吧！