如何在MongoDB中原样存储POST传入的dynamic非结构化JSON对象

出现异常存储结果的核心原因是MongoDB .NET驱动的默认序列化逻辑触发了不必要的多态分支：当驱动识别到dynamic字段反序列化后为Newtonsoft.Json的JObject/JToken类型时，会自动启用多态序列化机制，在生成的文档中插入_t（存储类型全名称）、_v（承载实际值的容器）这类元数据，用于后续反序列化时还原对应类型；但JToken本身没有驱动可访问的公开构造函数，最终导致文档中实际值丢失、Compass无法查看内容、检索时抛出构造函数访问权限异常的问题。

方案1：注册专门的JToken系列序列化规则（对现有架构改动最小） #

无需修改现有接口的入参逻辑，直接在服务启动阶段的MongoDB初始化流程中，覆盖默认的JObject/JArray/JValue序列化行为，将这类对象直接映射为原生MongoDB文档结构，不插入冗余的类型元数据。

• 配置示例代码：

// 替换驱动默认的多态序列化逻辑
BsonSerializer.RegisterSerializer(typeof(JObject), new JObjectSerializer());
BsonSerializer.RegisterSerializer(typeof(JArray), new JArraySerializer());
BsonSerializer.RegisterSerializer(typeof(JValue), new JValueSerializer());

• 最终效果：存储的文档会完全匹配POST请求传入的原始JSON结构，无额外的_t、_v字段，MongoDB Compass可正常展开查看嵌套值，检索时也能正常还原JToken对象，不会抛出构造函数访问权限的异常。

方案2：通过BsonDocument中转（无额外依赖适配） #

如果不想引入额外的序列化适配代码，可以在接口接收到dynamic数据后，绕开JObject类型的直接传递，将原始请求的JSON内容直接转换为MongoDB原生的BsonDocument结构：

1. 接收POST请求时，保留接收到的原始JSON字符串，不对其做额外的强类型反序列化；
2. 调用BsonDocument.Parse(原始JSON字符串)将字符串直接解析为MongoDB可识别的原生文档对象；
3. 实体中承载非结构化数据的字段，类型定义为BsonDocument而非dynamic/JObject。

• 该方案完全跳过了JObject类型的序列化流程，从根源上避免了多态元数据插入的问题，存储结果与传入的JSON完全一致，也不会出现将内容存为普通字符串的问题。

• 直接将dynamic序列化为字符串存储：实体对应字段的类型为string时，MongoDB驱动会严格按照字段类型做存储，自然会把JSON字符串当成普通文本存储，不会自动解析为嵌套文档；
• 直接传入JObject存储：未覆盖默认的序列化规则时，驱动会自动走多态序列化分支，在文档中塞入类型元数据，破坏原始值结构。

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