Go ColumnType.Nullable 返回不支持时怎么兼容不同数据库驱动

在 Go 的 database/sql 中，ColumnType.Nullable() 不是只返回一个“能不能为 NULL”的布尔值，而是返回 (nullable, ok bool)。跨数据库驱动时，真正重要的是先看 ok：当 ok=false 时，驱动没有提供这项元数据，不能把第一个返回值 false 当成“明确不可空”。

官方地址：https://pkg.go.dev/database/sql#ColumnType.Nullable

兼容写法只有一个核心原则：ok=true 才消费 nullable；ok=false 就把状态保留为 unknown。如果业务必须得到强结论，再进入绑定具体数据库的方言适配，而不是在通用层猜测。

先看懂 Nullable 的两个返回值

Rows.ColumnTypes() 返回结果列的 *sql.ColumnType。对其中一列调用 Nullable() 时，可以把返回值理解成两层信息：

• nullable 是驱动给出的列可空判断；只有在 ok=true 时它才有业务意义。
• ok 是能力标志，表示当前驱动是否支持报告这项属性。

因此它实际表达的是三种状态，而不是两个状态：

把返回值转换成应用自己的三态

如果直接把 nullable 存进结构体，调用方很容易忘记检查 ok。更稳妥的做法是定义一个明确的三态类型，把驱动的二元返回值在边界处转换一次：

package metadata

import "database/sql"

// Nullability 表示结果列的可空性，Unknown 不等于 NotNull。
type Nullability uint8

const (
	// NullabilityUnknown 表示驱动没有提供可靠的可空元数据。
	NullabilityUnknown Nullability = iota
	// NullabilityNotNull 表示驱动明确报告不可空。
	NullabilityNotNull
	// NullabilityNullable 表示驱动明确报告可能为 NULL。
	NullabilityNullable
)

// nullabilityOf 只在 ok 为 true 时消费 nullable。
func nullabilityOf(column *sql.ColumnType) Nullability {
	nullable, ok := column.Nullable()
	if !ok {
		// false 只是返回值的一部分，不能在这里推导出“不可空”。
		return NullabilityUnknown
	}
	if nullable {
		return NullabilityNullable
	}
	return NullabilityNotNull
}

这个转换的价值在于：后续代码看到 NullabilityNotNull 时，可以确认它来自驱动的明确回答；看到 NullabilityUnknown 时，也不会误以为是数据库不允许 NULL。

读取列元数据时不要丢掉 unknown

通用的结果描述器通常还需要列名。下面的写法把 ColumnTypes 的错误和每列的未知状态都保留下来，适合导出表结构、生成接口描述或绘制结果集字段说明：

package metadata

import "database/sql"

// ColumnMeta 是供上层展示或生成文档使用的最小元数据。
type ColumnMeta struct {
	Name       string
	Nullability Nullability
}

// DescribeRows 收集驱动能提供的列信息，不为 unknown 猜一个默认值。
func DescribeRows(rows *sql.Rows) ([]ColumnMeta, error) {
	columns, err := rows.ColumnTypes()
	if err != nil {
		// 读取列元数据失败时交给调用方决定是否重试或降级。
		return nil, err
	}

	result := make([]ColumnMeta, 0, len(columns))
	for _, column := range columns {
		// Name 可以用于展示；可空性仍然经过三态转换。
		result = append(result, ColumnMeta{
			Name:        column.Name(),
			Nullability: nullabilityOf(column),
		})
	}
	return result, nil
}

注意这里的 unknown 不是错误。它表示“当前抽象层拿不到答案”，而不是查询失败。比如一个通用数据查看器可以把这一列显示为“未知”，继续展示结果；一个需要生成严格模型的工具则可以停止生成并提示用户选择具体数据库适配器。

跨驱动代码应该怎样消费未知状态

跨驱动场景最容易出现的错误，是把三态压扁成一个 bool：

// badNullable 把 unknown 错误地压成了 false，不适合跨驱动元数据。
func badNullable(column *sql.ColumnType) bool {
	nullable, _ := column.Nullable()
	return nullable
}

这段代码在驱动不支持 Nullable 时会返回 false，调用方如果据此生成“不可空”字段，就把能力缺失变成了错误事实。兼容层应该让下游显式处理三态，例如：

// NullabilityLabel 把三态转换成用户可读标签，但不隐藏未知状态。
func NullabilityLabel(value Nullability) string {
	switch value {
	case NullabilityNullable:
		return "nullable"
	case NullabilityNotNull:
		return "not-null"
	default:
		// unknown 需要在界面、文档或生成器中保持可见。
		return "unknown"
	}
}

什么时候需要数据库方言适配

如果业务只是把查询结果展示给用户，保留 unknown 往往就是最兼容的方案。如果业务必须生成严格的结构定义、自动生成校验器或决定某个写入策略，通用 database/sql 层可能不够，此时可以增加一个明确的适配边界：

• 先确认应用绑定的数据库产品、驱动和版本范围，再使用该数据库的官方元数据接口或维护好的适配器。
• 让适配器返回与通用层相同的三态类型；无法确认时仍返回 unknown。
• 把方言查询放在独立包内，不让通用代码根据 DatabaseTypeName、ScanType 或一次样本值臆测可空性。
• 如果使用配置覆盖，记录覆盖来源和适用连接类型，避免同一份配置被不同数据库复用。

这里的重点不是“永远不能查询数据库元数据”，而是不要把特定数据库的推断伪装成所有驱动都成立的标准行为。

最后用这张清单检查兼容实现

一句话总结：ColumnType.Nullable 的兼容关键不是给 ok=false 选一个默认答案，而是把“驱动没有回答”作为一等状态保留下来。这样同一套 Go 代码面对不同数据库驱动时，最多是信息不足，不会悄悄生成相反的结论。

常见追问

ok=false 时 nullable 一定是 false 吗？

调用方不应该依赖它的具体值。文档定义的是驱动不支持该属性时 ok 为 false，因此兼容逻辑只消费 ok=true 时的 nullable。

能不能用 ScanType() 判断列是否可空？

不建议。ScanType 描述适合扫描的 Go 类型，和驱动是否报告列可空是不同的元数据；把两者互相推导会让跨驱动行为不稳定。

结果列是表达式时也能直接当作表字段规则吗？

不要无条件这么做。Nullable 是驱动对结果列元数据的报告，不应被扩展成对所有查询表达式、业务模型和写入约束的完整证明；需要强约束时仍应使用明确的 schema 或方言适配。