考虑一下：

return render(request, 'index.html', {..context..})
return render_to_response('index.html', {..context..})

一方面，render它更干净，更pythonic。另一方面，你将request用作第一个参数，但我觉得这很多余和令人困惑。所以我开始怀疑更大的差异…

根据文档：

render（）与使用context_instance参数（强制使用RequestContext）对render_to_response（）的调用相同。

因此，区别仅在于使用RequestContext。那么，RequestContext的重要之处是什么？让我们再次看一下文档：

特殊的Context类的行为与普通的django.template.Context略有不同。第一个区别是它将HttpRequest作为其第一个参数。

好。根本没关系

第二个区别是，根据你的TEMPLATE_CONTEXT_PROCESSORS设置，它会自动使用一些变量填充上下文[...]除了这些，RequestContext始终使用django.core.context_processors.csrf [...]并且无法通过TEMPLATE_CONTEXT_PROCESSORS设置关闭。

因此，这是重要的部分-确保所有上下文处理器都能正常工作，并重点放在csrf上。所以真的，回到我的第一个示例，这些实际上是相同的：

return render(request, 'index.html', {...})
return render_to_response('index.html', {...}, context_instance=RequestContext(request))

现在，第二个例子显然更糟，整个事情似乎太过复杂了。所以我最大的问题是为什么要使用render_to_response？为什么不反对呢？

想到的其他问题：

1. 有没有更好的方法来强制执行RequestContext默认设置？
2. 有没有办法避免传递request为参数？这是非常多余的。我找到了一篇博客文章，展示了如何使render_to_response成为易于使用的装饰器。我们不能做类似的事情render吗？
3. 有没有考虑这个问题（如果有问题的话）？在将来的弃用时间表中，我什么也看不到。考虑render到django 1.3 专门解决了render_to_response的问题，并且所有人都同意 你不应使用 django 1.3 ，我觉得这特别令人困惑。 render_to_response
   我知道这似乎有点题外话，但我希望能得到答案，以解释为什么render_to_response会留下来和/或用例的示例，其中使用render_to_response将优先于render（如果有）