ob_start() 后页面无反应是因为输出被缓冲且未释放，需配对调用ob_end_flush()或ob_end_clean()；其回调函数可预处理内容，但必须返回字符串；多层嵌套时内层回调先执行；它不解决header()问题，仅延迟报错。
为什么 ob_start() 调用后页面没反应？
常见现象是加了 ob_start() 却看不到任何变化，甚至页面空白。这不是函数失效，而是它默认把输出“扣住”了，不显式释放就一直存着，脚本结束时才自动清空并丢弃——所以你什么也看不到。
必须配对使用 ob_end_flush() 或 ob_end_clean() 才能真正让内容出来：
-
ob_end_flush()：送出缓冲区内容，并关闭缓冲 -
ob_end_clean()：丢弃内容，关闭缓冲（适合想拦截但不输出的场景） - 漏掉这一步，等于写了日志却忘了调用
echo
ob_start() 的回调参数到底怎么用？
第二个参数 output_callback 是关键能力，不是摆设。它让你在内容发出前做转换，比如压缩、加水印、替换敏感词，比单纯“缓存再吐”灵活得多。
注意点：
立即学习“PHP免费学习笔记（深入）”；
- 回调函数必须返回字符串，不能只
echo或修改全局变量 - 传入参数是当前缓冲区的完整内容，类型是
string，别当数组处理 - 如果回调里抛异常或返回非字符串，整个输出会中断，页面可能 500
示例：简单 HTML 标签转义
ob_start(function($buffer) {
return htmlspecialchars($buffer, ENT_HTML5, 'UTF-8');
});
多个 ob_start() 嵌套时谁先执行？
PHP 输出缓冲支持多层嵌套，但顺序是「后开先关」——就像套娃，最内层的回调最先被触发，外层后处理。这点容易误判逻辑流向。
典型陷阱：
- 在框架中间件里开了一个
ob_start()，又在控制器里再开一个，结果回调执行顺序和预期相反 - 某层用了
ob_end_clean()，会直接清掉当前层及所有内层，外层拿不到数据 - 调试时用
ob_get_level()查当前嵌套深度，比硬猜靠谱
启用 ob_start() 会影响 header() 吗？
会，但只是“延迟报错”，不是阻止。只要缓冲开着，header() 就不会立即失败；一旦缓冲关闭（或脚本结束），PHP 才检查是否已输出过内容——这时才爆 Warning: Cannot modify header information。
这意味着：
- 你以为“开了缓冲就能随便 header”，其实只是把错误拖到后面了
- 真正安全的做法是：确保
header()在任何echo、HTML 输出、甚至空格/换行之前调用 -
ob_start()不是 header 失败的解药，而是掩盖问题的绷带
最容易被忽略的是：BOM 头、文件末尾多余空行、UTF-8 with BOM 的 PHP 文件，都会在你完全没意识到的时候触发输出。
