Go quotedprintable.Writer 怎样冲刷尾部并保留底层连接

quotedprintable.Writer 写完正文后应显式调用并检查 Close()，让编码器把尚未输出的尾部写到底层。这个 Close 不会关闭底层 io.Writer；若它包着 bufio.Writer，还要由调用方在编码器完成后调用 Flush。真实连接何时关闭，由持有连接的代码决定。

官方文档：https://pkg.go.dev/mime/quotedprintable

现象：Write 成功，尾部却还没出现在输出里

邮件正文编码后少了最后几个字符，或短正文一直没有显示，不一定是字符串被截断。Write 接受了输入，并不表示所有编码字节已经抵达最终输出端。quoted-printable 编码器自身会保留部分数据，下层又可能有独立缓冲。

最小处理原则是：正文输入正常完成后检查编码器 Close 的返回值，再处理外层输出缓冲。不要只看到 Write 没报错，就把整个正文写入判定为成功；也不要通过关闭整条连接来代替编码层的完成动作。

分层检查：编码器、输出缓冲和连接不是同一层

常见包装关系是：业务函数持有 encoder，encoder 的底层目标是 buffered，buffered 再持有 sink。本文的 sink 使用内存 bytes.Buffer；在真实程序中，它也可能是文件或网络连接。三个对象有不同的生命周期。

encoder.Close 只把编码层残留字节交给它直接持有的 Writer。如果这个 Writer 是 bufio.Writer，字节仍可能停留在输出缓冲中。buffered.Flush 才负责把该缓冲里的字节提交给 sink。网络端还需要自己的协议确认，Flush 成功不能被描述成远端业务已经处理成功。

证据判断：Close 不会取得底层连接的关闭权

官方文档明确说明，quotedprintable.Writer.Close 会刷新尚未写出的编码数据，但不会关闭底层 Writer。NewWriter 接收的类型也是 io.Writer，接口本身只承诺写入能力，不要求提供 Close。

因此，“担心 encoder.Close 导致连接断开”不是省略它的理由。需要追查的应该是业务代码是否另外调用了连接 Close，是否由上层协议结束当前正文，或者其他包装器是否有自己的关闭策略。不要把所有名为 Close 的方法都理解为同一种资源动作。

修复动作：返回编码错误，把缓冲权留给调用方

以下示例把正文编码封装为 WriteBody。函数不关闭 dst，也不擅自刷新调用方拥有的缓冲。演示程序用内存输出替代真实连接，展示编码器完成后底层 Writer 仍可继续接收内容。

package main

import (
    "bufio"
    "bytes"
    "fmt"
    "io"
    "mime/quotedprintable"
)

// WriteBody 只完成编码层，不取得 dst 的关闭权。
func WriteBody(dst io.Writer, text string) error {
    encoder := quotedprintable.NewWriter(dst)
    if _, err := io.WriteString(encoder, text); err != nil {
        return fmt.Errorf("写入编码正文：%w", err)
    }
    // Close 可能首次触及底层写错误，必须显式返回。
    if err := encoder.Close(); err != nil {
        return fmt.Errorf("完成编码正文：%w", err)
    }
    return nil
}

func demo() error {
    // 用内存接收器模拟输出端，不建立真实网络连接。
    var sink bytes.Buffer
    buffered := bufio.NewWriter(&sink)
    if err := WriteBody(buffered, "item=7"); err != nil {
        return err
    }
    // 编码层完成后，再刷新调用方持有的缓冲层。
    if err := buffered.Flush(); err != nil {
        return fmt.Errorf("刷新输出缓冲：%w", err)
    }
    fmt.Printf("编码正文：%q\n", sink.String())

    // 编码器 Close 不会关闭底层；调用方仍能写原始后续内容。
    if _, err := io.WriteString(buffered, "\r\nNEXT"); err != nil {
        return err
    }
    if err := buffered.Flush(); err != nil {
        return err
    }
    fmt.Printf("后续内容写入后：%q\n", sink.String())
    return nil
}

func main() {
    if err := demo(); err != nil {
        fmt.Println("处理失败：", err)
    }
}

按代码语义，第一次输出应包含 item=3D7，因为等号需要编码；后续原始写入的换行和 NEXT 属于调用方追加内容。这是语义预期，不是运行日志。这个拼接例子只解释 Writer 的资源边界，不是完整 MIME 邮件或 SMTP 会话的实现。

实际 MIME 多段正文的分隔符应由上层 MIME 组件负责，不要把分隔符也写进已经完成的 quoted-printable 编码器。新的一段编码正文应创建自己的编码器；不要依赖 Close 之后继续向同一个编码器 Write 的行为。

反向推演：哪些位置失败时不能继续当作成功

如果正文 Write 已经失败，示例立即返回，避免把一个未完成的正文标成成功。若 Write 成功而 Close 失败，同样返回错误：剩余编码字节可能没有完整写出。如果 Close 成功但 buffered.Flush 失败，调用方仍不能认为最终输出完整。

不要对可能已经部分写入的网络消息直接重跑整段编码，否则可能出现重复内容。发生部分写入后，是否丢弃当前协议消息、重建连接或按业务标识重试，应由上层协议决定。这里的编码函数没有事务或回滚能力。

仅写 defer encoder.Close() 容易丢失最后的写错误。defer 可以参与资源收尾，但对于决定正文是否完整的操作，应显式检查错误，或使用能保留返回错误的专门封装。也不要先 Flush 再 Close 后就离开函数：Close 可能又向输出缓冲加入尾部数据。

生命周期清单与常见问题

底层是 bytes.Buffer 还需要 Flush 吗？直接传给编码器时没有 bufio 这一层，无须额外调用 bufio.Flush，但仍应完成编码器 Close。

编码器自己有 Flush 方法吗？这个 Writer 的公开完成接口是 Close，不要套用 bufio.Writer 的方法名。

Close 会补一个邮件结束标记吗？不能把它当成 MIME 边界或 SMTP 正文结束命令。它完成的是 quoted-printable 编码，协议结束由相应上层组件处理。

参考：quotedprintable.Writer.Close；bufio.Writer.Flush。