在Go的数据库生态里，database/sql 包无疑是最成功的抽象之一。它统一了接口，让开发者几乎不用关心底层驱动。但如果你深入用过像pgx这样功能丰富的驱动，可能会隐约感觉到一种“不对等”——尤其是在处理复杂数据类型时。这种别扭的感觉，根源在于一个存在了十几年的结构性问题：驱动对查询参数的写入有话语权，但对结果读取的控制力却近乎为零。
Go 1.27 引入的 driver.RowsColumnScanner 接口，正是为了解决这个问题。它不是一个你会天天手动调用的新API，但它正在悄然改变驱动与标准库之间的权力格局。
一个所有 Go 数据库开发者都遇到过的问题
先看一段最常见的Go数据库操作代码：
var name string
var createdAt time.Time
err := db.QueryRow("SELECT name, created_at FROM users WHERE id = $1", id).
Scan(&name, &createdAt)表面上看，代码干净利落。但如果你用的驱动支持更丰富的类型（比如PostgreSQL的UUID、数组），就会察觉到一种微妙的不公。
当你传入查询参数时，驱动可以通过实现 driver.NamedValueChecker 接口来检查、转换甚至拒绝参数，主动权在握。然而，当你调用 rows.Scan 读取结果时，流程就变了味：
rows.Next()让驱动把当前行的数据填充到一个[]driver.Value（也就是[]any）切片里。rows.Scan(dest...)遍历这个切片，使用database/sql内置的convertAssign函数，将any转换成你提供的目标类型。
问题就出在第二步。驱动被完全架空了。无论它对当前数据库连接、字段的二进制格式有多了解，标准库都只会按照自己那套固定的规则进行类型转换。
在只有 string、int64、time.Time 的简单世界里，这没问题。但现实中的数据库，类型系统要复杂得多。
数组、UUID、自定义类型——那些被逼着绕路走的数据
以PostgreSQL为例。假设有一张用户表，包含了UUID和标签数组：
CREATE TABLE users (
id UUID PRIMARY KEY,
tags TEXT[]
);如果使用pgx的原生接口，映射到Go类型非常自然：
var id uuid.UUID
var tags []string
err := conn.QueryRow(ctx, "SELECT id, tags FROM users WHERE id = $1", id).
Scan(&id, &tags)驱动知道UUID的二进制格式，也知道如何将 TEXT[] 的二进制表示还原成Go的字符串切片。一切都在底层高效完成。
但一旦换到 database/sql 的标准接口，这些便利就消失了。因为驱动返回的 []any 切片，到了标准库那里，它不认识 pgtype.UUID，也不认识 []string。
于是，驱动只剩下两个都不怎么好的选择：
- 放弃二进制格式：把数据转成文本字符串塞进
[]any，让标准库去解析。这等于把已经解析好的数据重新序列化，再让客户端解析一遍，纯属性能浪费。 - 让开发者自己处理：要求用户为每个复杂类型实现
sql.Scanner接口。这带来了大量样板代码，而且这些Scanner实现是“盲”的，它们拿不到连接上下文、字段类型等关键信息，只能在黑暗中摸索转换。
这正是pgx作者jackc在提出相关提案时描述的核心困境：驱动拥有一套灵活强大的类型系统，但在读取结果这一侧，标准库完全不给它施展的机会。
RowsColumnScanner：驱动手握方向盘的那一刻
Go 1.27 在 database/sql/driver
type RowsColumnScanner interface {
Rows
ScanColumn(dest any, n int) error
}当驱动实现了这个接口后，database/sql 在调用 rows.Scan 时，就不再走自己那套 convertAssign 逻辑了。它会将每一次扫描操作，直接委托给驱动的 ScanColumn(dest, index) 方法。
更妙的是，如果驱动对某一列不想处理（或者暂时没处理），它可以返回 driver.ErrSkip 错误。这时，标准库就会退回到原来的转换路径。这意味着驱动可以采取渐进策略，先接管自己有绝对把握的类型，其他的保持原样。
这看似只是增加了一个方法，实则翻转了权力关系。以前是标准库从驱动那里拿到一包“原材料”（[]any）后自己加工；现在是每一步加工都询问驱动：“这个零件，你想怎么装？”
二进制格式：一个直接的性能收益
新接口最直接的性能提升，来自于驱动可以放心使用二进制格式传输数据。
以PostgreSQL的libpq协议为例，字段数据可以用文本格式传输，也可以用二进制格式传输。二进制格式的解析开销远低于文本格式——它省去了词法分析、转义处理和字符串转换等步骤。
但在过去，如果驱动知道数据最终要经过标准库的 convertAssign 处理，它往往只能选择文本格式。因为 convertAssign 只认识有限的几种基础类型（string, int64, []byte, time.Time 等）。一条用二进制格式传回的UUID列，标准库根本不知道如何将它转换成 string。
pgx的基准测试印证了这一点。对于一个查询1000行 text[] 数据的场景，使用二进制格式相比文本格式，在内存分配次数上差了一个数量级。文本路径需要将数组序列化成 {a,b,c} 这样的字符串，客户端再重新解析；而二进制路径可以直接将数组元素按内存布局拷贝，没有中间字符串的转换损耗。
有了 RowsColumnScanner，驱动在 Next() 阶段就能预知自己将处理后续的扫描，从而可以全程采用高效的二进制格式。即使部分列因返回 ErrSkip 而回退到旧路径，主路径上的性能增益依然是实实在在的。
对 Go 工程实践的影响
这一变化，会在几个方面影响我们的日常开发：
第一，自定义类型映射变得更自然。 目前，很多项目会在 database/sql 之上再封装一层，用以处理自增ID、JSONB字段、枚举类型与Go常量之间的映射。这些封装层存在的一个重要原因，就是驱动在扫描端使不上劲。现在，驱动可以在扫描点直接完成这些映射，无需额外的封装层、ORM介入，也不必为每个类型编写独立的 Scanner 适配器。
第二，AI生成的数据库代码会更可靠。 AI助手在编写数据库操作代码时，一个常见难点是它不确定某个数据库字段应该映射到哪种具体的Go类型。created_at 是 time.Time 还是 string？status 是 int 还是自定义枚举？config 字段该用 json.RawMessage 还是某个具体的结构体？现在，驱动可以在扫描时直接给出答案，AI生成的代码不必在事后打上一堆类型断言或转换的补丁。
第三，性能敏感的服务需要重新评估扫描路径。 如果你的服务大量使用 database/sql 配合pgx这类高级驱动，升级到Go 1.27后，那些涉及UUID、数组、范围、复合类型等复杂字段的查询，其扫描路径的内存分配次数很可能会显著下降。虽然未必能达到“零分配”，但文本格式作为中间转换站的场景将大幅减少。
不要急着把所有驱动都切过来
在拥抱新特性的同时，也需要冷静看待潜在的兼容性风险。
database/sql 内置的 convertAssign 有一套非常精确的行为定义。例如，将一个 time.Time 值扫描到 *string 时，标准库会将其格式化为 time.RFC3339Nano 字符串。如果驱动的 ScanColumn 方法直接返回了驱动内部的文本表示，格式可能与此不同。
大多数情况下，这种差异并无大碍——只要输出的字符串能被通用的时间解析器识别，最终结果就是等价的。但如果你依赖了某种特定的字符串格式（例如直接进行字符串比较，或者将数据库值作为字符串对外暴露），那么在切换前后，务必进行一轮详细的对比测试。
稳妥的升级策略是：先在测试环境中启用驱动对扫描的接管，运行完整的集成测试，并进行新旧行为的结果diff检查，确认没有意外变化后，再部署到生产环境。
这件事为什么值得写一篇文章
归根结底，RowsColumnScanner 不是一个你会显式调用的日常API。它的深远意义在于，它解开了Go数据库生态中一个长达十几年的结构性症结——参数的写入和结果的读取，本就不应被区别对待。
在过去，这种“不对等”尚可忍受，因为业务类型相对简单。但随着PostgreSQL的数组、JSONB、范围、复合类型，以及SQLite的动态类型在业务中广泛应用，这个症结从“可以忽略”变成了“必须解决”的拦路虎。
Go 1.27 移开了这只拦路虎。对于像pgx、modernc.org/sqlite这样拥有强大原生类型系统的驱动而言，这意味着它们终于在 database/sql 的读写两端，都拿到了本该属于自己的、完整的话语权。这不仅是性能的提升，更是生态走向成熟与完善的关键一步。
