Go mime/multipart.Reader.NextRawPart 如何处理带前导换行的表单：Part 遍历与边界判断

如果你在 Go 里手动解析 multipart 请求，遇到“第一个 Part 之前多了一行空白”或同一字段在 NextPart 与 NextRawPart 中读出的字节不一样，先不要把它归结为 boundary 写错。mime/multipart.Reader.NextRawPart 会沿着 MIME boundary 找下一个 Part；它和 NextPart 的关键差别，是不会替你处理 Content-Transfer-Encoding: quoted-printable。因此，判断这类问题要把边界识别、当前 Part 的读取和最终的 io.EOF 分开看。

结论是：前导 CRLF 通常属于 multipart 的边界分隔格式，不是 Part 内容；循环中要完整读取当前 Part，再调用下一次 NextRawPart，并把 io.EOF 只当作“没有更多 Part”，不要把它当成当前字段读取失败。

先分清 NextRawPart 和 NextPart 的职责

NewReader 接受一个输入流和 boundary，Reader 本身是只能向前移动的迭代器。每次调用 NextRawPart，解析器会寻找下一个边界并返回一个 Part；前一个 Part 没有读完时，Reader 仍可能在下一次调用中帮你消耗剩余内容，所以业务代码最好把当前 Part 读完再继续。

NextPart 与它的返回类型相同，但对 quoted-printable 有额外处理：读取 Part 时会透明解码，并隐藏对应的传输编码头。NextRawPart 则保留原始传输形式，适合需要核对原始字节、自己决定解码策略或排查上游报文的场景。

mr := multipart.NewReader(body, "demo-boundary")
part, err := mr.NextRawPart()
if err != nil {
    return err
}
raw, err := io.ReadAll(part)
if err != nil {
    return err
}
fmt.Printf("name=%q raw=%q\n", part.FormName(), raw)

这段代码的可见成功状态是：part 非空，io.ReadAll(part) 返回 nil 错误，并且输出仍能看到上游传来的原始字节，也就是图中标出的 raw bytes。若把同一输入换成 NextPart，遇到 quoted-printable 时，读取结果可能已经是解码后的内容；这不是 boundary 变化，而是两个方法的职责不同。

带前导换行时，边界判断看什么

multipart body 通常以 boundary 行分隔各个 Part，边界前的 CRLF 属于分隔语法。不要在业务层先用 strings.TrimSpace 改写整个 body，再交给 Reader；这样会把字段值末尾本来合法的空白也一并删掉。更稳妥的做法是让 Reader 识别 boundary，只在读取当前 Part.Read 返回的数据上做字段级规则。

for {
    part, err := mr.NextRawPart()
    if err == io.EOF {
        break
    }
    if err != nil {
        return fmt.Errorf("next multipart part: %w", err)
    }

    data, err := io.ReadAll(part)
    if err != nil {
        return fmt.Errorf("read multipart part: %w", err)
    }
    fmt.Printf("field=%q bytes=%d\n", part.FormName(), len(data))
}

这里的成功状态是循环能打印每个字段，最后一次调用 NextRawPart 返回 io.EOF 后正常退出；中途的其他错误才需要记录为解析失败。即使某个 Part 的内容为空，也应该看到它的字段名并完成一次读取，而不是用“字节数为零”判断它不存在。

如果输入来自 HTTP 请求，还要把 boundary 从 Content-Type 的参数中解析出来，再交给 multipart.NewReader。不要从整条 header 字符串里手工截取引号或分号；参数转义、大小写和空格都可能让这种截取在另一份请求上失效。对于不可信请求，仍应在进入 Reader 前限制 body 大小，并对字段数量、单个 Part 大小设置业务上限。

一个可复现的最小检查方法

排查时可以构造两个 Part：第一个 Part 的值使用普通文本，第二个 Part 带上 Content-Transfer-Encoding: quoted-printable，并在每个 boundary 前保留标准 CRLF。分别调用 NextPart 和 NextRawPart，只比较第二个 Part 的读取字节；如果第一个结果已经解码、第二个结果仍保留传输编码，就说明 Reader 工作正常，差异来自方法契约。

最终检查清单很短：boundary 来自 Content-Type 参数；当前 Part 先读完；NextRawPart 只在需要原始传输字节时使用；io.EOF 只表示迭代结束；字段内容不要在 Reader 之前统一 Trim。这样即使报文在 boundary 前带有 CRLF，也不会把分隔符误当成业务字段，更不会把正常结束误报成损坏请求。

常见问题：NextRawPart 的边界与读取

为什么不直接用 ReadForm？

ReadForm 适合把 form-data 整体解析成表单和文件集合；如果你要保留原始传输编码、逐 Part 记录诊断信息，或需要在每个 Part 读取时执行自己的限额和校验，手动迭代更容易看清边界。

Part 没读完能直接调用 NextRawPart 吗？

解析器会处理输入流的推进，但业务代码仍建议先读完当前 Part，并在读取错误时立即退出。这样日志中的字段、字节数和失败位置是一致的，也不会把前一个 Part 的残留内容误归到下一个字段。