Django入门实践：为什么这个20年老框架依然值得学

为什么选择Django这样的"老牌技术"

知名技术博主Julia Evans最近分享了她学习Django的心得。她提出了一个颇具启发性的观点：学习一项存在20多年的"老旧无聊技术"反而是极好的体验——你遇到的每个问题都已经被解决了上千次，社区文档和解决方案极其丰富，你可以专注于把事情做好。

背景：Django的诞生与演进 Django诞生于2003年，由Lawrence Journal-World报社的开发团队创建，2005年以开源形式发布。它的设计初衷是应对新闻媒体行业快速迭代的需求，这也解释了为何Django天然具备强大的内容管理能力。Django遵循MTV（Model-Template-View）架构模式，与MVC本质相同但命名不同。经过20年演进，Django已成为Python Web生态的基石，Instagram、Pinterest、Disqus等大型平台均曾或仍在使用Django构建核心服务。这种经过大规模生产验证的成熟度，正是"老旧无聊技术"的核心价值所在。

Django学习笔记

在尝试过Rails之后，她最终选择了Django。核心原因是：Django更加显式（explicit），而非依赖约定。对于那些会把项目搁置数月甚至数年再回来继续开发的人来说，代码的可读性和可追溯性至关重要。

比Rails更少的"魔法"

作者在2020年曾尝试学习Rails，但发现Rails的"约定优于配置"哲学对她来说是个障碍。例如，在routes.rb中写一行resources :topics，你无法直接看出路由的具体配置在哪里，必须记住或查阅约定规则。

两种哲学的本质差异 Rails奉行的"约定优于配置"（Convention over Configuration）哲学由DHH提出，核心思想是通过预设大量约定减少配置代码量，让开发者专注于业务逻辑——熟悉约定的开发者可以极速上手新项目。而Django更接近Python之禅中"显式优于隐式"（Explicit is better than implicit）的理念，每一个行为都有明确的代码对应。两种哲学各有权衡：约定减少了初期代码量，但增加了认知负担，需要开发者将框架规则内化为肌肉记忆；显式增加了代码量，但降低了理解成本，即使是陌生人也能通过阅读代码推断系统行为。对于长期维护、团队流动性高或间歇性开发的项目，显式设计往往更具可持续性。

而在Django中，一个小型项目通常只需关注5个核心文件：

urls.py — 路由配置
models.py — 数据模型
views.py — 视图逻辑
admin.py — 管理后台
tests.py — 测试代码

如果想找某个HTML模板的位置，通常可以从这些文件中的显式引用追溯到。这种透明性让项目在长期搁置后依然容易理解，也让Django的学习曲线更加平缓。

内置管理后台：开箱即用的生产力

Django最令人惊喜的特性之一是内置的Admin管理界面。只需少量代码就能定制一个功能完善的数据管理后台：

@admin.register(Zine)
class ZineAdmin(admin.ModelAdmin):
    list_display = ["name", "publication_date", "free", "slug", "image_preview"]
    search_fields = ["name", "slug"]
    readonly_fields = ["image_preview"]
    ordering = ["-publication_date"]

这段代码配置了列表视图的显示字段、搜索字段和默认排序。Django Admin的底层实现本身就是一个完整的Django应用，它通过读取模型的元数据（Meta class）自动生成增删改查界面，并支持权限管理、历史记录追踪等企业级功能。对于需要手动查看或编辑数据库数据的场景，Django Admin比从零搭建一个管理界面要高效得多，特别适合个人项目和小团队使用。

ORM的魅力：从"谁需要它"到"真香"

作者过去的态度是"ORM？我自己写SQL就行了"。但Django ORM改变了她的看法。

ORM技术原理 ORM（Object-Relational Mapping，对象关系映射）是一种将面向对象编程语言中的对象模型与关系型数据库表结构进行映射的技术。它的核心价值在于让开发者用面向对象的方式操作数据库，而无需直接编写SQL，同时提供数据库方言抽象——同一套ORM代码可以在SQLite、PostgreSQL、MySQL之间切换而无需修改业务逻辑。Django ORM的双下划线查询语法（Lookup API）是其最具特色的设计之一：通过field__related_field__condition的链式语法，ORM引擎会自动分析模型间的外键（ForeignKey）和多对多（ManyToManyField）关系，生成对应的SQL JOIN语句。这种设计在保持可读性的同时，也让复杂查询的构建变得直观，且生成的SQL经过了充分优化。

一个典型例子是用__（双下划线）表示JOIN操作：

Zine.objects.exclude(product__order__email_hash=email_hash)

这一行代码涉及5张表的关联查询（zines、zine_products、products、order_products、orders）。你只需在模型中声明ManyToManyField关系，Django就知道如何连接这些表。

相比手写复杂的SQL JOIN语句，product__order__email_hash不仅输入量更少，可读性也更强。对于小型项目来说，ORM生成的查询性能完全不是问题。

自动迁移：数据模型变更的利器

Django ORM带来的另一个巨大好处是自动迁移。当你在models.py中添加、删除或修改字段时，Django会自动生成迁移脚本（如migrations/0006_delete_imageblob.py）。迁移系统会追踪每一次模型变更，形成有序的版本历史，类似于数据库结构的Git版本控制。在项目初期频繁调整数据模型时，这个功能尤为重要——你不需要手动编写ALTER TABLE语句，也不用担心遗漏某个变更，团队协作时每个成员只需运行python manage.py migrate即可将数据库同步到最新状态。

实用选择：SQLite替代Postgres

在经历了运维Postgres的痛苦后，作者决定用SQLite运行所有小型网站。

SQLite生产环境的再认识 SQLite是世界上部署量最大的数据库引擎，其设计目标是嵌入式场景而非客户端-服务器架构，整个数据库存储在单个文件中。长期以来，SQLite被认为不适合生产环境，但这一认知正在被重新审视。SQLite官方文档指出，对于每日写入量低于100万次的应用，SQLite的性能完全胜任。2022年，Litestream等工具的出现进一步解决了SQLite的实时备份和流式复制问题。Django 4.2版本也专门优化了SQLite支持，引入了WAL（Write-Ahead Logging）模式配置——WAL模式允许读操作和写操作并发进行，大幅提升了并发场景下的吞吐量，使SQLite在Web应用场景下的表现远超传统认知。

好处显而易见：

备份只需VACUUM INTO然后复制单个文件
无需管理数据库服务进程
对于每天几百次写入的小站完全够用

她参考了社区的SQLite生产环境配置指南，并以自己的另一个项目"Mess with DNS"（写入量更大，分布在3个SQLite数据库）作为成功案例佐证。Django + SQLite的组合对于个人项目和小型网站来说，是一个被严重低估的高效方案。

电池齐全的框架哲学

Django的"batteries-included"（电池齐全）理念体现在方方面面：CSRF防护、Content-Security-Policy、邮件发送等功能都内置其中。

Web安全内置机制 CSRF（Cross-Site Request Forgery，跨站请求伪造）是一种常见的Web安全攻击，攻击者诱导已登录用户在不知情的情况下向目标网站发送恶意请求，例如在用户不知情时完成转账操作。Django的CSRF防护通过在表单中注入随机Token（{% csrf_token %}模板标签）并在服务端验证来实现，这一机制默认启用且无需额外配置。Content-Security-Policy（CSP）则是另一层防御，通过HTTP响应头告知浏览器哪些资源来源是可信的，从而防止XSS（跨站脚本）攻击。Django将这些安全机制作为内置中间件（Middleware）提供，中间件架构允许在请求-响应周期中插入横切关注点，体现了"安全默认