本文详解 mgo 中 collection.Find(nil).All() 查询无报错却无法看到结果的典型问题，指出日志误打 err 变量导致数据“消失”的根本原因，并提供安全调试方法与最佳实践。
本文详解 mgo 中 `collection.find(nil).all()` 查询无报错却无法看到结果的典型问题，指出日志误打 `err` 变量导致数据“消失”的根本原因，并提供安全调试方法与最佳实践。
在使用 mgo（Go 语言经典 MongoDB 驱动）进行全量查询时，开发者常遇到一种“看似成功、实则无声”的情况：collection.Find(nil).All(&users) 返回 err == nil，但 fmt.Println("Results >> ", err) 却只输出 <nil></nil>，让人误以为查询失败或数据为空。实际上，问题不在于查询逻辑，而在于日志打印对象错误——你打印的是 err，而非真正承载结果的 users 变量。
✅ 正确写法：打印结果变量，而非错误变量
var users []User
err := collection.Find(nil).All(&users)
if err != nil {
log.Fatal("Mongo collection find fail: ", err)
}
fmt.Println("Results >> ", users) // ← 关键修正：此处应为 users，不是 err若 users 仍为空切片（[]），说明数据库中确实无匹配文档，或结构体字段标签配置有误。
? 调试建议：先用 []interface{} 绕过结构体映射问题
当不确定文档结构是否与 User 完全匹配（如字段名大小写、嵌套字段、额外字段等），可先用泛型方式验证数据存在性与原始格式：
var raw []interface{}
err := collection.Find(nil).All(&raw)
if err != nil {
log.Fatal("Mongo collection find fail: ", err)
}
fmt.Printf("Raw results (%d docs): %+v\n", len(raw), raw)此方式跳过 BSON → Go struct 的字段映射过程，直接暴露原始文档内容，便于快速确认：
- 数据库是否真有数据；
- 文档字段命名（如
emailvsEmail）是否与 struct tagbson:"email"一致； - 是否存在类型不匹配（如
_id是ObjectId，但User中未定义对应字段）。
⚠️ 注意事项与最佳实践
-
务必检查
bsontag：MongoDB 字段默认小写，User结构体中若定义为Email stringbson:"Email"，将无法匹配"email": "a@b.com"；应统一为小写：Email stringjson:"email" bson:"email"。 -
Find(nil)等价于{}：表示空查询条件，即查找全部文档；确保集合名（"users"）和数据库名（"my_db"）拼写准确，且 Docker 中 MongoDB 服务已就绪、网络可达。 -
资源释放：
mgo.Session非线程安全，每次操作后建议调用session.Close()（或使用session.Copy()+defer s.Close()模式）。 -
替代方案提醒：
mgo已停止维护，生产环境推荐迁移到官方驱动mongo-go-driver，其 API 更现代、上下文支持更完善。
通过修正日志输出目标、辅以泛型调试、严格校验结构体标签，即可快速定位并解决 Find(nil).All() “静默失败”问题。
