我正在制作一个template engine benchmark计划。最初，该程序旨在通过返回渲染结果（作为字符串）来测试模板引擎。但是，一些模板作者提出了一个问题，即模板引擎不应该返回字符串作为结果，而是应该接受输出流或编写器实例作为参数并将渲染结果合并到它们中。他们声称案例代表了正在使用的模板引擎的真实环境。
ASAIK，这句话并非百分之百正确。 Play！Framework（至少1.x）要求模板引擎返回一个String，然后将它们放入outputstream。而且我认为以这种方式组织它是合理的。考虑一下，如果任何逻辑错误导致模板渲染过程失败，如果模板引擎直接输出响应，那么错误将变得无法恢复。在Play中，您很有可能将响应指向优雅的系统错误页面，而不是将半混乱的数据运行到浏览器。
另一方面，直接渲染输出对性能和资源消耗有明显的好处。我很好奇哪一个应该是模板引擎设计师的更好方法。
答案 0 :(得分：1)
写入Writer，因为这是最低的共同点。为方便起见，您的算法可能希望将其包装在PrintWriter中，这样您就可以接受FileWriter，OutputStreamWriter或StringWriter。
写入字符串似乎是一个坏主意，因为在实际使用中，您不太可能需要保留整个字符串以进行后期处理，而是让您能够以小的逻辑片段编写或发送文档 - 因此你的记忆消耗模式会更加真实。
请记住，如果您接受Writer，则可以使用StringWriter来获取String。如果您使用String，即使Writer（和流API）就足够了，您也必须永远分配该内存。
答案 1 :(得分：1)
在我看来，因为返回一个字符串可能会导致各种性能问题（当你需要在有人写一个巨大的模板时尽快将响应返回到内存问题时输出延迟）你肯定会采用流方法。
我也不同意这个不可恢复的错误点。例如，您可以向模板引擎添加一个配置选项，以“缓冲”正在进行的模板（通过使用缓冲的输出流到文件/内存，而不是将任何内容写入“实际”输出流，直到完成为止）。在这种模式下，您可以实现完全相同的错误逻辑。当然，默认情况下该模式应该关闭 - 为了性能。