Go 读取标准输入遇到 EOF 时为什么不是错误日志

用 Go 读取标准输入时，循环最后一次拿到 io.EOF 很正常，它表示输入流已经被读完，不等于程序出错。真正需要记录日志的是网络断开、文件权限失败、设备读取失败，或者固定格式数据只收到半截。处理顺序也很重要：先消费本次读到的字节，再判断错误；不能看到 EOF 就直接 log.Fatal。

标准输入是自由结束的文本流时，io.EOF 应作为循环结束条件静默处理；只有非 EOF 错误，或固定长度数据中途 EOF，才需要按异常记录和返回。

为什么标准输入读到 EOF 不该打印错误

io.Reader.Read 的约定是：当没有更多输入可用时返回 io.EOF。命令行程序从管道、重定向文件或终端读取数据，输入总会有一个自然结束点。因此，EOF 更接近“对方说完了”，而不是“读取动作失败”。Go 官方 io.EOF 文档也明确把它定义为优雅结束输入的信号。

这也是 io.ReadAll 和 io.Copy 成功返回 nil 的原因：它们内部会读到 EOF，但对调用方隐藏了这个正常终点。若把每次 EOF 都打印成 error，管道任务在正常完成时也会留下误导性的红色日志。

循环读取时如何区分 EOF 与真实错误

逐行读取时最容易犯的错，是把 err != nil 放在处理数据之前。某些 Reader 在最后一次读取中可以同时返回“剩余数据”和 io.EOF，所以应先使用本次拿到的内容，再根据错误决定是否结束。

package main

import (
    "bufio"
    "errors"
    "fmt"
    "io"
    "os"
)

func main() {
    reader := bufio.NewReader(os.Stdin)

    for {
        line, err := reader.ReadString('\n')
        if len(line) > 0 {
            // 先消费本次读到的内容，避免最后一行被 EOF 丢掉。
            fmt.Print(line)
        }
        if err != nil {
            if errors.Is(err, io.EOF) {
                // 标准输入自然结束，安静退出循环。
                break
            }
            // 非 EOF 才是需要交给调用方处理的读取失败。
            fmt.Fprintf(os.Stderr, "读取标准输入失败: %v\n", err)
            os.Exit(1)
        }
    }
}

这段写法有三个判断点：line 非空就先处理；errors.Is 可以识别被上层包装过的 EOF；只有剩余错误才写 stderr 并返回失败状态。若输入严格按行结束，ReadString 通常会在读到换行后返回 nil，下一轮再以 EOF 结束；即使最后一行没有换行，仍不应丢弃它。

什么时候 EOF 要升级为 unexpected EOF

EOF 是否正常，取决于协议有没有规定“必须还有数据”。读取普通文本时，流结束就是完整结果；读取固定 16 字节的消息头、长度前缀或完整 JSON 帧时，中途结束代表输入不完整。

这类场景不要手写“遇到 EOF 就是错误”的统一规则，而应使用能表达边界的 API。io.ReadFull 在一个字节都没读到时返回 EOF，读到一部分但未达到目标长度时返回 io.ErrUnexpectedEOF：

func readHeader(r io.Reader) ([]byte, error) {
    header := make([]byte, 16)
    n, err := io.ReadFull(r, header)
    if err != nil {
        // 记录 n 便于判断收到的是空输入还是半截头部。
        return nil, fmt.Errorf("读取消息头 %d/16 字节: %w", n, err)
    }
    return header, nil
}

调用方可以用 errors.Is(err, io.ErrUnexpectedEOF) 单独提示“数据被截断”，用 errors.Is(err, io.EOF) 区分“一个字节都没有到达”。这比把所有错误都打印成“EOF 错误”更有诊断价值。

把读取函数设计成清晰的返回契约

如果读取逻辑要复用，建议让底层函数返回错误，把日志和退出码留给最外层。这样库函数不会在正常 EOF 时污染业务日志，也不会在被 HTTP、任务队列或测试调用时擅自退出进程。

可以按下面的清单检查：自由长度流是否把 EOF 当终止条件；固定长度数据是否使用 ReadFull；是否先处理带回的数据；是否用 errors.Is 做错误分类；是否只在边界层决定日志级别和退出码。读标准输入时，最实用的结论就是“EOF 是状态，不是日志级别”。

常见问题

为什么 fmt.Fscan(os.Stdin, &v) 也会遇到 EOF？

扫描器同样依赖输入流结束来判断没有更多 token。若程序允许用户输入结束，EOF 可以作为正常分支；如果业务要求必须输入一个值，则应把它转换为业务提示，而不是简单打印底层错误。

EOF 和空字符串是不是一回事？

不是。空字符串可能是合法内容，EOF 是 Reader 的结束信号。判断是否结束应看返回的 error，不能用内容长度代替。

为什么固定长度读取不直接判断 EOF？

直接判断会丢失“读到半截”的信息。使用 io.ReadFull 能把空输入和中途截断区分为 EOF 与 ErrUnexpectedEOF，调用方才能决定重试、丢弃或报警。

处理 Go 标准输入时，先定义输入协议，再选择 EOF 的语义：自由结束的文本流静默收尾，固定结构的半截数据明确报错。这个边界稳定后，日志会更干净，调用方也更容易判断任务究竟是正常完成还是输入损坏。