本文详解 Go 枚举类型（int 底层）无法被 database/sql 驱动识别的根本原因，并通过将底层类型改为 int64、正确实现 driver.Valuer 和 sql.Scanner 接口，实现与 GORM 兼容的枚举持久化。
本文详解 go 枚举类型（`int` 底层）无法被 `database/sql` 驱动识别的根本原因，并通过将底层类型改为 `int64`、正确实现 `driver.valuer` 和 `sql.scanner` 接口，实现与 gorm 兼容的枚举持久化。
在 Go 中使用 GORM 操作数据库时，若自定义枚举类型（如 type PlatformType int）直接参与 SQL 写入，常会遇到如下 panic：
panic: sql: converting Exec argument #1's type: non-Value type int returned from Value
该错误并非 GORM 特有，而是源于 Go 标准库 database/sql 对 driver.Value 的严格类型约束：只有 int64、float64、string 和 bool 四种底层类型被官方认可为合法的 driver.Value 返回值（见 database/sql 文档）。当你定义 type PlatformType int 并在 Value() 方法中返回 int(u)，尽管 int 在运行时可能与 int64 等价（如在 64 位系统上），但 Go 的类型系统仍将其视为独立类型——int ≠ int64，因此 database/sql 拒绝接受，触发 panic。
✅ 正确解法是：统一使用 int64 作为枚举底层类型，并确保 Value() 返回 int64，Scan() 接收 int64。以下是修复后的完整关键代码段：
// ✅ 正确：底层类型为 int64
type PlatformType int64
const (
PLATFORM_TYPE_NOT_A_VALUE PlatformType = iota
PLATFORM_TYPE_TYPE1
PLATFORM_TYPE_TYPE2
)
var platformTypeNames = [...]string{
"Not a type",
"Type1",
"Type2",
}
func (p PlatformType) String() string {
if p < 0 || int64(p) >= int64(len(platformTypeNames)) {
return "Unknown"
}
return platformTypeNames[p]
}
// ✅ 实现 sql.Scanner：从数据库读取时解析 int64
func (p *PlatformType) Scan(value interface{}) error {
if value == nil {
return nil // 处理 NULL 值
}
if v, ok := value.(int64); ok {
*p = PlatformType(v)
return nil
}
return fmt.Errorf("cannot scan %T into PlatformType", value)
}
// ✅ 实现 driver.Valuer：向数据库写入时返回 int64
func (p PlatformType) Value() (driver.Value, error) {
return int64(p), nil
}同时，请确保结构体字段可导出（已满足），且 GORM 标签明确指定列类型（如 gorm:"type:integer"），SQLite 将自动映射为 INTEGER。
⚠️ 重要注意事项：
- 不要使用 int、uint、int32 等非标准类型作为 Value() 返回值，即使它们在特定平台下能“偶然”工作，也违反 database/sql 规范，存在跨平台或驱动升级风险；
- Scan() 方法必须接收指针（*PlatformType），并处理 nil（对应 SQL NULL），否则读取空值时 panic；
- 若需支持字符串枚举（如存 "type1" 而非 1），应将底层类型改为 string，Value() 返回 string(p)，Scan() 接收 []byte 或 string；
- GORM v2（gorm.io/gorm）同样遵循此规则，无需额外适配。
通过以上改造，你的 Platform 实例即可被 store.db.Create() 安全持久化，且后续查询也能正确反序列化枚举值。这不仅是解决 panic 的技巧，更是 Go 数据库交互中类型安全实践的典型范例。
