我一直在享受的Django其他一些特性
内容提要
作者用Django构建后端渲染网站，享受查询构建器、模板过滤器、querystring和自动数据库迁移等特性，认为它们提升开发效率。但不喜欢用继承组织视图代码，偏好函数式写法。同时困惑于Django性能优化，如缓存和模板系统选择，并提到误关缓存加载器导致性能下降。整体对Django体验积极，但仍在学习性能调优。
延伸解读
查询构建器的可读性优势
作者原本认为“懂SQL就不需要查询构建器”，但实际使用Django的QuerySet后，发现将常用过滤条件封装成方法（如approved()、future()）能显著提升代码可读性。这种链式调用让复杂查询的意图一目了然，尤其适合视图层复用。这提示开发者，即使熟悉SQL，查询构建器也能在代码组织和可维护性上带来实际收益。
模板过滤器的实用价值
Django内置的模板过滤器（如urlize、linebreaksbr、date、json_script）虽然功能简单，但能减少大量重复的HTML处理代码。作者特别提到querystring过滤器，它允许在模板中直接生成带参数的链接，无需在视图或JavaScript中手动拼接URL。这些“小工具”累积起来，能显著提升后端渲染页面的开发效率。
性能调优的困惑与陷阱
作者对Django性能优化感到困惑，尤其是缓存和模板系统的选择。他提到一个具体教训：误关了默认开启的缓存模板加载器，导致性能下降。这反映出Django作为“框架”的复杂性——配置项多且容易误操作。对于新手，建议先了解默认配置，再逐步调整，避免盲目优化。
函数式视图 vs 继承式视图
作者尝试用类继承组织视图代码，但体验不佳，最终回归函数式写法。他认为继承在Python中难以驾驭，但接受Django框架本身提供的继承接口（如QuerySet类）。这提醒开发者，框架提供的继承机制（如类视图）并非强制，选择适合自己思维方式的代码组织方式更重要。
Q&A
Django的查询构建器有什么好处？
Django的查询构建器允许你定义带有不同WHERE条件的查询集类，然后在视图代码中链式调用这些方法，使代码可读性高且易于使用。例如，可以定义approved()、future()等方法，然后像Events.objects.approved().for_tab(tab)这样组合使用。
Django模板中有哪些实用的过滤器？
Django模板提供了一些实用的过滤器，如urlize（将URL转为链接）、linebreaksbr（将换行转为<br>）、date（格式化日期）、json_script（安全地将Python字典转为JSON并插入<script>标签）以及querystring（生成修改后的查询字符串链接）。
Django的querystring过滤器有什么作用？
querystring过滤器可以生成一个链接，该链接基于当前查询字符串，但可以修改或删除参数。例如，{% querystring date=nav.prev_date %}会生成一个链接，将date参数改为指定值；{% querystring outdoors=None %}会移除outdoors参数。
Django的自动数据库迁移有什么好处？
Django的自动数据库迁移允许你通过修改模型来添加字段等，然后自动生成迁移文件，方便地更改数据库结构，无需手动编写SQL。作者认为这极大地简化了数据库变更的过程。
作者为什么不喜欢用继承来组织视图代码？
作者尝试过使用类视图和继承来共享代码，但体验不佳，觉得使用继承来共享代码不直观，转而使用函数式视图，认为这样更直接。作者提到自己从未在Python中通过继承获得良好体验，因此不再尝试。
作者在Django性能方面有哪些困惑？
作者对Django性能优化感到困惑，包括如何应对突发流量、是否应该设计缓存、是否要切换模板系统（如Jinja）、以及模板缓存的重要性。他还提到误关了缓存模板加载器导致性能下降，并认为Django设置文件令人困惑。
