PostgreSQL 的 ARRAY 类型必须用 gorm.io/datatypes 包显式支持，因 GORM 原生不识别该扩展类型；需使用 datatypes.Array[T] 并配合 gorm:"type:xxx[]" 标签，否则迁移失败或运行时 panic。
PostgreSQL 的 ARRAY 类型必须用 gorm.io/datatypes 包显式支持
原生 GORM 不识别 PostgreSQL 的 ARRAY 类型，直接用 []string 或 [][]int 会导致迁移失败或运行时 panic。根本原因是 GORM v2 默认只处理标准 SQL 类型（如 text、integer），而 PG 的数组是扩展类型，需通过专用封装。
必须引入 gorm.io/datatypes 并在结构体字段中使用其提供的类型：
-
datatypes.JSONB对应jsonb，不是数组 —— 别混淆 -
datatypes.Array[string]才对应TEXT[]；datatypes.Array[int64]对应BIGINT[] - 不能用
[]string直接 tag 成type:text[]—— GORM 会忽略该 type 声明，仍按普通字符串处理
datatypes.Array[T] 的声明方式和迁移注意事项
字段类型必须是泛型实例，且需配合 gorm:"type:xxx[]" 显式指定数据库列类型，否则 AutoMigrate 可能建错表（例如建为 text 而非 text[]）。
示例：
import "gorm.io/datatypes"
type Product struct {
ID uint `gorm:"primaryKey"`
Tags datatypes.Array[string] `gorm:"type:text[];not null"`
Scores datatypes.Array[float64] `gorm:"type:float8[]"`
}
关键点：
-
Tags字段在数据库中生成为tags TEXT[] NOT NULL，不是TEXT -
type:text[]中的[]不能省略，否则 PG 驱动无法识别为数组类型 - 若用
type:varchar(50)[]，需确保长度参数与 PG 兼容（varchar(n)支持数组，但char(n)不推荐） -
AutoMigrate对已存在表不修改列类型，改类型需手动ALTER TABLE ... TYPE
查询和写入 Array 字段的实际行为
写入时，Go 侧直接赋值切片即可；查询时，GORM 自动解包为 Go 切片。但要注意 PostgreSQL 数组的边界行为：
- 空切片
[]string{}写入后在 PG 中是{}（空数组），不是NULL - 想存
NULL，字段类型得是*datatypes.Array[string]，然后设为nil - 用
WHERE查询数组内容时，不能直接WHERE tags = ARRAY['a','b']—— GORM 不自动转义，需手写原生 SQL 或用Where("tags @> ?", datatypes.Array[string]{"a"})（@>是 PG 的包含操作符） - 更新单个元素不被支持：不能
db.Model(&p).Update("tags[0]", "new")，PG 不允许这种语法，必须全量更新整个数组
容易踩的坑：嵌套数组、NULL 和性能
PostgreSQL 支持多维数组（如 INTEGER[][]），但 datatypes.Array 仅支持一维。试图用 datatypes.Array[datatypes.Array[int]] 会编译失败或运行时报错。
其他高频问题：
- JSONB 字段误当 Array 用：有人把
[]map[string]interface{}存进JSONB，结果查出来是[]interface{}，类型丢失 —— 这不是 Array 映射问题，而是 JSON 解析问题 - 没加索引导致查询慢：
tags @> ARRAY['sale']在大数据量下必须配 GIN 索引，否则全表扫描 - 迁移时字段名含下划线或大写，别依赖默认蛇形转换 —— 显式写
gorm:"column:tag_list"更稳
最常被忽略的是：数组字段的零值语义和 NULL 语义完全不同，业务逻辑里混用会导致条件判断失效。写之前先确认你真需要数组，还是用关联表更清晰。
