.NET 6中获取JsonElement值底层类型的惯用方法是什么

逐一调用TryGetInt32()、TryGetInt64()、TryGetDouble()等方法逐一尝试匹配的做法不属于最佳实践，这种写法存在两个明显缺陷：

• 匹配顺序错误时会出现严重的类型误判：比如如果优先调用TryGetDouble()，所有整数值都能成功转换为double，后续的整数类型判断逻辑永远不会触发
• 手写的尝试逻辑容易出现精度丢失问题，且和System.Text.Json内置的转换规则可能存在行为差异，维护成本高

首先需要明确一个基础认知：JSON标准本身没有对Number类型做整数、浮点数、高精度小数的类型区分，Number节点本质是一段符合数值语法的文本标记，不存在CLR层面的"原生底层类型"，我们判断适配类型的核心目标是找精度损失最小、最符合常规编码预期的托管类型。

根据不同场景选择对应方案即可：

场景1：已知目标字段的明确类型 #

这是绝大多数业务开发的场景，完全不需要手动做类型判断，直接调用内置反序列化方法即可：

// 直接反序列化为目标强类型，内置转换器自动处理类型兼容和精度问题
int targetValue = jsonElement.GetInt32();
// 或者直接反序列化整个DTO
var dto = JsonSerializer.Deserialize<MyDto>(jsonElement);

这种方式和System.Text.Json的官方行为完全一致，是最推荐的做法，没有多余的自定义判断逻辑，也不会出现行为偏差。

场景2：Schema不固定，需要动态解析数值的适配类型 #

这种场景不要手写无序的TryGet调用，可以直接复用Utf8JsonReader的内置判断逻辑，按照「窄类型优先、精度损失最小优先」的顺序做匹配，和官方反序列化的判断逻辑保持一致：

public static Type GetBestMatchNumberType(this JsonElement element)
{
    if (element.ValueKind != JsonValueKind.Number)
    {
        throw new ArgumentException("传入的JsonElement不是Number类型节点", nameof(element));
    }

    // 基于原始JSON数值文本判断，避免中间转换带来的精度损失
    ReadOnlySpan<byte> rawUtf8 = Encoding.UTF8.GetBytes(element.GetRawText());
    Utf8JsonReader reader = new Utf8JsonReader(rawUtf8);
    reader.Read();

    // 判断顺序从精度损失最小的窄类型，依次向宽类型递进
    if (reader.TryGetInt32(out _)) return typeof(int);
    if (reader.TryGetInt64(out _)) return typeof(long);
    if (reader.TryGetUInt64(out _)) return typeof(ulong);
    if (reader.TryGetDecimal(out _)) return typeof(decimal);
    return typeof(double);
}

这个实现的优势：

• 所有判断逻辑复用System.Text.Json内置的Utf8JsonReader能力，和官方反序列化的类型匹配逻辑完全一致，不会出现自定义逻辑的行为偏差
• 判断顺序遵循类型宽度优先原则，不会出现整数被误判为浮点数的问题
• 直接基于原始文本解析，不存在中间转换的精度损失

• 涉及金融、计量等高精度要求的数值场景，可以调整判断顺序把TryGetDecimal的优先级提前，避免double的浮点精度误差
• 不要把TryGetDouble、TryGetSingle这类浮点类型判断放在整数判断之前，否则会导致所有整数都被匹配为浮点类型
• 非必要不要做动态类型判断，强类型反序列化始终是稳定性最高、最符合.NET编码惯例的方案

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