Go bufio.Reader.ReadString 为什么返回数据和错误同时存在

我在把一段文本流改成“按行读取”的小工具时，最容易误判的一种结果就是：bufio.Reader.ReadString('\n') 返回了非空字符串，同时 err 也不是 nil。这不是 Go 把一次读取做坏了，而是它在告诉你“数据已经读到这里，但分隔符或后续数据没有正常出现”。

官方资料：https://pkg.go.dev/bufio#Reader.ReadString

ReadString 应先处理返回的数据，再判断错误。只要返回字符串非空，就不能因为 err != nil 而直接丢弃；当最后一段没有以分隔符结尾时，常见结果就是尾部数据和 io.EOF 同时返回。

先做一个能保留尾部文本的小工具

为了让现象更直观，我把任务限定为读取一段配置文本：完整行以换行符结束，最后一行故意不补换行符。这个小项目不需要网络或文件，输入源用 strings.NewReader 就能表达真实的流式读取边界。

package main

import (
    "bufio"
    "fmt"
    "io"
    "strings"
)

func main() {
    // 最后一行没有换行符，用来观察数据和 io.EOF 同时返回的情况。
    input := "name=go\nmode=stream"
    reader := bufio.NewReader(strings.NewReader(input))

    for {
        line, err := reader.ReadString('\n')
        // 先处理本次已经读到的数据，不能因 err 非空而丢掉尾部。
        if line != "" {
            fmt.Printf("内容=%q，错误=%v\n", line, err)
        }
        // EOF 说明本轮之后没有更多数据；其他错误需要继续上抛。
        if err != nil {
            if err == io.EOF {
                break
            }
            panic(err)
        }
    }
}

这个循环的关键不是把 err 忽略，而是把“数据通道”和“状态通道”分开处理：字符串回答本次拿到了什么，错误回答这次读取是否还能继续。两者可以同时有意义。

为什么数据和 io.EOF 可以同时返回

ReadString(delim) 会一直读到第一个分隔符；如果底层输入先结束了，它只能把已经拿到的内容返回出来，同时用 io.EOF 表示“没有更多字节可读”。因此，输入 name=go\nmode=stream 会出现两轮语义不同的结果：

官方文档给出的判断也可以换成一句代码规则：当返回的数据没有以分隔符结束时，err 就不会是 nil。所以不要把“err != nil”简单等价成“本轮没有数据”。

循环顺序决定最后一行会不会丢失

我实际排查这类问题时，通常先看错误判断是不是写在数据处理之前。下面这种写法看起来简洁，却会丢掉没有末尾换行符的内容：

for {
    line, err := reader.ReadString('\n')
    // 错误先退出，会把 err=io.EOF 时已经返回的尾部文本丢掉。
    if err != nil {
        break
    }
    fmt.Print(line)
}

更稳妥的写法是把“有数据就消费”放到前面，再对错误分类。若业务只把 EOF 当成正常结束，其他错误仍要保留给调用者：

func printLines(reader *bufio.Reader) error {
    for {
        line, err := reader.ReadString('\n')
        // 非空字符串即使伴随 EOF，也代表一段必须处理的输入。
        if line != "" {
            fmt.Print(line)
        }
        if err == nil {
            continue
        }
        // EOF 是输入自然结束，不应伪装成业务失败。
        if err == io.EOF {
            return nil
        }
        // 其他底层 I/O 错误要交给上层决定重试或失败。
        return err
    }
}

这里没有依赖“最后一行一定有换行符”的文件格式假设，因此更适合处理用户上传文本、管道输入和分块响应。对我来说，最重要的验收标准不是日志里有没有 EOF，而是最后一个非空片段是否被消费。

正常 EOF、其他错误和分隔符结果要分开

不要为了“让循环结束”把所有错误都当成 EOF。io.EOF 表示输入自然结束；短读之外的底层错误可能意味着文件、管道或网络读取失败。如果把它们吞掉，文章示例能结束，生产问题却会变成静默的数据缺失。

• 数据非空，错误为 nil：通常找到了分隔符，处理后继续。
• 数据非空，错误为 io.EOF：处理最后一段，然后正常结束。
• 数据非空，错误为其他值：先按业务决定是否保留这段数据，再返回真实错误；不要自动重试同一不确定输入。
• 数据为空，错误为 io.EOF：没有新的内容，结束读取。

如果分隔符不是换行符，只需把参数替换成对应字节；返回契约仍然一样，返回数据是否以分隔符结束仍是判断重点。

什么时候换成 ReadBytes 或 Scanner

ReadString 适合需要字符串结果、能接受一次读取一段文本的场景。若后续要按字节处理，可以使用语义相同的 ReadBytes；若只是简单按行或按词扫描，Scanner 更省心，但它的 token 大小和错误处理模型不同，不应为了绕开 EOF 而机械替换。

写完读取循环后的检查清单

• 是否处理了“非空数据 + io.EOF”这一组合？
• 是否把错误判断写在数据消费之后？
• 是否把其他 I/O 错误和正常 EOF 区分开？
• 是否明确返回字符串是否包含分隔符？
• 输入最后没有换行符时，验收结果是否仍包含最后一行？

因此，Go bufio.Reader.ReadString 返回数据和错误同时存在，是一次读取的两个结果维度：数据告诉你已经拿到的内容，错误告诉你下一步是否还能继续。保留这两个维度，尾部文本就不会因为一个正常的 io.EOF 被误删。

常见问题

ReadString 返回 io.EOF 时，返回字符串一定为空吗？

不一定。若输入末尾没有分隔符，已经读取到的尾部文本会和 io.EOF 一起返回；只有没有任何新字节时，字符串才为空。

遇到 EOF 后还要再调用一次 ReadString 吗？

通常不需要。处理本轮非空数据后即可结束；继续调用只会重复得到输入结束状态。

能不能只判断字符串是否为空？

不能。字符串非空只能说明有数据，不能说明读取是否还能继续。仍要判断 err，并对 EOF 和其他错误分别处理。