Question

我已经阅读了文档，两者似乎都达到了相同的目标：渲染模板，将模板传递给上下文或变量。

Answer 1

它们用于不同的目的。 include标记仅包含现有模板中的内容并且未经修改。自定义包含标记将上下文传递给一个函数，该函数可以包含在将上下文传递给模板之前操作上下文的逻辑。

例如，也许我有一个将在多个页面上显示的面板。面板的模板需要通过上下文将一些特定查询传递给它。包含面板的页面不需要其他任何上下文变量。如果我使用include标记包含面板模板，我将不得不在包含面板的每个视图中编写这些查询，并将它们作为上下文变量传递。

或者，我可以编写一个包含查询的自定义包含标记，并将它们传递给面板的模板。通过使用自定义包含标记，我不需要重复代码来在包含面板的每个视图中生成其上下文。我的观点将包含更少的代码，并且不会仅仅由面板使用的上下文变量混乱。

虽然您是正确的，因为简单地传递未经操作的上下文的自定义包含标记与include标记相同。

Answer 2

需要将模板分隔为较小的文件吗？使用包含标记（可读性和可维护性以及DRY）

在渲染模板之前需要包含更多代码吗？使用包含标记（获取更多数据，添加一些业务逻辑......它真的像另一个小的无网址视图。它就像一个模板函数。）

Answer 3

原则上，dgel和YardenST的回答是正确的。另外，查看django的代码可以很好地了解这两个选项在性能方面的比较。

使用default template loaders时，两者之间绝对没有区别。两者最终都调用InclusionTag render()函数，后者又调用模板Loader get_contents()，从文件系统打开模板文件。 render()仅缓存文件，以防它在模板中用于循环。

作为旁注，使用django.template.loaders.cached.Loader可以实现性能差异。

最后，关于dgel建议在不同视图中使用包含标记用于公共上下文：当html标记位于跨越的单个基本模板中时，很有可能避免渲染包含模板的额外开销许多观点，使用ContextMixin。这是渲染的常见场景，例如。基本模板中的主菜单。

Answer 4

最近，当我试图找出最适合采用的路线-include与inclusion tag时，遇到了这个问题-当inclusion tag中没有真正的额外逻辑时。

出于以下原因，我选择了inclusion tag：

模板中更紧凑，更易读的标记

<!-- include -->
{% include "path/to/funky.html" with arg1=arg1 arg2=arg2 %}

与

<!-- inclusion tag -->
{% funky arg1 arg2 %}