Go 1.27 database/sql.ConvertAssign 怎么复用 Rows.Scan 转换：驱动实现与类型错误边界

数据库驱动在扫描一行结果时，常常要把 driver.Value 转成调用方传进来的目标指针。过去，驱动作者要么依赖 Rows.Scan 间接完成这件事，要么自己维护一套容易漏掉边界的转换代码。Go 1.27 新增的 database/sql.ConvertAssign 把这段标准转换规则直接暴露出来，适合用在驱动内部的扫描适配层。

把 ConvertAssign 放在驱动的“源值到目标指针”边界，能复用 Rows.Scan 的转换语义；但它不替代 NULL 约定、目标类型校验和驱动自己的行生命周期管理。

Go 1.27 为什么把 ConvertAssign 交给驱动

Rows.Scan 面向应用层，驱动却同样需要处理“数据库值如何落到 Go 变量”这个问题。两边如果各写一套转换逻辑，字符串数字、字节切片和 nil 的行为就可能不一致。Go 1.27 的变化很小，但位置很明确：database/sql.ConvertAssign 让驱动可以调用标准库已有的转换路径。

最小调用链：从 driver.Value 写到目标指针

先把问题缩成一个驱动适配函数。这里不模拟网络协议，只验证标准转换边界：数据库层给出 driver.Value，适配层调用 ConvertAssign，最后由目标指针接收结果。

package main

import (
    "database/sql"
    "database/sql/driver"
    "fmt"
)

func scanOne(src driver.Value, dest any) error {
    return sql.ConvertAssign(dest, src)
}

func main() {
    var id int64
    var name string

    if err := scanOne(int64(42), &id); err != nil {
        panic(err)
    }
    if err := scanOne([]byte("Ada"), &name); err != nil {
        panic(err)
    }
    fmt.Printf("id=%d name=%s\n", id, name)
}

这段代码里，driver.Value 是源值，ConvertAssign 是转换边界，*int64 是可写目标。驱动真正实现 RowsColumnScanner 时，可以把类似调用放在列值已经拿到、尚未交给上层目标的那一层。

字符串数字、字节切片和 NULL 要分别验收

不要只测“整数写入整数”。数据库驱动更容易在跨类型和空值场景里出现差异。建议至少覆盖 string 到数字、[]byte 到字符串，以及 nil 到目标指针这三组测试。

func checkConversions() error {
    var count int64
    if err := sql.ConvertAssign(&count, "42"); err != nil {
        return err
    }

    var label string
    if err := sql.ConvertAssign(&label, []byte("ready")); err != nil {
        return err
    }

    var nullable sql.NullString
    if err := sql.ConvertAssign(&nullable, nil); err != nil {
        return err
    }
    if nullable.Valid {
        return fmt.Errorf("nil should make NullString invalid")
    }
    return nil
}

nil 不是“空字符串”或“0”。如果目标是 sql.NullString 这类可表达空值的类型，应核对它的 Valid 状态；如果目标是普通 *int64，则应把转换错误当作输入与字段约定不一致的信号，而不是悄悄填零。

驱动接入时，别把转换 API 当成 Rows 管理器

ConvertAssign 只处理赋值转换。驱动仍然要自己保证 Next 返回的列数量稳定、底层资源在 Close 后释放，并且在协议层 NULL 与 driver.Value 的映射上遵守 database/sql/driver 的约定。把所有问题都塞进转换函数，会让真正的行状态错误更难定位。

如果驱动提供了自定义的 RowsColumnScanner，建议把转换测试和行推进测试拆开：前者验证 ConvertAssign 的返回值和目标结果，后者验证列顺序、重复调用 Next、末尾状态和关闭路径。两类测试失败时，修复方向完全不同。

升级判断：哪些项目现在适合采用

新驱动或正在重写扫描层的项目，可以直接把 ConvertAssign 纳入适配层，减少与标准库的语义分叉。已经稳定运行的驱动则应先看支持的 Go 版本：Go 1.27 之前的工具链无法编译引用这个新增符号的代码，可以通过构建标签或保留旧实现来维持兼容矩阵。

采用前至少做一次对照测试：同一组 driver.Value，分别通过现有转换函数和 ConvertAssign 写入相同目标，重点比较错误、空值和字节切片处理。结果一致，再把改动拆成一个可回滚提交。

常见问题

ConvertAssign 只给数据库驱动使用吗？

它主要解决驱动复用 Rows.Scan 转换逻辑的需求，但任何需要遵循 database/sql 赋值语义的适配代码都可以评估使用。

目标参数必须是指针吗？

是。目标需要可写，传值而不是指针通常会得到错误；驱动应把错误原样保留并补充列名等上下文。

nil 能直接写入 int64 吗？

不应把它当作 0。普通数字目标无法表达 NULL 时，应返回错误或改用可空目标类型，具体取决于字段契约。

用了 ConvertAssign 就不用测试 Rows.Close 了吗？

不用。它只负责一次转换，结果集推进、关闭、资源释放和列数量检查仍由驱动与 Rows 实现负责。

把标准转换留在标准边界内

Go 1.27 的 database/sql.ConvertAssign 值得采用的理由不是代码少几行，而是驱动和 Rows.Scan 可以共享同一套类型转换语义。先用 driver.Value、目标指针和 Err 把边界测清楚，再处理行状态与版本兼容，改动才容易回退和复查。