gin 和 mongodb 在 go 中能高效配合，但连接管理、错误处理、结构体 tag 映射三处最易出错：mongo.connect 必须用 context.withtimeout（如 10 秒），禁止 context.background()；连接成功后立即 defer client.disconnect(ctx) 并调用 client.ping(ctx, nil) 验证可用性；结构体字段须导出且 bson tag 严格匹配（如 id primitive.objectid bson:"_id,omitempty"）；find 返回游标需显式 cursor.next + decode + cursor.close，findone 查无结果返回 mongo.errnodocuments；db 实例应依赖注入而非全局变量，避免重连失效。
直接说结论：Gin 和 MongoDB 在 Go 里能高效配合，但连接管理、错误处理、结构体 tag 映射这三处最容易出错，不注意就会 panic 或查不到数据。
mongo.Connect 必须带 context.WithTimeout
生产环境里 mongo.Connect 不能用 context.Background() 或 context.TODO() —— 一旦 MongoDB 挂了或网络不通，程序会卡死在连接上，超时都等不到。
- 必须用
context.WithTimeout(ctx, 10*time.Second)控制最大等待时间 -
defer client.Disconnect(ctx)要在连接成功后立即 defer，否则 panic 时没机会释放资源 - 连接后务必调用
client.Ping(ctx, nil)验证连通性，光 connect 成功不代表 DB 可用
结构体字段必须导出 + bson tag 要严格匹配
Go 的反射机制要求 struct 字段首字母大写（导出），否则 mongo-go-driver 完全无法序列化/反序列化，查出来是空对象或字段全零值。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
ID primitive.ObjectID `bson:"_id,omitempty"`中_id是 MongoDB 实际字段名，大小写、下划线都不能错 -
omitempty只影响插入时跳过空值，不影响查询；更新时若字段为零值又没加$set，会把原值清空 - 时间字段推荐用
time.Time，MongoDB 自动存为ISODate，别手动转字符串
FindOne 和 Find 返回值解码方式不同
FindOne 直接返回单个文档，Find 返回游标（*mongo.Cursor），必须显式 cursor.Next(ctx) + cursor.Decode()，且最后要 cursor.Close(ctx)。
- 忘记
cursor.Close()会导致连接泄漏，MongoDB 连接数缓慢上涨 - 用
var result []Post接收Find结果时，得循环调用Decode，不能直接Decode(&result) -
FindOne查不到文档时返回mongo.ErrNoDocuments，不是nil错误，要单独判断
Gin handler 里传 db 实例不能用全局变量
很多人图省事把 *mongo.Database 声明成包级变量，看似方便，实则埋雷：并发请求共用同一实例没问题，但一旦连接断开或重连，全局变量不会自动更新，后续所有请求都会失败。
- 正确做法是通过 Gin 的
gin.Context或自定义 handler struct 持有*mongo.Database - 比如
h := handlers.NewHandler(db)，把 db 作为依赖注入到 handler 实例中 - 不要在 handler 函数里重复调用
client.Database("xxx").Collection("yyy")，开销小但易写错名称
最常被忽略的是 cursor.Close 和 context 超时 —— 它们不出错时不报警，但压测或高并发时立刻暴露连接耗尽或响应延迟问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
