pgx读JSONB需先Scan为[]byte或pgtype.JSONB再json.Unmarshal，写入须预序列化为[]byte/json.RawMessage，查询用->>走GIN索引，避免并发用map[interface{}]interface{}导致非法JSON。
pgx 怎么读取 JSONB 字段到 Go 结构体
直接用 Scan 把 JSONB 列扫进 map[string]interface{} 或 []byte 最常见，但容易忽略类型映射细节。pgx 默认把 JSONB 当作 []byte 返回，不是自动解析的 JSON 对象。
- 想转成结构体，得先扫成
[]byte，再用json.Unmarshal解析；别直接扫进map[string]interface{}——pgx 不支持这种隐式转换，会 panic - 如果字段可能为 NULL，必须用
pgtype.JSONB类型：它自带Valid字段，能安全区分 NULL 和空 JSON - 用
json.RawMessage是更轻量的选择，适合只转发、不立即解析的场景（比如 API 透传）
示例：
var data pgtype.JSONB
err := row.Scan(&data)
if err != nil {
return err
}
if !data.Valid {
// 是 NULL，不是 "{}"
return nil
}
var user User
return json.Unmarshal(data.Bytes, &user)
写入 JSONB 时为什么总是报 “cannot convert xxx to JSONB”
错误通常发生在用 Exec 或 QueryRow 传参时，把未序列化的 Go 值（比如 map[string]string）直接塞进 JSONB 参数位。pgx 不做运行时 JSON 序列化，它只认 []byte、string、json.RawMessage 或 pgtype.JSONB。
- 别传
map[string]interface{}直接进去——会触发类型不匹配错误 - 推荐统一用
json.Marshal转成[]byte再传；或者提前封装成json.RawMessage，避免重复序列化 - 如果值来自 HTTP 请求 body，直接复用
json.RawMessage字段可省一次 decode/encode
示例：
payload, _ := json.Marshal(map[string]string{"name": "alice", "role": "admin"})
_, err := conn.Exec(ctx, "INSERT INTO users (meta) VALUES ($1)", payload)
JSONB 查询条件怎么写才不丢索引
用 -> 或 ->> 做 WHERE 条件时，PostgreSQL 只有在表达式能命中 GIN 索引时才高效。直接写 meta->>'status' = 'active' 是可以走索引的，但加函数或类型转换就容易失效。
- 确保查询字段用了
jsonb_path_ops或jsonb_ops的 GIN 索引；建索引语句必须显式指定：CREATE INDEX idx_users_meta_status ON users USING GIN ((meta->>'status')) - 避免在列上套函数，比如
lower(meta->>'status')—— 这会让索引失效 - 用
@>（包含操作符）查对象存在性比->>更快，但语义不同：前者查子集，后者查字符串值
用 pgxpool 时 JSONB 字段并发更新出错怎么办
典型现象是部分请求返回 invalid input syntax for type json，尤其在高并发写入含嵌套结构的 JSONB 时。根本原因不是 pgx，而是 Go 的 json.Marshal 在并发下对某些 map 类型（如 map[interface{}]interface{}）行为未定义，可能产出非法 JSON。
立即学习“go语言免费学习笔记（深入）”；
- 永远别用
map[interface{}]interface{}构造 JSONB 数据；改用明确 key 类型的map[string]interface{}或结构体 - 如果数据来自外部（比如 HTTP body），优先用
json.RawMessage持有原始字节，直到真正需要解析时才调用Unmarshal - 注意
pgxpool的连接复用机制不会污染 JSONB 序列化，但 Go runtime 的并发 map 读写会——这是最常被忽略的根源
事情说清了就结束
