stdbuf 是用于修改标准 i/o 流缓冲行为的 linux 工具，仅对使用 libc stdio 的程序有效；它支持 -ol（行缓冲）、-o0（无缓冲）等模式，但对直接使用系统调用的程序无效，且在管道中仅作用于直接启动的进程。
stdbuf 能直接改程序运行时的 stdout/stderr 缓冲行为，但不是万能的——它只对用 libc stdio 的程序有效，比如 grep、ls、python（默认 IO）这类；对 dd、cat -v 或自己用 write() 系统调用输出的程序，stdbuf 基本没反应。
什么时候必须用 stdbuf -oL 而不是 -o0
多数实时日志场景下，-oL 比 -o0 更可靠：
-
-o0强制无缓冲，但某些程序（如python -u已启用无缓冲）再叠加-o0会报错或被忽略 -
-oL触发行刷新，兼容性更好，且避免高频小写带来的性能损耗 - 重定向到文件或管道时，
stdout默认变成块缓冲（4KB/8KB），-oL是最轻量的“立刻可见”方案
典型用法：stdbuf -oL tail -f /var/log/nginx/access.log | grep "404" —— 没它，grep 可能卡住不输出任何匹配行。
stdbuf -o0 -e0 在管道中容易失效
当命令链里有多个进程时，stdbuf 只作用于它直接启动的那个程序，后面的不会继承：
-
stdbuf -o0 python script.py | grep "error"：只有python的 stdout 被设为无缓冲，grep仍按自身逻辑缓冲 - 如果
grep是瓶颈，得单独包一层：stdbuf -oL python script.py | stdbuf -oL grep "error" - 注意
grep自身也有--line-buffered选项，比套stdbuf更精准
为什么 stdbuf -i0 几乎没用
-i0 表面是“标准输入无缓冲”，实际效果非常有限：
- 它不能让键盘输入跳过终端驱动的行缓存（即你敲完回车才传给程序）
- 对读取管道或文件的程序，
-i0不改变行为，因为read()本身就不缓冲 - 真正需要“即时响应输入”的场景（如交互式调试器），得靠程序自己用
setvbuf(stdin, NULL, _IONBF, 0)或tcsetattr关掉终端回显和行缓存
所以除非你明确知道目标程序依赖 fgets() 且卡在 stdin 缓冲上，否则别白费劲加 -i0。
真正麻烦的是那些自己调用 setvbuf 或用非 libc IO 的程序——stdbuf 完全绕不过去，这时候只能改源码或换工具（比如用 unbuffer 配合 expect）。
