output_buffering 配置项设为数字（如4096）最有效：启用固定大小缓冲区，满即自动flush，兼顾响应速度与内存占用；off完全禁用，on易致延迟。
PHP 输出缓冲默认已开启，但具体行为取决于配置和代码调用方式；单纯“开启”不是提速关键，误用反而拖慢响应。
output_buffering 配置项怎么设才有效
PHP 启动时会根据 output_buffering 配置决定是否自动启用输出缓冲。它有三个合法值：
-
Off：完全禁用，echo、print立即发送到 SAPI（如 Apache 或 PHP-FPM） -
On：启用无限大小缓冲区，所有输出先暂存，脚本结束时统一 flush - 数字（如
4096）：启用固定大小缓冲区，满即自动 flush，未满则等脚本结束
修改位置优先级：代码中 ini_set('output_buffering', '4096') .htaccess（仅 Apache） php.ini。注意：ini_set() 在 output_buffering = Off 时无法动态开启，必须在 php.ini 中设为 On 或数值才允许运行时调整。
ob_start() 和 ob_end_flush() 的典型误用场景
很多开发者以为多套 ob_start() 就能“层层加速”，实际容易引发嵌套混乱或内存堆积：
立即学习“PHP免费学习笔记（深入）”；
- 未配对调用
ob_end_flush()或ob_end_clean()，导致缓冲区残留，页面空白或内容错乱 - 在循环中反复
ob_start()+ob_get_clean()处理小片段，比直接拼接字符串更耗 CPU 和内存 - 在 CLI 模式下使用
ob_start()无意义，因为 CLI 默认无输出缓冲（output_buffering不生效）
真正合理的用法是：只在需要截获/修改/压缩输出时启动一次，例如生成静态 HTML 缓存、统一处理 HTTP 头、或做模板渲染隔离。
开启输出缓冲后反而变慢的常见原因
输出缓冲本身不提速，它只是改变了输出时机。以下情况会让性能下降：
- 脚本执行时间长，但用户需等待整个脚本结束才看到首字节（TTFB 变高），体验更差
- 启用了
zlib.output_compression = On却没关output_buffering，造成双重缓冲，增加延迟和内存占用 - FPM 模式下，
fastcgi_buffer_size或fastcgi_buffers（Nginx）设置过小，导致缓冲区被频繁刷出，反而触发更多系统调用
若目标是“加速”，应优先检查是否真需要缓冲 —— 大多数 API 接口或流式响应（如 SSE、大文件下载）应显式关闭：if (function_exists('ob_end_clean')) ob_end_clean();，再 flush() 分段输出。
输出缓冲的复杂点不在“开或关”，而在于你是否清楚每一层缓冲（PHP 层、Web 服务器层、代理层、浏览器层）当前状态；一个 ob_get_level() 调用常比改十次配置更管用。
