DeleteOne 必须传非 nil filter，否则 panic；需校验 ID 并用 bson.M 构造；删除后必须检查 DeletedCount 是否为 1；应使用 context.WithTimeout 防卡死；批量删除优先用 DeleteMany。
Go 用 DeleteOne 删除单个文档，必须传 filter 且不能为 nil
传 nil 会 panic，错误信息是 panic: runtime error: invalid memory address or nil pointer dereference——因为底层驱动没做空检查，直接解引用了。实际开发中容易在条件未满足时（比如 ID 解析失败）误传 nil。
正确做法是始终构造一个非空 bson.M 或 bson.D：
- 按
_id删除：用bson.M{"_id": objectID}，注意先用primitive.ObjectIDFromHex校验并转换字符串 - 按业务字段删除（如
email）：确保字段有索引，否则可能全表扫描 - 永远别写
collection.DeleteOne(ctx, nil)，哪怕只是临时测试
判断是否真删掉了，得看 DeleteResult.DeletedCount，不是 err
DeleteOne 成功时返回 err == nil，但这只代表操作没崩溃，不等于删到了东西。MongoDB 对“没匹配到文档”的情况也返回成功 err == nil，只是 DeletedCount 为 0。
常见误判场景：
立即学习“go语言免费学习笔记（深入）”；
- 用户填错 ID，代码以为删除成功，其实什么都没动
- 软删除逻辑里漏查
DeletedCount，导致状态同步失败 - 测试用例只断言
err == nil，没覆盖空匹配路径
实操建议：删除后立刻检查 res.DeletedCount == 1，否则按“未找到”处理，比如返回 http.StatusNotFound。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
用 context.WithTimeout 包一层，避免 DeleteOne 卡死
MongoDB 驱动默认不设超时，网络抖动或副本集选举时，DeleteOne 可能卡住几秒甚至更久。Go HTTP handler 里不加 context 控制，会拖垮整个连接池。
正确姿势：
- 不要直接传
ctx，改用context.WithTimeout(ctx, 5*time.Second) - 超时后
err是context.DeadlineExceeded，可记录 warn 日志，不需 panic - 如果业务允许“尽力而为”，可忽略该 err；但金融类操作必须重试或回滚
批量删用 DeleteMany，别循环调 DeleteOne
想删多条？比如清除某用户所有日志。用循环 + DeleteOne 看似直观，但会发 N 次网络请求，延迟叠加、连接占用高，还可能被限流。
真正高效的做法：
- 用
DeleteMany配合一个 filter，一次发请求 - filter 写成
bson.M{"user_id": "xxx", "created_at": bson.M{"$lt": threshold}} - 注意
DeleteMany返回的是DeletedCount，不是布尔值，别拿它当 if 条件
唯一例外是需要逐条确认删除结果（比如带审计日志），但这种情况极少，优先走批量。
最常被忽略的点：filter 里的字段名大小写必须和 MongoDB 文档里完全一致，"UserId" 和 "userid" 是两个字段——驱动不会帮你做映射，也不会报错，只会默默不匹配。
