按时间刷新输出，减少命令行 I/O 开销

日志刷得越勤，程序反而越慢，问题可能就出在每行末尾的换行符。原文借 Chris Wellons 编写解压工具 tugz 的经历，提出一个改法：保留文件列表，但把刷新条件从「遇到换行」改成「到达短暂的时间期限」。

它值得程序员读的地方，是把「及时反馈」和「逐行写出」拆开了。不过，文章里的性能收益没有完整对照数据，示例代码对刷新期限的处理也有差异。可以借鉴思路，不能直接把示例当成生产实现。

为什么一个换行会增加系统调用

调用 puts 或 print，不等于立即执行一次底层写入。中间还有语言运行时和用户态缓冲区，真正跨过系统调用边界的是 write。

原文展示了一个 glibc 环境下的例子：先执行 puts("a\nb")，再执行 puts("c")，通过 strace 观察，会看到三次写入，分别输出 "a\n"、"b\n"、"c\n"。一次 puts 里的字符串，也可能因为包含换行而被拆开。

原因是行缓冲：遇到换行，就把相应内容刷出去。程序输出五万行日志时，这个策略就可能带来大量系统调用。但终端并不要求每行单独到达，把多行合在一次写入里，同样能显示。

C 的 setvbuf 提供三种模式：全缓冲 _IOFBF、行缓冲 _IOLBF、无缓冲 _IONBF。原文讨论的典型默认行为是，通过 isatty 判断输出是否连着交互设备；连着终端时倾向于行缓冲，重定向到文件或管道时使用全缓冲，通常积攒到 4 或 8 KB 再写。

这解释了一个常见现象：同一个程序，重定向输出后可能明显变快。不过，这里不能把全部差异都归给缓冲策略，终端处理和绘制文本也有成本。

CPython 的行缓冲文本流同样会受换行触发刷新，只是处理细节与 glibc 不完全一致。共同的问题是：用换行这个文本标记，决定什么时候支付底层写入成本。

原文引用的 Info-ZIP unzip 案例更直观。解压大量小文件时，逐个打印文件名可能比解压本身更拖时间。Wellons 曾中断解压，改用 quiet 选项重新开始；后来编写 tugz，则尝试保留列表、减少写入。

这是作者转述的使用经历，文章没有给出归档规模、终端配置和耗时对照，不能据此认定所有解压任务都由日志拖慢。

把刷新条件改成时间，需要怎样实现

用户需要输出及时出现，不一定需要每一行立刻写出。

原文建议给缓冲区一个约 100 毫秒的期限。在此期间积攒多行，到期统一刷新；数据量太大时提前刷新。它与 TCP 的 Nagle 算法有相似动机：把零碎写入合并，分摊每次操作的固定开销，但两者并不是同一套机制。

实现也不一定需要后台线程。程序可以在处理解压块等自然执行点检查时间。原文给出的 Python 包装器如下，它把「追加数据」「检查期限」「实际写出」拆成三个动作：

import os
import time

class DeadlineWriter:
    def __init__(self, fd, deadline=0.1, chunk=65536):
        self.fd = fd
        self.deadline = deadline
        self.chunk = chunk
        self.buf = bytearray()
        self.flush_at = None

    def write(self, data):
        self.buf += data
        if self.flush_at is None:
            self.flush_at = time.monotonic() + self.deadline
        if len(self.buf) >= self.chunk:
            self.flush()

    def poke(self):
        if self.buf and self.flush_at is not None:
            if time.monotonic() >= self.flush_at:
                self.flush()

    def flush(self):
        if self.buf:
            os.write(self.fd, bytes(self.buf))
            self.buf.clear()
        self.flush_at = None

    def close(self):
        self.flush()

重点看 if self.flush_at is None：只有缓冲区开始积攒数据时才建立期限，后续写入不会反复把期限往后推。time.monotonic() 用于计算间隔，chunk=65536 则提供容量触发条件。

接入工作循环时，调用方必须主动检查期限：

out = DeadlineWriter(1)  # 标准输出

for name in archive.namelist():
    out.write(f"  inflating: {name}\n".encode())
    data = archive.read(name)
    for block in iter_blocks(data):
        process(block)
        out.poke()
out.close()

要盯住的是 out.poke() 的位置。时间到了，缓冲区不会自己醒来；程序走到这里，才有机会刷新。

如果循环持续运行且检查足够频繁，显示节奏可以接近每秒 10 次，多行共享一次写入。原文声称一万行突发输出可以从一万次写入变成少量写入，但没有附测量结果。实际次数还取决于输出大小、持续时间以及容量阈值。

100 毫秒期限为什么不等于延迟保证

原文最需要补充解释的，是「期限」成立的条件。

首先，协作式检查依赖工作循环。上面的 archive.read(name) 位于检查之前，如果读取或处理长时间阻塞，输出就可能超过 100 毫秒仍未刷新。没有进入内层循环时，也不会执行那里的 poke()。

因此，原文所说「进程崩溃最多丢失 100 毫秒状态输出」，对这段代码并不无条件成立。它需要检查足够频繁，且写出过程没有额外阻塞。

其次，原文的 C 片段和 Python 实现并不完全一致。C 版本在期限尚未到达时，会执行 b->deadline = now + DEADLINE。如果每次检查都比 DEADLINE 更早到来，期限就可能持续后移。这更接近等待一段空闲时间的防抖，而 Python 示例是从首次积攒数据开始计时。

要控制最长等待时间，就不能让后续检查无限推迟已有期限。

最后，还有输出正确性。os.write 可能只写出部分字节，示例随后直接清空整个缓冲区，会有数据丢失风险。原文也承认需要处理短写，并提到可用时考虑 os.writev；但更换 API 不能代替检查返回值、处理未写完的数据。

多线程共享缓冲区还需要锁。交互提示则必须在等待输入前显式刷新，例如打印 Password: 后立即读取输入。用回车原地重绘的进度条、需要尽快暴露的错误输出，也应有各自策略。

我的判断

这个思路说得对：换行是文本结构，延迟是交互要求，两者没有必要永远绑定。对批量打印状态的命令行工具，按时间和容量共同刷新，比只能加 quiet 选项更能兼顾可见性与吞吐。

但文章对收益的表达比证据更强。它没有给出 tugz 的完整基准，没有拆分系统调用、终端绘制和解压工作的成本。「列表几乎免费」应当视为特定场景的经验描述。

相比纯容量缓冲，时间条件能改善低流量时迟迟看不到输出的问题；相比逐行刷新，它允许合并突发输出；相比后台定时刷新，工作循环主动检查减少了并发管理，却要求循环持续获得执行机会。三者各有前提。

这也不值得让已有成熟日志框架的团队立刻重写输出层。原文自己指出，多线程场景可能更适合把策略放进自定义 logging handler。先确认瓶颈，再选择改哪一层，比照搬一个包装器更可靠。

能拿来做什么

• 给构建工具、代码生成脚本或批量文件处理 CLI 排查性能时，可以比较终端输出与重定向输出，并用 strace 观察写入次数，确认逐行输出是否构成明显成本。
• 给自有 Node CLI 设计日志策略时，可以借鉴「时间期限加容量阈值」，但原文没有验证 Node 的输出行为，需要先检查实际调用链，不能直接套用 glibc 的结论。
• 试用这段 Python 示例时，应补齐短写处理、退出收尾，并检查所有长耗时路径能否及时执行 poke()；交互提示和错误输出单独处理。
• 为 AI 编程生成的批处理脚本审查日志代码时，可以要求它明确刷新条件、最长等待的前提和异常退出行为，避免只看到 deadline=0.1 就认定已有延迟保证。