Go连接MongoDB问题根源在于context控制、类型误用和驱动行为误解：需用context.WithTimeout替代Background，FindOne()查无结果返回nil但err为nil，必须用primitive.M而非map[string]interface{}，结构体须加bson tag，InsertMany()不自动填充_id。
Go 连接 MongoDB 卡住、查不到数据、插入后拿不到 _id——这些问题基本都出在 context 控制、类型误用和驱动行为误解上，不是数据库没起来，也不是代码写错了语法，而是没按 mongo-go-driver 的契约来。
mongo.Connect() 为什么卡住或超时？
根本不是网络问题，而是你传了 context.Background()。驱动默认不设连接超时，它会一直等 DNS 解析、TCP 握手、TLS 协商完成，操作系统级超时才触发（通常 2–3 分钟）。
- 必须用
context.WithTimeout(context.Background(), 10*time.Second)，超时后err是context.DeadlineExceeded，不是connection refused -
connectTimeoutMS参数只影响初始握手阶段，不能替代 context 超时，两者要一起用 - 连接字符串格式必须严格：
mongodb://localhost:27017或 Atlas SRV 地址，漏@、多空格、大小写错误都会让解析失败 - 连接成功不等于可用，务必紧接着调
client.Ping(ctx, nil)验证连通性
FindOne() 返回 nil 却不报错？
这是驱动的明确设计：查无结果 ≠ 出错。FindOne() 找不到文档时返回 nil *mongo.SingleResult，但 err 仍是 nil。直接判 result == nil 就 panic，是常见崩点。
- 正确流程分两步：先检查
err != nil（真出错），再调result.Err()看是否等于mongo.ErrNoDocuments -
result.Decode(&v)前必须确保result != nil且result.Err() == nil，否则 runtime panic - 别用
if result == nil { /* 当作失败 */ }，这会把“查不到”当成“连不上”处理
primitive.M 和 map[string]interface{} 能混用吗？
不能。虽然 primitive.M 是 map[string]interface{} 的类型别名，但驱动内部做了字段顺序保留、nil 值特殊编码、time.Time 自动转 BSON Date 等处理。混用会导致字段丢失、时间变零值、二进制字段消失。
立即学习“go语言免费学习笔记（深入）”；
- 所有 filter、update、insert 一律用
primitive.M{"name": "alice", "created_at": time.Now()} - 结构体字段必须加
bson:"name"tag，否则驱动按 Go 字段名（首字母大写）映射，BSON 里找不到对应 key -
time.Time字段保持原类型，别转成string或int64，否则不会序列化为 BSON Date
InsertMany() 为啥插完拿不到每条记录的 _id？
因为 InsertMany() 不会反向填充你传入切片中每个结构体的 _id 字段——它只返回新生成的 _id 列表，你需要自己关联回原始数据。
- 如果结构体里没定义
ID primitive.ObjectID `bson:"_id,omitempty"`字段，插入后你根本不知道哪个_id对应哪条记录 - 安全做法：插入前手动赋值
doc.ID = primitive.NewObjectID()，再传给InsertMany() - 注意
InsertMany()默认是 ordered 模式，1000 条中某条失败会回滚全部；如需部分成功，得显式用options.InsertMany().SetOrdered(false)
最常被忽略的是：驱动不自动补 _id、不帮你做类型转换、也不封装“查无结果”的语义。它只忠实执行 BSON 协议，所有控制权都在你手上——context、primitive.M、bson tag、result.Err()，少一个环节就容易掉坑里。
