Json.Net判定属性是否应被反序列化的规则是什么？

这个问题其实涉及Json.NET反序列化时的核心逻辑——它如何选择初始化对象的方式，以及对私有setter属性的处理规则，咱们一步步拆解：

为什么原有私有setter属性能正常工作？ #

你之前的Name、TotalFrames等私有setter属性能成功反序列化，大概率是因为你的类定义了带参数的构造函数，且这些参数的名称和属性名（大小写不敏感）完全匹配。

Json.NET默认会优先尝试用构造函数注入来初始化对象：当JSON里的字段名和构造函数参数名对上时，它会通过反射调用这个构造函数，把JSON的值直接传给参数初始化属性——这个过程根本不需要调用属性的setter，哪怕setter是私有的也没关系。这就是你原有属性能正常反序列化的关键。

新增属性失败的根源 #

而你新增的ForceAttachedObjectToGround和测试属性，没有对应的构造函数参数，这时候Json.NET只能尝试通过属性的setter来赋值。但它的默认规则是：

• 只有带公共setter的属性，或者被[JsonProperty]特性显式标记的属性，才会被纳入反序列化范围；
• 私有setter的属性如果没加[JsonProperty]，Json.NET默认会直接忽略，不会通过反射去调用私有setter赋值。

这正好对应你测试的所有结果：

• 保留私有setter且不加特性：被忽略，无法反序列化；
• 移除内联初始化：不影响，问题根源不在初始化值；
• 把setter改成public：符合默认规则，正常反序列化；
• 添加[JsonProperty]：告诉Json.NET“这个属性必须处理”，不管setter访问级别，所以能正常工作。

Json.NET判断属性是否反序列化的核心规则 #

最后总结一下它的判断逻辑：

1. 优先看构造函数：如果类有构造函数（默认选参数最多的非默认构造函数，除非用[JsonConstructor]指定），且参数名和JSON字段匹配，就用构造函数注入初始化属性，不用依赖setter；
2. 再看属性本身：当构造函数没法覆盖属性时，检查setter：
   • 公共setter：默认参与反序列化；
   • 非公共setter：必须加[JsonProperty]才会被处理；
   • 只有getter的属性：默认不反序列化（除非构造函数能初始化）。

另外你配置的TypeNameHandling = TypeNameHandling.Objects和自定义绑定器在这个场景里没影响，它们主要管类型识别和对象创建，不影响属性的反序列化规则。

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