2026 年用 2010 年方式做网站，Django 特性与使用问题大揭秘！

为何要以 2010 年的方式制作网站？

此前制作网站得心应手的工具组合有静态网站生成器、运用 JavaScript 实现有趣功能的静态网站、简单的 Vue.js 单页应用。对于超简单应用，喜欢前端为主开发方式，但制作多页面网站时，大量前端代码方案吸引力降低，于是决定从后端入手。编写少用 JS 的后端为主的网站和少依赖后端的单页 JS 网站感觉类似，都是尽量集中逻辑。

我很喜欢查询构建器

在 Django 中可定义“查询集”类，包含带不同 `WHERE` 语句的方法用于构建查询。定义好方法后在视图代码中使用，方法定义方式也有展示。定义过滤器语法虽非最爱，但方法使用方便，提升代码可读性，让人想研究其他查询构建器库。还发现有人用 Python 编写小型查询构建器，之后打算研究。

模板过滤器非常棒

Django 模板中有很多实用小过滤器，如将纯文本 URL 转换为链接或换行符转换为 `
`、格式化日期、`json_script` 转换 Python 字典为 JSON 并插入 HTML 等，功能单独简单但整体体验不同。

`querystring` 很实用

最喜欢的模板过滤器是 `querystring`，网站会用 `?date=2026-06-01` 这样的过滤器决定显示内容，`querystring` 可创建指向相同查询字符串但有一处修改的链接。

自动数据库迁移依然出色

喜欢 Django 的自动数据库迁移系统，编辑模型添加新字段等操作，Django 能自动生成迁移脚本。目前已进行 19 次数据库迁移，之后可能还有更多，能轻松修改数据库意义重大。

我不想用继承来组织代码

Django 文档有时建议用基于类的视图和继承组织视图代码，但尝试后不喜欢用继承在视图间共享代码的体验，转而用函数，像一篇文章提倡的那样更直接明了。不过不介意用继承使用 Django 本身提供的接口。

我不知道如何评估 Django 的性能

大语言模型爬虫发现网站后每秒发约 10 个请求，屏蔽后开始思考网站承载能力。通过简单负载测试发现，在月费用约 10 美元的虚拟机上，网站每秒约能处理 2 - 3 个请求。想深入研究性能分析和优化，但不清楚 Django 网站性能水平和宏观思考方式，还有一些未弄清楚的问题。

模板缓存可能很重要

使用 Django 易不小心配置错误，读性能文档发现启用缓存模板加载器可提高性能。CPU 性能分析发现渲染模板占大量时间，开启缓存后网站似乎能轻松处理每秒约 12 个请求且不占全部 CPU。一直听到的性能建议多是检查数据库查询，但遇到的性能问题并非查询慢，先进行 CPU 性能分析更有帮助。

暂时就说这么多！

之后可能再分享对 Django 的喜爱之处或遇到的难题，最近打算多写简短博客文章。