默认连接池不适用于日志写入，因其面向通用业务读写，而日志需高频、低延迟、可丢弃，共用池会导致业务连接被挤占；必须隔离配置（MaxPoolSize=5–10）、禁用WriteConcern（w:0）、关闭RetryWrites，并采用异步队列+批量写入+结构化文档设计。
为什么不用 mongo-go-driver 的默认连接池直接写日志
默认连接池设计面向业务读写，日志写入高频、低延迟要求高，但 mongo-go-driver 的 InsertOne 或 InsertMany 会触发完整 BSON 序列化 + 网络往返 + 确认机制，压测时容易拖慢主服务。真实场景中，你看到的 context deadline exceeded 或 connection refused 错误，往往不是 MongoDB 挂了，而是日志协程把连接池占满，挤占了业务查询。
- 必须单独配置日志专用客户端，用独立
ClientOptions设置MaxPoolSize（建议 5–10），避免和业务共用连接池 - 禁用
WriteConcern：日志可丢，设为w:0，跳过多数节点确认 - 关闭
RetryWrites：日志不重试，失败就丢，否则重试逻辑会卡住 goroutine
如何让日志结构适配 MongoDB 的嵌套查询需求
纯字符串日志没法按 service_name、level、trace_id 过滤。必须在写入前做结构化解析，但又不能依赖固定 schema —— 微服务字段常变。正确做法是用 map[string]interface{} 构建文档，把原始日志文本塞进 message 字段，其他元数据平铺为同级 key。
示例结构：
{
"timestamp": {"$date": "2024-06-12T08:34:22.123Z"},
"level": "error",
"service_name": "auth-service",
"trace_id": "abc123",
"span_id": "def456",
"message": "failed to verify token: invalid signature",
"error": {
"code": "TOKEN_INVALID",
"stack": "github.com/xxx/auth.VerifyToken\n\t..."
}
}-
error字段只在有错误时存在，MongoDB 支持稀疏索引，不影响查询性能 - 时间必须用
time.Time类型传入，驱动会自动转成$date；别传字符串，否则无法用$gt做时间范围查询 - 避免嵌套过深：MongoDB 单文档上限 16MB，但实际建议控制在 1MB 内，防止批量写入失败
怎么避免日志写入阻塞主流程
同步写 MongoDB 必然拖慢 HTTP handler。必须异步，但简单起个 goroutine 有内存泄漏风险 —— 日志量突增时 goroutine 积压，OOM。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 用带缓冲的 channel 做日志队列，容量设为 1000–5000（根据 QPS 估算），超限则丢弃（日志可丢）
- 后台 worker 固定 1–3 个 goroutine 消费 channel，每次
InsertMany批量写（建议每批 100 条），减少网络开销 - worker 要监听
ctx.Done()，服务退出时清空 channel 并 flush 剩余日志，否则最后几秒日志丢失
关键代码片段：
logCh := make(chan map[string]interface{}, 2000)
go func() {
ticker := time.NewTicker(1 * time.Second)
defer ticker.Stop()
var batch []interface{}
for {
select {
case log := <-logCh:
batch = append(batch, log)
if len(batch) >= 100 {
_ = collection.InsertMany(ctx, batch)
batch = batch[:0]
}
case <-ticker.C:
if len(batch) > 0 {
_ = collection.InsertMany(ctx, batch)
batch = batch[:0]
}
}
}
}()聚合查询时为什么 $lookup 会超时
日志库常要关联 trace 表查上下文，但 $lookup 在海量日志集合上执行极慢。根本原因是 MongoDB 默认不为 trace_id 字段建索引，且 $lookup 会全表扫描被关联集合。
- 必须对所有用于查询的字段建索引：
db.logs.createIndex({"trace_id": 1, "timestamp": -1}) - 避免跨集合
$lookup：把 trace 关键字段（如service_name、status）冗余到日志文档里，用单集合查询替代 join - 时间范围查询务必用
timestamp索引，别用$expr或正则匹配message字段，那会扫全表
真正难的不是连上 MongoDB，而是让日志写得快、查得准、扩得稳 —— 连接池隔离、结构设计、异步队列、索引策略，四者缺一不可。
