输出缓冲？ 为什么不？

I found few articles on the Internet that are suggesting use of ob_ functions, all of these emphase benefits, and there are no downsides of using functions mentioned.

My question is what are the downsides of using ob_ functions, or setting ini_set('output_buffering', '1'); ?

The cons of using output buffering entirely depend on the context of your usage.

One of the biggest cons of output buffering is your runtime error messages or warnings may get suppressed, and you may sometimes end up with erroneous data.

Consider this example:

<?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() );
?>

If either of fetch_template_and_render or do_render throw run time errors, they will get dumped into your output, and eventually in this example will end up in the database or cache.

Here are 2 snippets that demonstrate what I mean which you can try for yourself

#1

<?php 
    echo 1/0; 
?>

outputs

Warning: Division by zero on line 1

#2

<?php 
    ob_start();
    echo 1/0; 
    $var = ob_get_clean();
?>

outputs nothing.

To avoid such cases, you will need to be diligent about error checking and take precautions.

When used diligently, ob_* functions are very powerful and super useful.

Here's a pretty good use for ob_ functions:

ob_start("ob_gzhandler");

Provided that the zlib extension is enabled in PHP, that should ensure your output is gz-compressed. It noticably speeds up page transfers for large pages.

There are no major drawbacks, with proper implementation, to the use of output buffering.

Output buffering can allow errors/warnings/notices (except stop errors) to appear in the output without being readily apparent. This is typically resolved with proper error checking, better configuration of the php environment and the implementation of a good error handler (such as one that converts errors to ErrorExceptions which can be caught with try/catch - see Whoops! as an example of an error handler using ErrorExceptions).

Memory can possibly be a drawback, but the output size is typically insignificant for most scripts. An exception to this may be when sending large amounts of data, such as using fpassthru to deliver file content. This can be resolved by turning off the output buffering (ob_end_clean or ob_end_flush) before writing this content to the output.

Memory consumption is the most important drawback. I've recently built a PHP script that outputs a large chunk of XML data of several megabytes. The framework this 'page' was part of used output buffering. With output buffering, you need a memory buffer large enough to contain all the data. In my case it wasn't and the script failed.

If you output the data directly to the client, you don't have this problem. This is escpecially important in cases like this and when throughputting files. In case of generating a 'normal' HTML page, you will likely not use up the whole buffer, although you still need a lot of memory if you have many simultaneous requests.

Without buffering, the data is gone and doesn't trouble your server anymore. As long as the data is buffered, it can be changed or flushed, but actually puts a load on your server.