本文深入解析 Go 语言中为何向 sql.DB.Exec 传入自定义枚举类型时必须使用指针（如 &s.Status），核心在于 driver.Valuer 接口的接收者类型决定了接口实现归属，值接收者与指针接收者在类型满足性上存在本质差异。
本文深入解析 go 语言中为何向 `sql.db.exec` 传入自定义枚举类型时必须使用指针（如 `&s.status`），核心在于 `driver.valuer` 接口的接收者类型决定了接口实现归属，值接收者与指针接收者在类型满足性上存在本质差异。
在 Go 的 database/sql 生态中，自定义类型要参与 SQL 参数绑定（如 Exec、Query），必须实现 driver.Valuer 接口以告知驱动如何将其序列化为数据库可接受的值。关键点在于：接口实现是否成立，取决于方法的接收者类型与实际传入值的类型是否严格匹配。
回顾你的原始实现：
func (s *StatusEnum) Value() (driver.Value, error) {
return []byte(*s), nil
}该方法使用 指针接收者（*StatusEnum）*，因此只有 `StatusEnum类型（即StatusEnum的指针）才实现了driver.Valuer接口；而StatusEnum` 类型本身（值类型）并未实现该接口**。当你调用：
db.Exec("UPDATE ... SET Status = ?", eqi.Status) // ❌ eqi.Status 是 StatusEnum 值database/sql 包内部会检查 eqi.Status 是否实现了 driver.Valuer。由于 StatusEnum 值类型不满足该接口，最终触发错误：
sql: converting Exec argument #0's type: unsupported type emailqueue.StatusEnum, a string
而使用 &eqi.Status 后，传入的是 *StatusEnum，它确实实现了 Value() 方法，因此能被正确识别并转换。
✅ 正确做法是统一采用值接收者实现 Valuer（更符合 Go 标准库惯例，也避免指针陷阱）：
func (s StatusEnum) Value() (driver.Value, error) {
return string(s), nil // 直接返回 string 更简洁，MySQL 驱动会自动处理 []byte 或 string
}同时，Scan 方法也建议改为值接收者（或保持指针接收者但确保一致性）：
func (s *StatusEnum) Scan(src interface{}) error {
if src == nil {
return errors.New("Status field cannot be NULL")
}
if bs, ok := src.([]byte); ok {
*s = StatusEnum(string(bs))
return nil
}
if str, ok := src.(string); ok {
*s = StatusEnum(str)
return nil
}
return fmt.Errorf("cannot scan %T into StatusEnum", src)
}? 为什么 sql.NullString 不需要取地址？
因为 sql.NullString 的 Value() 方法明确使用值接收者：func (ns NullString) Value() (driver.Value, error) { ... }所以 eqi.Body（类型为 sql.NullString）本身即可满足 driver.Valuer，无需 &eqi.Body。
? 总结与最佳实践：
- ✅ 自定义类型实现 driver.Valuer 时，优先使用值接收者（func (t T) Value()），语义清晰、调用安全、与标准库（如 sql.NullInt64、sql.NullString）保持一致；
- ⚠️ 若误用指针接收者（func (t *T) Value()），则必须传指针，否则编译期无错但运行时报 unsupported type；
- ? Scanner 实现通常需指针接收者（因需修改原值），但 Valuer 不涉及修改，值接收者更自然；
- ? 测试建议：对自定义类型显式断言接口实现，增强可维护性：
var _ driver.Valuer = StatusEnum("") // 编译期验证：StatusEnum 值是否实现 Valuer
遵循这一原则，你的 StatusEnum 将无缝融入 SQL 操作，既安全又符合 Go 的类型哲学。
