我在互联网上发现很少有文章建议使用ob_
函数,所有这些强调的好处,并且没有使用上述功能的缺点。
我的问题是使用ob_
函数或设置ini_set('output_buffering', '1');
的缺点是什么?
答案 0 :(得分:1)
使用输出缓冲的缺点完全取决于您的使用环境。
输出缓冲的最大缺点之一是您的运行时错误消息或警告可能会被抑制,您有时可能会得到错误的数据。
考虑这个例子:
<?php
function render_template() {
ob_start();
// Do some processing
fetch_template_and_render();
do_render();
// end capture
$output = ob_get_clean();
return $output;
}
memchace::set( $some_key, render_template() );
?>
如果fetch_template_and_render
或do_render
中的任何一个抛出运行时错误,它们将被转储到您的输出中,并且最终在此示例中将最终出现在数据库或缓存中。
这里有两个片段,展示了我自己可以尝试的意思
#1
<?php
echo 1/0;
?>
输出
Warning: Division by zero on line 1
#2
<?php
ob_start();
echo 1/0;
$var = ob_get_clean();
?>
什么都不输出。
为避免此类情况,您需要勤勉地进行错误检查并采取预防措施。
当努力使用时,ob_ *函数非常强大且非常有用。
答案 1 :(得分:0)
正确实现输出缓冲的使用没有重大缺陷。
输出缓冲可以允许错误/警告/通知(除了停止错误)出现在输出中而不是很明显。这通常通过适当的错误检查,更好的php环境配置以及良好的错误处理程序(例如将错误转换为ErrorExceptions
,可以通过try / catch捕获的错误处理程序的实现来解决 - 请参阅{{3} }作为使用ErrorExceptions
)的错误处理程序的示例。
内存可能是一个缺点,但对于大多数脚本而言,输出大小通常无关紧要。例外情况可能是发送大量数据,例如使用fpassthru
传送文件内容。这可以通过在将此内容写入输出之前关闭输出缓冲(ob_end_clean或ob_end_flush)来解决。
答案 2 :(得分:0)
内存消耗是最重要的缺点。我最近构建了一个PHP脚本,输出大量几兆字节的XML数据。这个'page'框架是使用输出缓冲的一部分。使用输出缓冲,您需要一个足够大的内存缓冲区来包含所有数据。在我的情况下它不是,脚本失败了。
如果直接将数据输出到客户端,则不会出现此问题。在这种情况下以及吞吐文件时,这一点尤为重要。如果生成“普通”HTML页面,您可能不会用完整个缓冲区,但如果您有多个同时请求,仍需要大量内存。
如果没有缓冲,数据就会消失,不再对您的服务器造成麻烦。只要数据被缓冲,就可以更改或刷新数据,但实际上会给您的服务器带来负担。
答案 3 :(得分:-1)
这对ob_函数非常有用:
ob_start("ob_gzhandler");
如果在PHP中启用了zlib扩展,那么应该确保输出是gz压缩的。它显着加快了大页面的页面传输速度。