在mgo中，Clone()复用底层连接而Copy()新建连接；批量操作应优先复用单个克隆会话，避免为每条记录创建新连接，兼顾性能与资源开销。
在mgo中，`clone()`复用底层连接而`copy()`新建连接；批量操作应优先复用单个克隆会话，避免为每条记录创建新连接，兼顾性能与资源开销。
在使用 mgo（v2）操作 MongoDB 时，Session.Clone() 和 Session.Copy() 的语义差异至关重要，直接关系到应用的并发性能与系统资源消耗。
- session.Clone() 返回一个共享底层 TCP 连接的新 Session 实例，它不建立新 socket，仅复制会话状态（如读写关注、超时配置等）。多个 Clone() 出来的 Session 可安全并发使用，且因复用连接，显著减少三次握手、连接池争用和服务器端栈分配开销。
- session.Copy() 则会主动拨号新建一条独立 TCP 连接，带来明显的网络延迟（尤其在高频率小操作场景），并可能迅速耗尽客户端/服务端连接数限制（如 ulimit -n 或 MongoDB 的 maxIncomingConnections）。
回到你的两个方案：
✅ 推荐方案一（单次 Clone，循环复用） 是更优选择：
func (s *CvStoreServiceImpl) SetCvJobItemMeasureList(
accessToken *base_datatype.ServiceAccessToken,
versionPolicy string,
jobItemList []*cv_common_type.CvJobItemMeasure,
) error {
// 仅克隆一次，复用整个批处理生命周期
session := s.session.Clone()
defer session.Close() // 确保释放会话资源（归还至连接池）
for _, jobItem := range jobItemList {
objKey := &orm.ItemIdKey{
VersionName: versionPolicy,
ItemId: jobItem.ItemId,
}
obj := orm.ConvertToCvJobItemMeasureObj(versionPolicy, jobItem)
_, err := s.jobMeasureCollection.With(session).Upsert(objKey, obj)
if err != nil {
return &common_error.NamedError{err.Error()}
}
}
return nil
}
该方式在单次 HTTP 请求或事务性批量写入中高效稳定：既避免了高频建连开销，又不会因长连接阻塞影响其他 goroutine（mgo 内部已对 Clone() 后的 Session 做并发安全封装）。
❌ 方案二（每个 record 都 Clone() + Close()）存在明显隐患：
- 每次调用 SetCvJobItemMeasure 都触发 Clone() → Upsert() → Close()，虽未 Copy()，但频繁创建/销毁 Session 实例仍增加 GC 压力；
- 更严重的是，若 Close() 被意外遗漏或 panic 导致跳过，将造成连接泄漏；
- 若误用 Copy() 替代 Clone()，则每条记录都新建 socket，极易触发 connection refused 或 too many open files 错误。
? 关键注意事项：
- session.Clone() 是轻量、线程安全的操作，适合“一个请求 / 一个批量任务”粒度的会话隔离；
- session.Copy() 应仅用于需要强隔离性的场景（如跨 goroutine 长期持有、自定义 socket 层配置），日常 CRUD 不建议使用；
- 所有 Clone()/Copy() 得到的 Session 必须显式调用 Close()，否则连接无法归还至池中，最终导致连接池枯竭；
- 生产环境建议配合 session.SetSafe(&mgo.Safe{}) 或设置合适的 Timeout，防止慢查询长期占用会话。
✅ 总结：对 upsert 批量数据这类典型 OLTP 场景，统一 Clone() 一次、循环复用、最后 Close() 是兼顾性能、稳定性与可维护性的最佳实践。连接复用不是瓶颈，盲目新建才是。
