【发布时间】：2011-02-24 13:30:10
【问题描述】：
我看到（不仅在这个网站上）没有经验的 PHP 程序员提出了很多关于臭名昭著的“标头已发送...输出开始于”错误的问题，许多人建议使用输出缓冲作为解决方案。
根据我的经验，我从来没有发现错误不是由程序逻辑缺陷引起的。是否存在输出缓冲实际上是正确解决方案的情况？
【问题讨论】：
标签： php output-buffering
【发布时间】：2011-02-24 13:30:10
【问题描述】：
我同意你最初的说法。通常，通过输出缓冲解决“headers”问题是权宜之计。
这个解决方案真正可悲/有趣的部分是：当您想要输出大的东西时会发生什么，例如您保存在付费专区后面的文件？通常它会导致人们用他们的脚本内存不足来替换“标题”问题。
哎呀。
【讨论】：
我能想象的唯一情况是可以在 HTML 代码中调用插件的 CMS 或 Weblog，例如
<h1>My images</h1>
{plugin:show_images}
这些插件可能必须添加自己的样式表和页面的<head> 部分中的其他内容。使用缓冲，这是可能的。
但在实践中，这对性能不利，感觉很笨拙，并且在关闭输出缓冲时不起作用。因此，即使在这里，最好在显示内容之前对其进行预处理，并在输出任何内容之前添加样式表等。
【讨论】：
-
我认为你在谈论一个不同的问题。 HTML 与 HTTP 标头不同。
-
@ZZ Coder 不，我说的是在您目前正在处理的位置“上方”的位置插入代码。这是
<body>还是<head>元素中的不同位置并不重要。重点是在发送之前使用缓冲来修改输出。 -
@Pekka웃 这并不是问题所在。
您可能希望在流程后期发出 HTTP 重定向，例如在模板或异常处理中。 （当然，带有模板或全局异常处理的框架无论如何都需要输出缓冲，所以你可以说它不是专门解决这个问题的方法。）
【讨论】：
根据我的经验，我从未发现错误不是由程序逻辑中的流程引起的。是否存在输出缓冲实际上是正确解决方案的情况？
不过，我必须同意你的观点：
1) 我喜欢 PHP 的原因之一是因为它可以让你选择如何解决问题
2) output_buffering 除了修复“已发送的标头”消息之外还有其他用途 - 例如压缩输出，捕获任意代码的输出，避免分块编码......
C.
【讨论】：
对于模板系统，您将需要 ob_start ...look 和 Zend_View
稍后编辑 我误解了这个问题，并提供了一个使用 ob_start 是有效解决方案的案例。
【讨论】：
-
没错，模板系统需要它。不过，问题是关于“标头已发送”的情况。
-
solomongaby 暗示一些模板系统使用输出缓冲来渲染模板的片段，以便在稍后的渲染步骤中合并。然而，虽然这是对输出缓冲的有效使用，但这并不能解释为什么缓冲可能是解决原始问题“标题”问题的有效方法。