必须用pgx/v5替代已归档的lib/pq；导入_ "github.com/jackc/pgx/v5/database/sql"，连接串含sslmode=disable（开发）或require（生产），初始化后立即db.Ping()验证。
直接用 database/sql + pgx 驱动最稳，别一上来就套 GORM。Fiber 本身不绑定任何数据库方案，它只管 HTTP 层；真正连 PostgreSQL 的是驱动和连接池配置，错一点就 panic 或连不上。
为什么不用 lib/pq 而选 pgx
lib/pq 已归档，不再维护；pgx 是当前事实标准，兼容 database/sql 接口，同时支持原生协议（类型映射准、JSONB 可直扫、批量插入快）。漏装驱动或导入方式不对，sql.Open("postgres", ...) 会直接报 driver: unknown driver "postgres"。
- 必须执行：
go get github.com/jackc/pgx/v5（v5 是当前主流） - 必须导入驱动：
import _ "github.com/jackc/pgx/v5/database/sql"（注意下划线） - 连接字符串要用 URL 格式：
postgres://user:pass@localhost:5432/dbname?sslmode=disable，本地开发不加sslmode=disable就默认走 SSL，99% 连不上 -
pgx的database/sql适配层不支持流式查询、自定义类型注册等高级功能，真要用得切回原生pgx.Conn
连接池初始化和 Ping 不是可选项
sql.DB 是连接池，不是单次连接。它必须在程序启动时初始化、全局复用，不能在 handler 里反复 Open 和 Close——那等于每请求建一次 TCP 连接，压测一下就崩。
- 调用
db.Ping()才真正发起连接验证，sql.Open()只是构造结构体，不发包 - 务必设置连接池参数：
db.SetMaxOpenConns(20)、db.SetMaxIdleConns(10)、db.SetConnMaxLifetime(60 * time.Second)，否则默认不限制，高并发下连接耗尽 - 记得
defer db.Close()，但要在app.Listen()之后、程序退出前执行，别放错位置
Scan 字段顺序错位就会 panic
Go 没有运行时字段名绑定，rows.Scan(&a, &b, &c) 完全依赖 SQL SELECT 子句的字段顺序和变量声明顺序严格一致。PostgreSQL 里用函数、别名、NULL 值一掺和，裸 Scan 极易出错。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 永远优先封装成 struct，手动按 SELECT 顺序映射，别依赖反射自动绑定
- 时间字段必须用
*time.Time（防 NULL），数值字段用sql.NullInt64等，否则 NULL 导致 panic -
jsonb字段不能扫进*string，会报cannot scan into *string from jsonb，改用json.RawMessage或实现Scanner接口 - 动态 SQL 或视图查询前，先调
rows.Columns()检查列名和数量，别硬写固定变量数
GORM 在 Fiber 里不是银弹
如果真要用 GORM，注意它只是抽象层，底层仍需驱动：PostgreSQL 必须装 gorm.io/driver/postgres，光装 gorm.io/gorm 会 panic unsupported driver: postgres。而且 GORM 默认不设连接池上限，不显式配置 SetMaxOpenConns，上线后容易被并发打穿。
- 别用老版
github.com/jinzhu/gorm（已弃用） - GORM 的自动迁移、钩子、预加载虽方便，但掩盖了 SQL 执行细节，慢查询难定位
- 事务管理更易出错：
tx.Commit()忘写、defer tx.Rollback()放错作用域，连接就卡死在事务中 - 简单 CRUD 场景，原生
database/sql+pgx更轻、更快、问题更透明
最常被忽略的一点：连接字符串里的 sslmode 不是“可选配置”，而是连接成败开关。本地开发不写 sslmode=disable，或者生产环境没配好证书却写了 sslmode=require，都会静默失败——日志里只显示 context deadline exceeded，根本看不出是 SSL 卡住的。
