Go bufio.ReadString 读到 EOF 时如何保留最后一段

bufio.Reader.ReadString 读到 EOF 时，仍可能返回非空字符串。要保留最后一段，就不能遇到任何错误立即退出：应分别看返回的数据和错误状态，在允许无换行末行的业务中消费这段数据，然后把 EOF 当作本次读取结束。其他读取错误仍需返回给调用方，不能伪装成正常结束。

官方地址：https://pkg.go.dev/bufio

先定义读者期待的末行行为

假设我们要做一个小型文本导入组件，输入是 item-a\nitem-b，界面期望显示两条记录。这里用的是原创场景，不是已经上线运行的案例。我会先把约定写清：允许最后一行不带换行；空行保留；空文件不凭空产生记录；记录显示时不包含行结束符。

ReadString以字节分隔符为界。读到换行时，返回值包含换行；在找到分隔符之前遇到错误，则同时返回已经取得的内容和该错误。因而“数据存在”与“读取结束”可以同时成立。代码若在检查字符串之前直接因EOF跳出，就会把末段丢掉。

把读取和消费职责拆开

下面把输入源交给调用者，消费函数负责接收文本和是否带换行的标记。代码会保留所有非空原始片段；如果片段伴随非EOF错误，消费方也能看到该状态，不能把它当成完整记录直接入库。

package main

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

// consumeLines不关闭输入源，资源由创建它的调用者管理。
func consumeLines(src io.Reader, emit func(string, bool, error) error) error {
    reader := bufio.NewReader(src)
    for {
        fragment, readErr := reader.ReadString('\n')
        if len(fragment) > 0 {
            terminated := strings.HasSuffix(fragment, "\n")
            text := fragment
            if terminated {
                // 只移除结束符，保留业务文本两侧的空格与制表符。
                text = strings.TrimSuffix(text, "\n")
                text = strings.TrimSuffix(text, "\r")
            }
            // 将原始读取状态交给消费方，避免异常片段被当成完整记录。
            if err := emit(text, terminated, readErr); err != nil {
                return fmt.Errorf("消费文本失败: %w", err)
            }
        }
        if readErr != nil {
            if errors.Is(readErr, io.EOF) {
                return nil
            }
            return fmt.Errorf("读取文本失败: %w", readErr)
        }
    }
}

func main() {
    // 内存输入不需要Close，最后一段刻意不附加换行。
    src := strings.NewReader("item-a\nitem-b")
    err := consumeLines(src, func(text string, terminated bool, readErr error) error {
        if readErr != nil && !errors.Is(readErr, io.EOF) {
            // 真正的读取异常不提交片段；外层会继续返回读取错误。
            return nil
        }
        fmt.Printf("文本=%q，带换行=%t\n", text, terminated)
        return nil
    })
    if err != nil {
        fmt.Println("导入未完成:", err)
    }
}

这是供读者复现的示例，没有附带本地实测输出。对给定输入，按代码逻辑应调用两次正常消费，第二次带换行标记为false。文件输入应在打开成功后由调用方安排关闭，并按应用需求处理关闭错误。不要在循环内不断重新创建Reader，否则其预读缓冲可能被丢弃。

让末段状态对调用方可见

为了让导入体验可理解，可以把“允许的无换行末段”与“读取异常片段”分开提示。前者不必标成失败；后者要显示未完成，并阻止整批被误报为成功。文字反馈应明确写出状态含义，不能仅靠红绿颜色区分。这个设计建议服务于调用方的展示与提交策略，不改变Reader契约。

按输入边界选择处理方式

本例只在确实有LF结束符时，再移除紧挨着它的CR，以兼容CRLF。无换行末段中的独立CR仍被保留。如果业务还把独立CR视为行分隔符，就应另定解析规则。不要用TrimSpace代替行结束符处理，否则缩进和字段空格也会改变。

ReadString会为返回的一段内容分配字符串，单行极长时仍可能占用较多内存。Reader缓冲区大小不是整行长度的业务上限。面对不可信或无限输入，需要另外定义总输入与单条记录上限，必要时改用分片策略；仅保留EOF末段不等于完成资源限制。

对于实时追加文件，EOF表示这次观察到的流结束，不证明生产者已经结束一条业务消息。不能直接照搬静态文件的“EOF末段立即提交”约定；应协商完整记录标记和等待机制。对于要求末尾必须有换行的协议，也应拒绝或暂存末段，而不是自动接受。

为什么判断原始fragment非空，而不是text非空？

一个换行去掉结束符后会变成空文本，它仍代表真实空行。若检查处理后的text，就会误删这条记录。

EOF之后还要再读取一次吗？

对这里的静态输入约定，没有必要。先处理本次返回的片段，再结束即可；持续追加流属于另一种消费契约。

ReadString会像ReadSlice一样在缓冲区满时只返回一片吗？

两者契约不同。不要把ReadSlice的ErrBufferFull分片语义套在ReadString上；ReadString仍需考虑一整段字符串的内存成本。

我倾向于把末行策略放在导入组件契约里：允许无换行末行时保留数据，要求严格终止符时明确拒绝，读取异常始终向上报告。这样界面显示的“完成”才和程序实际接受的数据一致。

参考：ReadString官方说明、Reader数据与错误约定。