{% include %}能拆分模板但需注意变量作用域、路径规则（仅从templates根目录解析）和循环中重复渲染的性能问题，非万能解法。
直接说结论：用 {% include %} 能拆分模板，但必须注意变量作用域、路径解析规则和循环内重复渲染的性能陷阱——它不是“无脑切文件”的万能解药。
include 标签怎么写才不报 TemplateDoesNotExist
Django 的 {% include %} 默认只在 TEMPLATES['DIRS'] 和各 app 的 templates/ 目录里找文件，不支持相对路径或上层目录访问。
- ✅ 正确写法：
{% include "blog/parts/article_header.html" %}（路径从 templates 根开始算） - ❌ 错误写法：
{% include "../header.html" %}或{% include "header.html" %}（后者只在当前 app 模板目录搜，容易漏） - 如果被包含模板需要动态路径，用变量：
{% include template_name %}，但变量值仍需符合上述路径规则
被包含模板里为什么读不到父模板的变量
{% include %} 默认**继承父模板上下文**，但有例外：
- 当用了
with参数显式传参时，会覆盖默认上下文，例如：{% include "nav.html" with current_page="home" %}→ 此时nav.html只能访问current_page，其他变量全丢 - 如果父模板用了
{% with %}块定义局部变量，那些变量不会透传进{% include %} - 调试技巧：在被包含模板开头加
{{ request.path }} {{ object }} {{ forloop }}快速确认哪些变量实际可用
在 for 循环里频繁 include 会不会拖慢页面
会。每次 {% include %} 都触发一次模板加载 + 编译 + 渲染流程，尤其当被包含模板本身含复杂逻辑（如嵌套 include、自定义 tag、数据库查询）时，性能下降明显。
立即学习“Python免费学习笔记（深入）”；
- 高频场景（如文章列表每项都 include 一个操作栏）建议改用
{% include %}+with传最小必要数据，避免在 included 模板里再查库 - 更优替代：把重复结构抽成自定义模板标签（
@register.inclusion_tag），它支持预编译、可缓存、参数类型更明确 - 验证方式：用 Django Debug Toolbar 看 “Templates” 面板里 include 的调用次数和耗时
真正麻烦的是跨 app 的模板复用——路径硬编码、上下文不一致、调试时找不到是哪个 app 提供的模板。这些细节不提前对齐，拆得越细，后期维护成本越高。
