Golang从MongoDB拉取异构数据的高效实现方案咨询

优化方案可按你的业务场景选择，效率从高到低排序如下： #

1. 优先在查询阶段做投影裁剪，减少无效数据传输

不管你用什么方式解码，首先要在MongoDB查询的投影配置里明确指定要返回的field3子字段，不要拉取整个field3对象。
比如你需要返回field3下的score1、score2字段，投影参数就写：

projection := bson.M{
    "field1": 1,
    "field2": 1,
    "field3.score1": 1,
    "field3.score2": 1,
}

服务端会直接过滤掉不需要的字段，网络传输量和后续解码的内存开销都会大幅降低，是收益最高的优化点。

2. 若field3的子字段是固定枚举值，用结构体替代map

如果field3下的key是可枚举的（比如最多十几到几十个固定的可选key），直接把所有可能的子字段定义为结构体成员，用omitempty标记避免空值占用空间：

type MongoScore struct {
    Field1  string   `bson:"field1" json:"field1"`
    Field2  float64  `bson:"field2" json:"field2"`
    Score1  *float64 `bson:"field3.score1,omitempty" json:"score1,omitempty"`
    Score2  *float64 `bson:"field3.score2,omitempty" json:"score2,omitempty"`
    // 其他可能的field3子字段按以上格式补充
}

这种方案完全规避了map的哈希计算、序列化/反序列化开销，字段访问是直接的结构体内存寻址，性能比用map高2~3倍，是解码层效率最高的实现。

3. 若field3的子字段完全动态，按需延迟解码

如果field3的key是动态不确定的，必须用map存储的话，可以用bson.Raw先存储field3的原始二进制数据，仅当业务需要访问field3内容时再做解码：

type MongoScore struct {
    Field1 string   `bson:"field1" json:"field1"`
    Field2 float64  `bson:"field2" json:"field2"`
    Field3 bson.Raw `bson:"field3"`
}

// 需要访问field3子字段时再解码
func (m *MongoScore) GetField3Keys() (map[string]float64, error) {
    var res map[string]float64
    if err := m.Field3.Unmarshal(&res); err != nil {
        return nil, err
    }
    return res, nil
}

适合大部分查询不需要用到field3内容的场景，能节省大量无用的解码CPU开销。

额外注意：你现在写的结构体字段都是小写开头，属于Go的私有字段，BSON解码器无法赋值，需要把字段改成大写开头，并且补充bson标签，仅加json标签对MongoDB解码是无效的。

内容的提问来源于stack exchange，提问作者z.a.