C# Newtonsoft.Json实战:JObject与JArray的5个高频使用场景(附代码)
如果你在.NET开发中处理过JSON数据,大概率已经和Newtonsoft.Json(现在也叫Json.NET)打过交道。这个库几乎是C#生态里处理JSON的“瑞士军刀”,而JObject和JArray则是其中最灵活、最趁手的两把“刀刃”。很多教程会告诉你它们是什么、怎么用,但真正到了项目里,面对千变万化的API响应、动态配置或者嵌套复杂的数据结构,你可能会困惑:到底什么时候该用它们?怎么用才能既高效又优雅,而不是写出一堆难以维护的“面条代码”?
这篇文章不会重复那些基础的Parse和ToString操作。我想和你聊聊的,是过去几年里,我在电商、物联网、企业应用集成等项目中,反复遇到的几个真实场景。在这些场景下,JObject和JArray的价值被发挥得淋漓尽致,它们能帮你解决那些用强类型模型处理起来很别扭,甚至很痛苦的问题。我们会从具体的痛点出发,看看如何用几行清晰的代码,把看似棘手的JSON难题轻松化解。
1. 动态构建与修改API请求参数
在对接第三方服务时,我们常常遇到一个尴尬的局面:对方API的请求体结构复杂多变,或者不同接口的字段差异很大。如果为每一个变体都定义一个C#类,代码会迅速膨胀,维护起来也头疼。这时候,JObject的动态构建能力就成了救星。
想象一下,你在开发一个电商订单推送系统,需要将订单数据发送给多个物流平台。每个平台要求的字段不尽相同:A平台需要recipient.phone,B平台却要求receiver.mobile;有的平台需要额外的扩展字段ext_info,而有的则完全不需要。用强类型对象序列化,你得准备多个DTO类,或者写一堆判空和条件赋值逻辑。
用JObject,你可以像搭积木一样,动态地组装出最终的JSON。
// 基础订单信息,这部分通常是固定的
JObject baseOrder = new JObject
{
["order_id"] = "ORD20231027001",
["total_amount"] = 299.99m,
["created_at"] = DateTime.UtcNow.ToString("yyyy-MM-ddTHH:mm:ssZ")
};
// 根据不同的物流平台,动态添加或修改字段
string logisticsProvider = GetConfiguredProvider(); // 假设从配置获取
if (logisticsProvider == "ProviderA")
{
baseOrder["recipient"] = new JObject
{
["name"] = "张三",
["phone"] = "13800138000",
["address"] = new JObject
{
["province"] = "广东",
["city"] = "深圳",
["detail"] = "南山区科技园"
}
};
// ProviderA要求一个额外的业务类型字段
baseOrder["biz_type"] = "standard";
}
else if (logisticsProvider == "ProviderB")
{
baseOrder["receiver"] = new JObject // 注意字段名不同
{
["full_name"] = "张三",
["mobile"] = "13800138000", // 字段名是mobile,不是phone
["shipping_address"] = "广东省深圳市南山区科技园"
};
// ProviderB需要物品的详细清单,以数组形式
baseOrder["items"] = new JArray
{
new JObject { ["sku"] = "ITEM001", ["qty"] = 1 },
new JObject { ["sku"] = "ITEM002", ["qty"] = 2 }
};
}
// 甚至可以基于运行时条件,动态删除某个字段
if (ShouldExcludeSensitiveData())
{
baseOrder.Remove("recipient"); // 或 baseOrder.Remove("receiver");
baseOrder["note"] = "收件人信息已脱敏";
}
// 最终,将动态构建的JObject转换为请求字符串
string requestBody = baseOrder.ToString(Formatting.None);
await httpClient.PostAsync(apiEndpoint, new StringContent(requestBody, Encoding.UTF8, "application/json"));
这种方式的优势在于灵活性。你无需在编译时确定所有字段,可以根据配置、用户输入或业务规则,在运行时自由地增、删、改属性。代码的意图非常清晰:就是按需构建一个JSON对象。
提示:虽然
JObject很灵活,但也不建议滥用。对于结构稳定、字段明确的内部接口,使用强类型模型(POCO)配合JsonConvert.SerializeObject仍然是首选,因为能享受编译时类型检查和IDE智能提示的好处。JObject更适合处理“未知”或“多变”的结构。

&spm=1001.2101.3001.5002&articleId=152582272&d=1&t=3&u=166a32bbb1df4ca8aa44dbd4c0608a06)
231

被折叠的 条评论
为什么被折叠?



