Go go-smtp 的 Quit 与 Close 有什么区别

go-smtp的 Client.Quit() 发送SMTP的QUIT命令并结束连接；Client.Close() 直接关闭底层连接。正常结束且会话可用时可选择Quit，异常清理时要有Close兜底，不能假设Quit返回错误也已经释放资源。

我比较这两个方法时，会先问“需要完成协议告别，还是只需要收回连接”。名字都像退出，但关注点不同。这里的讨论基于官方接口和源码，不是一次真实发信复盘，也没有把方法差异包装成新版本提案。

官方地址：https://pkg.go.dev/github.com/emersion/go-smtp

一个结束SMTP会话，一个直接关闭连接

官方实现中，Quit先处理会话问候，再发送QUIT并期待221响应，成功后调用Close。问候或QUIT交互出错时会提前返回。Close则是直接清理连接资源，不通过QUIT交互表达正常结束。

对我来说，最容易忽略的代价是把Quit放进所有路径后，就不再安排直接关闭。网络已经异常时，协议交互未必成功；资源所有者仍应负责最后的释放。

Quit报错后为什么还要安排Close

项目源码的注释明确要求Quit失败时使用Close。这意味着调用者不能把“尝试过优雅退出”当成“连接已确定关闭”。如果一个函数拥有客户端，就应让退出失败也回到同一处清理，而不是依赖上层猜测。

我倾向让成功分支显式调用Quit，错误分支统一直接关闭。这样日志可以分别标识业务错误、协议退出错误和资源清理错误。退出失败不需要抹掉较早的业务错误，清理失败也不该被无声吞掉。

用独立生命周期封装兜底清理

下面的原创函数片段接收已经创建的客户端和业务回调。连接建立、TLS、认证和邮件内容由调用方负责；它只演示退出和清理，没有连接服务器或发送真实邮件。示例使用errors.Join，需要Go 1.20及以上。

package lifecycle

import (
    "errors"
    "fmt"
    "time"

    smtp "github.com/emersion/go-smtp"
)

// OwnClient独占c的生命周期；work不得自行关闭c或把它交给并发任务。
func OwnClient(c *smtp.Client, work func(*smtp.Client) error) (err error) {
    // 示例等待预算按业务调整；这是命令响应超时，不是整封邮件的总期限。
    c.CommandTimeout = 10 * time.Second
    closed := false
    defer func() {
        if !closed {
            // work失败或Quit失败时直接关闭，保留主错误和清理错误。
            if closeErr := c.Close(); closeErr != nil {
                err = errors.Join(err, fmt.Errorf("关闭连接: %w", closeErr))
            }
        }
    }()

    if workErr := work(c); workErr != nil {
        return fmt.Errorf("业务操作失败: %w", workErr)
    }
    if quitErr := c.Quit(); quitErr != nil {
        return fmt.Errorf("业务操作已结束，SMTP退出失败: %w", quitErr)
    }
    // Quit成功已包含关闭操作，避免正常路径重复关闭。
    closed = true
    return nil
}

closed只在Quit成功后置为true。若work失败，defer负责Close；若Quit失败，也会尝试Close。在极少数已经尝试关闭但返回错误的路径中，兜底关闭可能再次报错，示例把它与原错误合并，让调用者了解实际情况。

这个封装的前提是独占客户端：work不能把连接留给其他任务继续用，也不能自行关闭。我的取舍是把所有权写进注释和接口约定，而不是让多个层级都觉得自己应该defer Quit。共享连接池应采用自己的归还与销毁规则，不能直接套这个函数。

退出错误不等于邮件投递结果

从应用语义上，我会把“业务操作的结果”和“连接退出的结果”分开保存。Quit是会话结束操作，不是用于查询收件箱最终到达情况的回执；业务回调若已经记录了提交状态，不应仅因为Quit报错就把原结果简单改成未执行。

反过来，work返回nil也不自动意味着收件人一定已经收到邮件。它究竟表示完成了什么，需要由回调所调用的业务接口决定。自动重试应依赖明确的业务状态与去重策略，不能一看退出错误就无条件重发。

这也是我不把一个error字段同时用作“提交是否发生”和“是否退出干净”的原因。对需要重试的任务，分别保存阶段结果比把所有失败折叠成一条“发送失败”更容易恢复。

超时与版本兼容怎么安排

示例把CommandTimeout设成十秒，这是演示的命令等待预算，不是通用推荐值，也不是总发信时长。官方客户端还有SubmissionTimeout等独立配置；处理邮件正文与结束会话时，不能把所有等待都理解成同一个阶段。

本文讨论的是github.com/emersion/go-smtp.Client，不是服务端的Server.Close，也不是其他包的同名方法。项目依赖若固定在其他版本，应以该版本接口为准。采用示例前，我会优先确认客户端所有权和错误分类，而不是只把Close替换成Quit。

常见问题

可以只defer Quit吗

不够稳妥。Quit可能在关闭前出错，资源所有者仍需Close兜底，并合理安排协议等待预算。

Quit成功后还必须再Close一次吗

成功路径已经包含关闭。可以像示例一样标记已关闭，避免正常情况下重复调用。

Close会帮我撤回已经提交的邮件吗

不能把连接关闭当成业务撤回。需要依据邮件提交阶段的实际结果处理，不能用连接生命周期代替邮件状态。

只想中止当前事务但继续用连接呢

那是Reset等协议操作的适用问题，不等同于Quit或Close。应另外核对当前会话状态与接口语义。

参考：go-smtp Client官方接口；项目client.go实现。