GORM 本身不自动支持 PostgreSQL 的 POINT、JSONB、ARRAY、RANGE 等原生类型，必须通过显式实现 Valuer/Scanner 接口或引入 gorm.io/datatypes 包才能安全读写；否则会报 Scan 错误。
直接说结论：GORM 本身不自动支持 PostgreSQL 的 POINT、JSONB、ARRAY、RANGE 等原生类型，必须通过显式实现接口或引入专用包才能安全读写——否则会报 sql: Scan error on column index X: unsupported Scan, storing driver.Value type string into type *main.Point 这类错误。
用 gorm.io/datatypes 支持 JSONB、Array、Range
这是最省心的方案，官方维护，适配 GORM v2 + PostgreSQL。它把常见高级类型封装成 Go 结构体，并内置 Valuer 和 Scanner 实现。
-
datatypes.JSONB：接收map[string]interface{}或struct{}，存为 PostgreSQL 的JSONB类型（推荐，支持索引和查询） -
datatypes.Array[string]：对应TEXT[]、INT[]等，注意泛型参数必须是数据库支持的数组元素类型 -
datatypes.Int4Range、datatypes.NumRange：用于int4range、numrange，字段定义时需显式指定 PostgreSQL 类型：gorm:"type:int4range" - 不支持
POINT或GEOMETRY——这些得自己实现接口，datatypes包没覆盖
手动实现 Valuer/Scanner 处理 POINT 类型
PostgreSQL 的 POINT 是文本格式 (x,y)，不能直接用 string 或 []byte 接收，否则扫描时会 panic。必须让 Go 结构体满足两个接口：
-
driver.Valuer：控制写入时如何转成数据库能认的值（返回string，不是[]byte，避免被误判为 binary） -
sql.Scanner：控制从database/sql返回的[]byte或string中解析出坐标 - 注意括号和逗号之间**不能有空格**，否则 PostgreSQL 解析失败；
X、Y用strconv.AppendFloat拼接，比fmt.Sprintf更高效且可控精度 - 示例结构体：
type Point struct { X, Y float64 } func (p Point) Value() (driver.Value, error) { out := []byte{'('} out = strconv.AppendFloat(out, p.X, 'f', -1, 64) out = append(out, ',') out = strconv.AppendFloat(out, p.Y, 'f', -1, 64) out = append(out, ')') return string(out), nil } func (p *Point) Scan(src interface{}) error { s, ok := src.(string) if !ok { bs, ok := src.([]byte) if !ok { return fmt.Errorf("cannot scan %T into Point", src) } s = string(bs) } if len(s) < 2 || s[0] != '(' || s[len(s)-1] != ')' { return fmt.Errorf("invalid point format: %s", s) } coords := strings.Split(strings.Trim(s, "()"), ",") if len(coords) != 2 { return fmt.Errorf("point must have exactly two coordinates, got %d", len(coords)) } x, err := strconv.ParseFloat(strings.TrimSpace(coords[0]), 64) if err != nil { return err } y, err := strconv.ParseFloat(strings.TrimSpace(coords[1]), 64) if err != nil { return err } p.X, p.Y = x, y return nil }
JSONB 字段映射：string / []byte / struct 三选一
选哪种取决于使用场景，没有绝对优劣，但错配会导致反序列化失败或字段为空：
- 用
string：最通用，不管数据库里存的是对象还是数组都可读出，后续再按需json.Unmarshal；适合 schema 不固定或需要做字符串级处理（如正则提取） - 用
[]byte：性能略好（避免一次内存拷贝），但必须确保后续调用json.Unmarshal时传的是string(b)或直接用b；若误当string打印会显示乱码 - 用具体
struct：类型最安全，GORM 自动完成反序列化；但一旦数据库存了不兼容结构（比如多了一个字段、类型错位），整个 Scan 就会失败并静默丢弃该行 - 别用
interface{}：GORM 无法自动推导其底层类型，会存成null或报错
字段类型声明必须显式匹配 PostgreSQL
GORM 默认映射可能不符合预期，尤其对高级类型——例如不加 type: 标签，datatypes.JSONB 可能被建为 text 而非 jsonb，导致无法使用 @>、#> 等操作符。
- 强制指定列类型：
gorm:"type:jsonb"、gorm:"type:point"、gorm:"type:text[]" - 数组类型要带维度声明，
text[]和text[][]是不同类型，不能混用 - 迁移时加
db.Migrator().AutoMigrate(&Model{})后，务必用\d table_name在 psql 里确认实际列类型是否正确，别只信 GORM 日志 - 软删除字段若用
gorm.DeletedAt，它默认是timestamp with time zone，但 PostgreSQL 里建议显式写成gorm:"type:timestamptz"，避免时区隐式转换问题
最容易被忽略的一点：所有自定义类型（包括 Point、datatypes.JSONB）在用 db.Create() 插入前，必须确保其 Value() 方法不 panic；而 Scan() 方法要能容忍空值、NULL、空字符串等边界输入——生产环境数据库字段为空太常见，别让一个 nil 把整批查询拖垮。
