不能直接用一个collection存所有事件类型，因为字段结构差异大会导致索引效率低、聚合难写、反序列化易出错；应通过_type字符串标识类型，通用字段放顶层，特有字段收敛至payload子文档，并按访问模式建立复合索引和稀疏索引。
为什么不能直接用一个 collection 存所有事件类型
硬塞 user_login、payment_success、api_timeout 到同一个 collection，表面省事，实际埋雷：查询时得靠 type 字段过滤，但每个事件的字段结构差异大，导致索引效率低、聚合难写、应用层反序列化易出错。MongoDB 不是关系型数据库，没有外键和严格 schema 约束，但“无约束”不等于“无设计”。
用 _type 字段 + 嵌套子文档实现轻量多态
核心是让每条日志自带类型标识，并把特有字段收进语义明确的子文档里，避免 flat 结构无限膨胀。
-
_type必须是字符串常量（如"user_login"），不建议用数字或布尔值，方便索引和调试 - 通用字段（
timestamp、trace_id、service_name）放在顶层，便于统一查询和 TTL 索引 - 类型特有字段全部收敛到
payload子文档下，例如user_login的ip_address和user_agent都在payload里，不和payment_success的amount、currency混在一起 - 避免在
payload里再嵌套_type—— 类型已由顶层_type定义，重复冗余且易不一致
{ "_type": "user_login",
"timestamp": { "$date": "2024-06-15T08:22:10.123Z" },
"trace_id": "abc123",
"service_name": "auth-service",
"payload": {
"ip_address": "192.168.1.100",
"user_agent": "Mozilla/5.0..."
}
}
如何高效查询和索引多态日志
按类型查、按时间范围查、按 trace_id 查是最常见场景，索引策略必须匹配访问模式。
- 复合索引优先建
{"_type": 1, "timestamp": -1}，既支持按类型筛选，又支持按时间倒序取最新 N 条 - 高频查询字段（如
trace_id）单独建索引，不要指望复合索引能覆盖所有查询路径 - 避免对
payload内部字段建索引（如payload.ip_address），除非该字段确实高频用于等值查询；否则索引体积大、写入慢、命中率低 - 如果某类事件需按 payload 中某个字段范围查询（如
payment_success的amount），可建稀疏索引：{"_type": 1, "payload.amount": 1}，配合partialFilterExpression只索引该类型
应用层反序列化时怎么避免运行时 panic
MongoDB 驱动返回的是松散的 map[string]interface{} 或 BSON 文档，直接 cast 易崩溃。关键不是“怎么转”，而是“怎么安全地转”。
- 永远先检查
_type字段是否存在且为预期字符串，再决定走哪个解析分支 - 不要用全局 switch 处理所有
_type，而是按模块隔离：认证模块只处理user_login和user_logout，支付模块只认payment_*，降低耦合 - Go 里用
mapstructure.Decode时加WeaklyTypedInput: true，容忍 int/float 字段类型微小差异；Python 用pydantic.BaseModel.parse_obj()并捕获ValidationError - 日志写入前做一次 schema 校验（如用
ajv或jsonschema），比在读取端兜底更可靠
多态日志最难的不是存，是让不同团队写的 service 能一致地写、安全地读、不因字段名拼错或类型偏差就 silently 丢数据。真正的复杂点在于组织协同，而不是 MongoDB 语法本身。
