Golang MongoDB FindOne嵌套bson.M偶发失效，其他写法正常

核心差异在于BSON文档的有序性以及Go中不同BSON类型的序列化行为：

1. filter1偶发失效的原因 #

你使用的bson.M本质是Go的map[string]interface{}，而Go中map的键遍历顺序是随机且不固定的。当把这个嵌套的bson.M序列化为BSON查询文档时，first_name和last_name的顺序可能随机变化。

MongoDB中，使用{field: {subKey1: val1, subKey2: val2}}这种格式查询时，属于子文档完全相等匹配——它要求查询的BSON子文档和数据库中存储的子文档在键的顺序、键值对内容上完全一致。

而你的Name结构体序列化到MongoDB时，BSON键顺序是固定的（对应结构体字段定义顺序：first_name在前，last_name在后）。当filter1的嵌套bson.M序列化后键顺序和数据库中存储的顺序不一致时，MongoDB就会判定子文档不相等，导致查询失败。这就是为什么会有10%的概率匹配不到结果——完全取决于map序列化时的键顺序。

2. filter2始终有效的原因 #

bson.D是有序的BSON文档，它会严格按照你定义的键顺序（first_name在前，last_name在后）序列化。这个顺序和Name结构体序列化到MongoDB的顺序完全一致，所以每次查询时的子文档匹配都能成功。

3. filter3始终有效的原因 #

filter3使用了MongoDB的点符号语法，它不是匹配整个子文档，而是分别匹配子文档中的first_name和last_name字段。这种查询逻辑不关心子文档的键顺序，只要两个字段的数值都符合条件，就会匹配成功，因此不会出现偶发失效的问题。

总结 #

• 用嵌套bson.M做子文档完全匹配时，会因为Go map的无序性导致BSON键顺序随机，和存储的子文档顺序不一致时查询失败。
• bson.D保证了键顺序固定，匹配存储的子文档顺序，所以稳定有效。
• 点符号语法是分别匹配子字段，不依赖键顺序，同样稳定有效。

内容的提问来源于stack exchange，提问作者Tianjun Fu