PHP在Docker中echo/print不实时显示是因stdout全缓冲所致：非TTY环境下CLI默认全缓冲，需同时调用ob_implicit_flush(true)、stream_set_write_buffer(STDOUT, 0)并加-t参数。
PHP echo / print 在 Docker 容器里不实时显示？是缓冲惹的祸
默认情况下，PHP 的标准输出（echo、print）在 Docker 容器中通常不会立即刷出，尤其用 php -S 或 Nginx + PHP-FPM 时更明显。这不是 Docker 的 bug，而是 PHP 自身的输出缓冲机制 + CLI/SAPI 环境差异共同导致的。
关键点：CLI 模式下，PHP 默认启用 stdout 行缓冲（line-buffered），但仅当 stdout 是终端（tty）时才生效；Docker 容器启动时若没加 -t，stdout 就是管道，变成全缓冲（fully buffered），导致内容卡住几秒甚至到脚本结束才吐出来。
- 验证是否为缓冲问题：在脚本开头加
var_dump(php_sapi_name());和var_dump(ob_get_level());，确认是cli且无手动开启的输出缓冲 - 临时测试加
docker run -t（分配伪 TTY），看是否立刻输出——如果好了，基本锁定是缓冲模式切换问题 - 不要依赖
flush()单独调用，它只刷 PHP 用户层缓冲，不保证 OS 层或 Web 服务器层也同步
如何强制 PHP CLI 实时输出：三步到位
要在容器里稳定做到“每行即见”，需同时处理 PHP 层、OS 层和运行时环境：
- 调用
ob_implicit_flush(true)关闭用户输出缓冲（比ob_end_flush()更可靠，避免因嵌套缓冲出错） - 用
stream_set_write_buffer(STDOUT, 0)关掉 C 标准库对stdout的缓冲（这是解决非 TTY 下全缓冲的关键） - 确保启动命令带
-t（如docker run -t php:8.2-cli php script.php），否则stream_set_write_buffer在某些 PHP 版本下可能失效
示例最小可行脚本：
立即学习“PHP免费学习笔记（深入）”；
Web 场景（Nginx + PHP-FPM）下实时输出更难，别硬刚
PHP-FPM 默认禁用
fastcgi_finish_request()之外的实时输出，Nginx 还会自己缓存响应体（proxy_buffering on）。想在浏览器看到逐行更新，得全链路打通：
- PHP 端必须用
ob_flush()+flush()（注意顺序：先ob_flush()再flush()） - Nginx 配置里关掉缓冲：
proxy_buffering off;、fastcgi_buffering off;（后者需 NGINX 1.19.6+） - 响应头必须设
Content-Type: text/plain或text/event-stream，浏览器对text/html有额外解析延迟 - PHP-FPM pool 配置中加
php_flag[output_buffering] = Off，并确认php_admin_value[output_handler] = ""
即便如此，移动端 Safari、某些 CDN 仍可能截断流式响应——实时日志类需求，建议改用 WebSocket 或 SSE，别死磕 flush()。
容易被忽略的底层陷阱：PHP 版本与 SAPI 差异
PHP 8.0+ 对 CLI 的 stdout 缓冲策略做了调整，stream_set_write_buffer(STDOUT, 0) 在非 TTY 下更稳定；但 PHP 7.4 及更早版本在 Alpine 镜像里常因 musl libc 表现异常，表现为 flush() 无效或报 failed to flush 错误。
- Alpine 用户优先试
apk add --no-cache php82-posix（补全 POSIX 扩展），部分缓冲控制函数依赖它 - Dockerfile 中避免用
php:alpine直接跑调试脚本，改用php:apache或php:cli（Debian base）更可控 - 如果用
exec启动 PHP 而非直接ENTRYPOINT ["php"]，父进程（如 shell）可能引入额外缓冲，建议用exec php script.php
真正卡住的时候，往往不是代码写错了，而是你没意识到 Docker 的 I/O 模式、PHP 的 SAPI 类型、libc 实现这三层缓冲正在叠 Buff。
