Go textproto.Reader.ReadContinuedLineBytes 怎样合并折行头部

先把结果说清楚：textproto.Reader.ReadContinuedLineBytes 适合“读取一条逻辑文本行，并把后续以空格或制表符开头的物理行接上”的场景。它会去掉行尾的 ASCII 空格和制表符，移除续行开头的空白，用一个空格连接各段，最后返回独立的 []byte。如果只想读一条物理行，用 ReadLineBytes；如果要解析完整的 MIME 头部映射，则应看 ReadMIMEHeader。

判断标准只有一个：输入是一条需要折行合并的逻辑行，就选 ReadContinuedLineBytes；输入是普通物理行或完整头部集合，就不要为了“返回字节”而强行使用它。

官方入口：https://pkg.go.dev/net/textproto#Reader.ReadContinuedLineBytes

先区分物理行、逻辑行和完整头部

协议文本经常把一个较长字段拆成多行：第一行包含主体，下一行如果以空格或制表符开头，就表示它仍属于上一行。程序真正需要的往往不是带换行符的原始文本，而是已经合并好的一个逻辑值。

ReadLineBytes 只负责去掉当前行末尾的换行；ReadContinuedLineBytes 还会继续观察下一行是否以空格或制表符开头；ReadMIMEHeader 则面向完整的键值头部集合。三者解决的是不同层级的问题。

ReadContinuedLineBytes 会怎样合并空白

官方文档把以空格或制表符开头的后续行视为 continuation。返回结果中，物理行之间的换行和续行前导空白都会消失，只保留一个空格。首行和每个续行还会去掉两端的 ASCII 空格与制表符，因此不要把它当成保留原始排版的 API。

这也解释了一个常见误区：缩进宽度不会被保留。两个空格和一个制表符都只是“续行标记”，输出统一成一个连接空格。

用一个最小示例读取一条折行文本

下面的输入包含一条三段式逻辑行，随后是另一条首行。第一次读取只应得到前一条的合并结果；第二次读取再处理 X-Next。

package main

import (
    "bufio"
    "fmt"
    "strings"
    "net/textproto"
)

func main() {
    input := "X-Trace: abc\r\n  def\r\n\tghi\r\nX-Next: keep\r\n\r\n"
    reader := textproto.NewReader(bufio.NewReader(strings.NewReader(input)))

    first, err := reader.ReadContinuedLineBytes()
    if err != nil {
        panic(err)
    }
    fmt.Printf("%q\n", first) // "X-Trace: abc def ghi"

    second, err := reader.ReadContinuedLineBytes()
    if err != nil {
        panic(err)
    }
    fmt.Printf("%q\n", second) // "X-Next: keep"
}

这里的关键不是把输入读成字符串还是字节，而是读取粒度：方法消费了第一条逻辑行，却不会把下一条以字母开头的新首行错误地拼进来。若后续还要做字节级查找或切片，直接使用 []byte 可以少一次从字符串回转的步骤。

三个 API 怎么选，别把返回类型当成唯一标准

这三个入口都能从 textproto.Reader 读文本，但职责差异比返回类型更重要。选型时先看输入边界，再看是否需要把所有头部组织成映射。

因此，“我需要字节切片”并不足以决定 API。若使用 ReadLineBytes 读取折行头部，调用方还要自己检测前导空白、拼接内容和处理终止条件，反而容易把下一条首行并错。

空行、读取错误和输入大小要单独处理

空行不会继续后续内容，它是一个明确的行边界。首行读取失败时，方法会直接返回错误；而在继续寻找续行时，如果后续读取过程结束，源码会停止追加并返回已经累计的内容。不要因此把这个 API 当成完整的协议校验器：需要严格拒绝异常输入时，上层仍要检查自己的协议状态和错误策略。

另一个边界是输入大小。ReadContinuedLineBytes 本身按无限制长度读取逻辑行；Go 官方对 textproto.NewReader 的说明建议，传入的 bufio.Reader 应建立在 io.LimitReader 或类似限制之上，以约束响应大小。面对不可信网络输入，限制应在 Reader 之外完成。

limited := io.LimitReader(conn, 1

常见误区与最后的决策表

误区一：以为它保留原始缩进。续行前导空格和制表符会被去掉，只留下一个连接空格。

误区二：以为它会读完整头部。它只读取当前逻辑行；需要键值集合时使用 ReadMIMEHeader。

误区三：以为字节返回就等于零拷贝。源码会对返回切片做 bytes.Clone，调用方可以独立持有结果，但仍应按实际数据量评估内存。

相关问题：为什么下一条以字母开头的头部不会被拼接？因为 continuation 的判定看的是下一行是否以空格或制表符开头。为什么不能用它保留格式？因为它会裁剪 ASCII 空白并把续行统一成一个空格。为什么还要限制 bufio.Reader 的来源？因为逻辑行长度默认没有单独上限，不受约束的网络输入可能持续占用内存。

总结：ReadContinuedLineBytes 的价值在于把“多条物理行组成一条逻辑行”的边界交给标准库处理。只要接受空白归一化、明确空行和错误策略，并在 Reader 外加输入上限，它就是读取折行文本协议头部的合适选择。