Go sql.Conn.Raw 怎么访问驱动层连接能力

sql.Conn.Raw 适合解决一个很窄的问题：应用仍由 database/sql 管理连接池，但偶尔需要调用标准接口没有暴露的驱动原生能力。正确做法是先用 DB.Conn 取得专用连接，再把所有原生操作限制在 Raw 回调内部；不要把底层连接保存到回调外，也不要把 Raw 当成普通查询的性能开关。

核心边界：driverConn 只在回调执行期间有效。回调正常返回后，sql.Conn 通常还能继续使用；若返回 driver.ErrBadConn，这条连接会被判定为不可复用。

先确定 Raw 解决的是能力缺口

database/sql 已经覆盖查询、执行、事务、预处理和连接池等通用能力。只有批量复制、协议级通知、驱动专属类型或底层连接参数等能力无法从标准接口表达时，才需要 Raw。它不会自动让 SQL 更快；是否值得使用，应由原生能力带来的结果和真实测量决定。

这些指标是部署后要采集的测量项，不是本文虚构的基准结果。若标准接口已经能完成任务，就继续使用 DB.ExecContext 或 DB.QueryContext，能减少驱动耦合和连接生命周期风险。

最小封装：只在 Raw 回调里使用原生连接

下面用 pgx 的 stdlib 适配层演示。pgx 官方公开了 *stdlib.Conn，其 Conn() 方法返回 *pgx.Conn。其他驱动的底层类型并不相同，必须按对应驱动的官方文档替换断言目标。

package rawpgx

import (
    "context"
    "database/sql"
    "fmt"

    "github.com/jackc/pgx/v5"
    "github.com/jackc/pgx/v5/stdlib"
)

// WithConn 把原生 pgx 连接的生命周期限制在 Raw 回调内部。
func WithConn(ctx context.Context, db *sql.DB, fn func(*pgx.Conn) error) error {
    // 从连接池取得一条专用 sql.Conn；ctx 只控制获取连接的等待过程。
    conn, err := db.Conn(ctx)
    if err != nil {
        return fmt.Errorf("获取专用数据库连接: %w", err)
    }
    // 无论回调成功与否，都要把 sql.Conn 归还给连接池。
    defer conn.Close()

    return conn.Raw(func(driverConn any) error {
        // 类型不匹配是配置错误，不能用 panic 或 driver.ErrBadConn 代替。
        stdlibConn, ok := driverConn.(*stdlib.Conn)
        if !ok {
            return fmt.Errorf("底层驱动类型为 %T，不是 *stdlib.Conn", driverConn)
        }

        // fn 必须同步结束，不能把 native 保存到回调外或交给 goroutine。
        native := stdlibConn.Conn()
        return fn(native)
    })
}

Raw 自身没有 context.Context 参数。需要取消或超时时，把同一个 ctx 传给原生驱动方法，并确保原生方法遵守上下文。Go 标准库源码还显示，回调执行期间会持有驱动连接内部锁，因此回调应保持同步、短小且有明确超时。

把驱动专属能力放进同一个作用域

有了上面的边界封装，驱动专属的 CopyFrom 可以直接放在回调内。返回到调用方的只是复制行数和错误，不返回 *pgx.Conn、结果游标或任何依赖底层连接继续存活的对象。

// CopyEvents 使用 pgx 的 CopyFrom 批量写入，并只返回稳定的值结果。
func CopyEvents(ctx context.Context, db *sql.DB, rows [][]any) (int64, error) {
    var copied int64

    err := WithConn(ctx, db, func(native *pgx.Conn) error {
        // 原生操作完整发生在 Raw 回调内，ctx 同时约束数据库调用。
        n, err := native.CopyFrom(
            ctx,
            pgx.Identifier{"events"},
            []string{"event_id", "payload"},
            pgx.CopyFromRows(rows),
        )
        if err != nil {
            return fmt.Errorf("CopyFrom 写入 events: %w", err)
        }
        copied = n
        return nil
    })
    if err != nil {
        return 0, err
    }
    return copied, nil
}

如果应用大量依赖 pgx 原生能力，长期通过 Raw 穿透适配层会增加耦合。此时应比较“继续使用 database/sql 并局部逃生”和“直接采用 pgx 原生接口”两种架构，而不是让每个仓储方法都重复断言。

错误怎么返回，连接什么时候会被丢弃

回调返回普通错误时，Raw 会把错误交给调用方，但该 sql.Conn 仍可在关闭前继续使用。只有确认底层物理连接已经不可用时，才返回 driver.ErrBadConn。标准库会据此丢弃连接，并使当前 sql.Conn 后续操作返回 sql.ErrConnDone。

return conn.Raw(func(driverConn any) error {
    stdlibConn, ok := driverConn.(*stdlib.Conn)
    if !ok {
        // 普通配置错误：保留真实原因，不谎报底层连接已经损坏。
        return fmt.Errorf("不支持的驱动连接类型 %T", driverConn)
    }

    native := stdlibConn.Conn()
    if native.IsClosed() {
        // 仅当原生连接确实不可用时，才通知 database/sql 丢弃它。
        return driver.ErrBadConn
    }
    return useNative(native)
})

这段代码还需要在 import 中加入 database/sql/driver。不要为了触发重试而滥用 driver.ErrBadConn：Conn.Raw 本身不会替你重放任意原生操作，尤其是已经产生副作用的写入。回调发生 panic 时，标准库也会把连接按坏连接处理后继续抛出 panic，所以 panic 不能当成分支控制。

发布前用四组场景核对边界

第一组让类型断言失败，确认返回的是带实际类型的普通错误；第二组让原生操作返回业务错误，确认错误能被包装且连接正常归还；第三组只在明确检测到连接关闭时返回 driver.ErrBadConn，确认后续操作得到 sql.ErrConnDone；第四组在并发负载下观察 DB.Stats()，确认 Raw 回调没有让 WaitCount 和连接占用时间异常上涨。

如果需要比较性能，应在相同数据量、事务边界、网络环境和连接池配置下，对标准写法、Raw 原生写法以及直接驱动写法分别压测。结论只采用真实测量值；单凭少一层接口调用，不能推导数据库操作一定更快。

相关问题

可以从 Raw 回调返回 *pgx.Conn 吗？

不可以。Go 文档明确要求底层驱动连接不能在回调外使用。应在回调内完成原生操作，只向外返回复制后的普通值或业务结果。

Raw 回调能启动 goroutine 吗？

不要把底层连接交给 goroutine 后提前返回。回调一结束，驱动连接的借用边界就结束；异步任务应在回调内等待完成，或改用驱动原生连接池管理生命周期。

调用 Raw 后还需要 Conn.Close 吗？

需要。DB.Conn 取得的是一条专用连接，使用完必须调用 Conn.Close 归还连接池。最简单的写法就是获取成功后立即 defer conn.Close()。

普通类型断言失败应该返回 driver.ErrBadConn 吗？

不应该。类型不匹配通常说明驱动配置或封装假设错误，并不等于物理连接损坏；返回普通错误更准确，也避免无谓销毁连接。