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

为何要以 2010 年的方式制作网站此前制作网站得心应手的工具组合有静态网站生成器、运用 JavaScript 实现有趣功能的静态网站、简单的 Vue.js 单页应用。对于超简单应用喜欢前端为主开发方式但制作多页面网站时大量前端代码方案吸引力降低于是决定从后端入手。编写少用 JS 的后端为主的网站和少依赖后端的单页 JS 网站感觉类似都是尽量集中逻辑。我很喜欢查询构建器在 Django 中可定义“查询集”类包含带不同 WHERE 语句的方法用于构建查询。定义好方法后在视图代码中使用方法定义方式也有展示。定义过滤器语法虽非最爱但方法使用方便提升代码可读性让人想研究其他查询构建器库。还发现有人用 Python 编写小型查询构建器之后打算研究。模板过滤器非常棒Django 模板中有很多实用小过滤器如将纯文本 URL 转换为链接或换行符转换为 、格式化日期、json_script 转换 Python 字典为 JSON 并插入 HTML 等功能单独简单但整体体验不同。querystring 很实用最喜欢的模板过滤器是 querystring网站会用 ?date2026-06-01 这样的过滤器决定显示内容querystring 可创建指向相同查询字符串但有一处修改的链接。自动数据库迁移依然出色喜欢 Django 的自动数据库迁移系统编辑模型添加新字段等操作Django 能自动生成迁移脚本。目前已进行 19 次数据库迁移之后可能还有更多能轻松修改数据库意义重大。我不想用继承来组织代码Django 文档有时建议用基于类的视图和继承组织视图代码但尝试后不喜欢用继承在视图间共享代码的体验转而用函数像一篇文章提倡的那样更直接明了。不过不介意用继承使用 Django 本身提供的接口。我不知道如何评估 Django 的性能大语言模型爬虫发现网站后每秒发约 10 个请求屏蔽后开始思考网站承载能力。通过简单负载测试发现在月费用约 10 美元的虚拟机上网站每秒约能处理 2 - 3 个请求。想深入研究性能分析和优化但不清楚 Django 网站性能水平和宏观思考方式还有一些未弄清楚的问题。模板缓存可能很重要使用 Django 易不小心配置错误读性能文档发现启用缓存模板加载器可提高性能。CPU 性能分析发现渲染模板占大量时间开启缓存后网站似乎能轻松处理每秒约 12 个请求且不占全部 CPU。一直听到的性能建议多是检查数据库查询但遇到的性能问题并非查询慢先进行 CPU 性能分析更有帮助。暂时就说这么多之后可能再分享对 Django 的喜爱之处或遇到的难题最近打算多写简短博客文章。