mgo.v2 仍可稳定用于老旧 mongodb（≤3.6）的微服务，但必须规避连接复用、会话模式和 objectid 生成这三类典型陷阱，否则高并发下极易出现数据错乱或连接泄漏。
直接说结论：mgo.v2 仍可稳定用于老旧 MongoDB（≤3.6）的微服务，但必须规避连接复用、会话模式和 ObjectId 生成这三类典型陷阱，否则高并发下极易出现数据错乱或连接泄漏。
为什么 mgo.Dial() 不能在微服务里全局复用
mgo.Session 不是线程安全的，Dial() 返回的 session 一旦被多个 goroutine 并发调用 Copy() 或直接使用，就会触发内部状态竞争。微服务天然多协程，若把 session 当单例全局变量用，轻则查询返回空结果，重则 panic: runtime error: invalid memory address。
- 每次业务逻辑开始前，必须调用
session.Copy()获取新会话，用完立刻Close() - 不要试图用 sync.Pool 缓存 session —— mgo 的 session 内部含未导出字段，Pool 释放后可能残留未关闭的 socket
- 连接字符串里显式加
?connect=direct，避免 replica set 自动发现带来的额外握手开销（老旧 MongoDB 常关副本集）
mgo.SetMode() 在微服务中该选 Monotonic 还是 Strong
老旧 MongoDB 微服务多数读多写少，且不依赖强一致性事务，Monotonic 是更稳妥的选择；Strong 模式虽保证读写都落在主节点，但会显著增加连接池压力，尤其当主节点短暂不可用时，整个服务可能卡死在等待主节点响应上。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
session.SetMode(mgo.Monotonic, true)允许读操作路由到从节点（若存在），写操作强制主节点，平衡延迟与可用性 - 若业务明确要求“写后立即可读”，才考虑
Strong，但需搭配session.Refresh()主动刷新连接，否则可能读到旧主节点缓存 - 绝对不要用
Eventual模式——它允许读从任意节点（包括延迟极大的从库），在微服务链路中极易导致下游服务拿到过期状态
插入文档时 _id 必须手动生成，别等 MongoDB 回填
微服务间常需用 _id 做跨服务关联或幂等控制，若依赖 MongoDB 自动生成，就不得不在 Insert() 后再查一次——这不仅多一次网络往返，还可能因时序问题查不到刚插入的文档（尤其在 Monotonic 模式下读到了从节点）。
- 插入前务必调用
bson.NewObjectId()，赋值给结构体的_id字段 - 结构体定义中，
_id字段类型必须为bson.ObjectId，且 tag 标记为bson:"_id"，否则 mgo 无法序列化 - 避免用
string类型存 ObjectId——虽然能插入，但后续用bson.ObjectIdHex()查询时会因类型不匹配失败
查询动态结构文档时，别硬套 struct，优先用 map[string]interface{}
老旧系统常有字段名不固定、嵌套层级混乱的集合（比如日志、用户行为快照），强行定义 struct 不仅维护成本高，还容易因字段缺失 panic。
- 用
map[string]interface{}接收查询结果，比bson.M更灵活（后者是 alias，但语义不够直白） - 访问嵌套字段时，逐层断言类型，例如
if meta, ok := doc["metadata"].(map[string]interface{}); ok { ... } - 若需部分字段校验，可配合
gjson或mapstructure解析，但注意mapstructure对interface{}的深层嵌套支持有限，老旧环境建议手动断言
真正麻烦的不是语法细节，而是 mgo 把连接生命周期和会话状态耦合得太紧——一个 Copy() 出错，整个 session 可能进入半关闭状态，而错误日志只报 read tcp: use of closed network connection，得靠抓包才能定位。微服务里，宁可多写几行 Copy()/Close()，也别省那点对象分配开销。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
