tee未显示输出是因管道中命令切换为非交互模式导致视觉无反应；需用-p强制刷新或验证输入源；stderr需2>&1重定向才能被tee捕获；大文件写入应避免全缓冲，用stdbuf -oL或script保障一致性；脚本中须用PIPESTATUS获取原始退出码。
tee 命令为什么没在屏幕上显示输出？
常见现象是执行 ls | tee output.txt 后，文件写入成功，但终端看起来“没反应”——其实它正常输出了，只是被后续命令覆盖或缓冲干扰。根本原因是：某些命令（如 ls 在管道中）会自动切换为非交互模式，禁用颜色、换行优化等，导致视觉上像“没输出”。
- 确认是否真没输出：加
-p参数强制逐行刷新（ls | tee -p output.txt），或用echo "test" | tee output.txt快速验证 - 如果命令本身不输出到 stdout（比如静默运行的
make -s），tee也无能为力，得先去掉静默开关 - 终端宽度变化、ANSI 转义序列（如颜色）可能被
tee原样写入文件，但屏幕渲染正常；若需干净日志，加script -qec "your_command" /dev/null | tee output.txt过滤控制字符
如何让 tee 把 stderr 也同时记录？
tee 默认只处理 stdin（即管道来的 stdout），stderr 会直接冲到终端，造成“屏幕有错、文件没记”的割裂。必须手动把 stderr 重定向进管道。
- 最常用写法：
command 2>&1 | tee output.txt—— 把 stderr 合并到 stdout 再交给tee - 想区分 stdout/stderr 到不同文件？用进程替换：
command > >(tee stdout.log) 2> >(tee stderr.log >&2) - 注意顺序：
2>&1 | tee不能写成| tee 2>&1，后者只重定向了tee自己的 stderr，不是原命令的
tee 写入大文件时卡住或丢数据？
默认情况下 tee 使用全缓冲（full buffering），当输入流不带换行（如二进制、实时日志流），或数据量大但未满缓冲区时，文件可能延迟落盘，甚至因进程异常退出而丢失末尾内容。
- 加
-i忽略中断信号（防止 Ctrl+C 中断写入）、--output-error=exit让写失败立刻报错 - 强一致性需求下，用
stdbuf -oL command | tee output.txt强制行缓存；或改用script -qfec "command" output.txt（更可靠但多一层 shell） - 避免用
tee -a频繁追加小数据——每次系统调用开销大；应批量生成再一次性tee，或用dd conv=notrunc类工具替代
在脚本里安全使用 tee 需要绕过哪些坑？
脚本中直接写 some_cmd | tee log.txt 看似简洁，但 exit code 会变成 tee 的（通常是 0），掩盖上游命令失败。这是最隐蔽也最危险的问题。
- 正确获取原始命令退出码：
some_cmd 2>&1 | tee log.txt; exit_code=${PIPESTATUS[0]}（bash/zsh 支持） - 不要在
if条件里直接管道接tee：if cmd | tee log.txt; then ...判断的是tee是否成功，不是cmd - 路径含空格或变量？务必引号包裹：
tee "$log_path"，否则tee报No such file or directory却不提示具体是哪个路径出问题
tee 不够，得配合 PIPESTATUS、显式 stderr 重定向和缓冲策略——这些细节不显眼，但缺一不可。 
