# 在 Django 模板中何时使用 simple_tag

在 Django 中往模板传递数据的方式通常有两种。

* **从视图通过 context 注入**：显式地把页面渲染所需的数据放进去。
* **通过 context processor 全局注入**：把所有模板都需要的公共数据“始终”放进去。

除此之外，还有一种方式：**`simple_tag`（自定义模板标签）**。

如果使用得当，**视图会更精简，模板的表现也更干净**；但如果使用不当，数据来源会变得模糊，维护起来会更困难。

![Django网页开发厨房中央](/media/editor_temp/6/40788e2b-5858-409e-b359-d9788aaa0233.png)

本文不打算给出唯一答案，而是基于我实际使用的经验，整理 **何时把 simple_tag 拿出来** 的准则。

---

## 用一句话定义 simple_tag

**一个接受模板中已有值作为输入，返回轻量处理结果的函数**。

* 可以在需要时像 `pull` 一样调用。
* 把仅用于输出的格式化/组合/转换逻辑移到模板之外。

---

## 与传统方式的边界

### 视图注入：页面核心数据

如果数据是渲染该页面的核心，我会毫不犹豫地放在视图里。

* 页面结构的主列表/详情数据
* 根据条件分支的逻辑结果
* 通过 ORM 查询得到的模型数据

这些属于 **请求处理流程的一部分**，如果搬到模板标签里，追踪会变得困难。

### context processor：全局数据

例如：

* `request`
* 登录用户信息
* 网站全局设置/菜单/环境值
* 通用徽章/通知计数等 UI 数据

但 context processor 也有缺点。

* 自动注入，难以追踪使用位置。
* 若不小心放入重逻辑，所有页面成本都会上升。

因此，我倾向于把 **全局数据保持最小化**，而 **全局数据的加工/组合** 用 simple_tag 处理。

---

## simple_tag 的使用准则

我的规则很简单：

1. **这数据是渲染页面的核心吗？ → 视图**
2. **ORM 参与吗？ → 视图**
3. **能用 request + context processor 的值组合/转换得到吗？ → simple_tag**
4. **是视图主逻辑之外的辅助逻辑吗？ → simple_tag**

核心在于：

* **获取数据**（尤其是数据库）由视图负责。
* **按展示需求加工**由 simple_tag 负责。

---

## 为什么“ORM 绝对放视图”

在模板标签中使用 ORM 常见问题：

* 在循环中调用标签导致 **N+1 查询**。
* 性能问题出现时，难以追踪查询来源。
* 缓存/预取等优化位置不明确。

因此，我保持保守：

* **所有数据库操作**放在视图（或服务层）。
* simple_tag 只做 **已有值的加工**。

---

## 最常用模式：request + 全局 context 组合输出

我把 `request` 对象和自定义 context processor 的值注入到所有模板，然后用 simple_tag 主要做：

* 字符串拼接
* 根据条件改变格式
* 类型转换
* 转成模板友好的结构

优点显而易见：

* 视图不堆满“输出专用加工代码”。
* 模板只需在需要时短调用。
* 数据已在模板中，调用成本低（不触碰数据库）。

---

## 示例：把模板中复杂加工搬到 simple_tag

在模板里使用 `{% if %}`、`{% for %}` 等控制语句很自然，但当条件增多、嵌套加深时，模板会变成 **标记 + 逻辑** 的混合，阅读困难。

例如，结合全局注入的值（context processor）和 `request` 生成“给用户展示的文字”时，常会出现：

* 条件过长
* 字符串拼接和默认值处理导致行数增多
* 嵌套导致流程不清

此时，把逻辑 **抽离到 simple_tag**，模板只关注 UI 表现。

```django
{% load ui_helpers %}
{% greeting_message %}
```

复杂判断/拼接在标签内部完成，模板只需一行调用。这样既保持了模板整洁，也让逻辑集中管理、易于测试。

---

## simple_tag 特别适合的场景

我认为 **以下情况** 最适合使用 simple_tag：

* **多模板重复使用的格式化**（日期、金额、标签、文案组合等）。
* **基于 request 的 UI 状态计算**（当前路径对应的菜单激活、查询字符串驱动的切换状态）。
* **把全局 context 转成模板友好结构**（把 dict 转成列表或更易迭代的形式）。
* **与视图主流程无关的“UI 帮手”**（决定 CSS 类、生成徽章文字、简单权限标记）。

---

## 关键是团队/项目的一致准则

我提出的准则并非唯一答案，但有了准则，优势明显：

* 随着时间推移，**为何在此处处理**的理由仍然清晰。
* 维护/调试时更易追踪。
* 代码评审时争议减少。

我个人对这种方式很满意，并将继续坚持。

---

## 结语

你们是如何划分的？

* 允许全局 context 的程度
* 在模板标签中放入逻辑的边界
* “视图应做的事”范围

无论准则如何，**拥有准则本身**在长期维护中都是极大的帮助。

---

**相关文章**

-  [Django 模板中提取 URL：path vs path_info vs get_full_path vs build_absolute_uri](/ko/whitedec/2026/1/23/django-template-url-extraction/)