ASP.NET MongoDB API使用BsonExtraElements标签时无报错冻结问题

请求挂死是序列化层递归死循环导致的：你用BsonDocument作为[BsonExtraElements]的承载类型时，ASP.NET Core默认使用的System.Text.Json序列化器无法识别BsonDocument的特殊结构，会遍历其内部包含的自引用元数据、父子节点关联属性，陷入无限递归逻辑，直接占满请求处理线程，既不会抛出明确异常，也不会返回响应，最终表现为Swagger一直加载、应用无响应，只能重启恢复。纯静态字段不存在这个复杂类型的序列化冲突，所以可以正常运行。

最简便的修复方式是更换额外字段的承载类型，MongoDB C#驱动原生支持Dictionary<string, object>作为[BsonExtraElements]的存储类型，同时该类型可以被System.Text.Json正常序列化，不会触发递归死循环，修改后的实体代码如下：

public class Incident
{
    [BsonId]
    [BsonRepresentation(BsonType.ObjectId)]
    public string? Id { get; set; }

    [BsonElement("Name")] 
    public string? Name { get; set; }

    [BsonExtraElements]
    public Dictionary<string, object>? Additional { get; set; }
}

大部分场景下不需要额外配置序列化规则，只有当额外字段包含多层嵌套对象、特殊时间/高精度数字格式时，才需要在Program.cs中补充如下序列化注册逻辑：

BsonSerializer.RegisterSerializer<Dictionary<string, object>>(
    new DictionaryInterfaceImplementerSerializer<Dictionary<string, object>, string, object>(
        BsonTypeMapperOptions.Defaults with { DuplicateNameHandling = DuplicateNameHandling.Throw }
    )
);

• 替换默认JSON序列化器为Newtonsoft.Json：Newtonsoft.Json对BsonDocument类型的兼容性更好，不会触发递归死循环，适合需要保留BsonDocument类型做原生Mongo查询操作的场景。配置方式如下，注意需要先安装对应版本的Microsoft.AspNetCore.Mvc.NewtonsoftJson NuGet包：

  builder.Services.AddControllers().AddNewtonsoftJson(opts =>
  {
      opts.SerializerSettings.ReferenceLoopHandling = ReferenceLoopHandling.Ignore;
  });
  

• 编写自定义JSON转换器：为Incident类单独实现JsonConverter，手动处理Additional字段（BsonDocument类型）和JSON结构的转换逻辑，完全绕开默认序列化器对BsonDocument内部结构的遍历，灵活性最高，但开发成本稍高。
• 继承DynamicObject实现动态模型：放弃使用[BsonExtraElements]特性，让Incident类继承DynamicObject，重写TryGetMember、TrySetMember方法动态读写额外字段，MongoDB C#驱动对DynamicObject类型的动态字段存储有原生支持，适合需要通过动态属性直接访问额外字段的场景。

注意：所有方案上线前必须做接口往返测试，确认额外字段入库时不会覆盖Id、Name等静态字段的映射，查询返回时额外字段不会带出_t、_v这类MongoDB序列化生成的冗余类型标记字段。

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