Go sql.Conn.Raw 修改驱动状态后为什么不建议继续复用连接

用 sql.Conn.Raw 改过驱动私有状态后，不建议无条件继续复用同一个连接。原因不是 Raw 回调结束后 *sql.Conn 必然失效，而是 database/sql 看不懂驱动内部状态：回调返回普通错误时，它仍会把 Conn 当成可用连接；只有返回或包装 driver.ErrBadConn，才会进入连接淘汰路径。换句话说，能否复用取决于驱动有没有明确的恢复契约。

Raw 回调结束后，Conn 到底还剩什么保证

官方对 Raw 的定义很窄：它在回调执行期间暴露底层 driver connection，回调参数不能在外部继续使用。标准库内部会锁住驱动连接，执行回调，再根据返回错误释放它。回调返回后，真正仍然由应用持有的是高层 *sql.Conn，不是可以任意操作的底层对象。

因此，下面这种写法的问题不在类型转换，而在生命周期逃逸：

var saved any
err := conn.Raw(func(driverConn any) error {
    // 底层连接只允许在这个回调里使用，不能交给异步任务。
    saved = driverConn
    return nil
})
_ = err
_ = saved

即使这次回调返回 nil，也不代表驱动状态已经恢复。比如驱动私有接口切换了会话模式、设置了连接级开关，或者记录了需要下一次请求清理的标志，database/sql 并不会自动理解这些业务含义。

先判断状态能不能被连接池恢复

连接池复用的危险点通常出现在“当前请求结束以后”。当前请求可能已经拿到预期结果，但下一次从池里取到同一物理连接的请求，会继承未清理的驱动状态。判断时可以先按下面的表格分层：

注意，SessionResetter 不是“所有 Raw 改动的万能清理器”。它是否实现、何时被调用、能否覆盖你改动的私有字段，都属于具体驱动契约。没有看到这份契约时，不能仅凭连接还能执行一次查询，就断定它适合长期复用。

什么时候应该返回 driver.ErrBadConn

如果驱动私有状态已经无法安全恢复，可以在 Raw 回调里返回 driver.ErrBadConn。下面的 sessionMutator 是示意接口，实际项目必须替换成目标驱动提供的真实接口：

type sessionMutator interface {
    SetSessionMode(string) error
}

func useAndDiscard(conn *sql.Conn) error {
    return conn.Raw(func(driverConn any) error {
        mutator, ok := driverConn.(sessionMutator)
        if !ok {
            // 驱动不支持该能力时，不伪造成功状态。
            return fmt.Errorf("driver does not expose session mutator")
        }
        if err := mutator.SetSessionMode("special"); err != nil {
            // 普通驱动错误要保留原错误，避免误触发重试语义。
            return err
        }
        // 状态无法确认已恢复，让 database/sql 淘汰这条连接。
        return driver.ErrBadConn
    })
}

ErrBadConn 的含义不是“这次业务操作失败了”这么简单，而是告诉 database/sql：这条 driver.Conn 已处于不应再进入普通复用流程的状态。它会让高层 Conn 进入关闭路径。使用它前要确认没有把“服务端可能已经执行成功的 SQL”误标成可安全重试的坏连接；本例讨论的是连接状态被主动改坏或无法恢复的场景。

把 Conn.Close 放在明确的拥有边界

db.Conn(ctx) 取得的是一条绑定到单个数据库会话的高层连接，使用完必须调用 Close。它通常把连接归还连接池；如果前面已通过 ErrBadConn 标记失效，则走的是淘汰而不是普通复用。一个更稳妥的外层结构如下：

func withRawState(ctx context.Context, db *sql.DB) error {
    conn, err := db.Conn(ctx)
    if err != nil {
        return err
    }
    defer func() {
        // 关闭高层 Conn，归还或释放底层连接。
        _ = conn.Close()
    }()

    if err := useAndDiscard(conn); err != nil {
        // 不在这里继续执行依赖旧驱动状态的高层查询。
        return err
    }
    return nil
}

如果驱动文档明确保证状态可逆，代码可以在 Raw 返回后继续使用 Conn，但仍要把恢复动作写在同一个回调或紧邻的错误处理路径里，并为恢复失败设计淘汰策略。对未知驱动版本、连接级开关和跨请求会话状态，宁可牺牲一条连接，也不要把隐性状态交给下一个请求。

延伸问答

Raw 返回 nil 后，Conn 一定可以继续用吗？

从标准库语义看，只要返回错误不是 driver.ErrBadConn，Conn 会继续被视为可用；但这不等于驱动私有状态已经恢复。是否安全仍要看驱动契约。

能不能直接调用 Conn.Close 让连接一定销毁？

不能把 Close 理解成物理销毁。普通 Close 的职责是把连接归还池；需要淘汰时，应在合适的 Raw 错误路径表达 ErrBadConn。

为什么不把 driver.Conn 保存起来下次继续用？

因为 Raw 明确限制底层连接只在回调期间有效，连接锁和池生命周期都由 database/sql 管理。保存底层对象会同时绕过这些约束。