我看到了以下的好处，在有pojo
1.可读性-你不会真正知道一个复杂JSON的结构。写一个简单的get需要知道json的结构。请参考我的文章中的“POJO over JSON Objects”一节-> https://medium.com/tech-tablet/programming-went-wrong-oops-38d83058885
1.提供类型检查-我们可以很容易地将一只猫分配给一只狗，甚至直到运行时才知道它。
1.通过组合和封装，感觉更面向对象--使用POJO很容易理解设计者的观点。一辆有轮子的汽车。
1.你可以选择你想要实现的对象，并只将其保存在内存中-当我们通过网络接收到的对象被JSON对象实现时，没有办法选择什么必须被实现并存储到内存中。如果你有一个1 MB大小的对象，而有效负载只有200 MB，那么如果我们不使用POJO，我们最终将把整个1 MB对象保存在内存中。
1.允许使用集合，并以清晰的方式对其进行流操作-在JsonNode中没有对流操作的原生支持。我们需要使用一个StreamStupport对象，这是可以避免的。
1.允许跨框架引用。通过一些注解，您可以选择将特定字段Map到数据库客户端-当您为数据库使用ORM框架时，很容易将实体注解和Map到数据库模式。
1.自然支持设计模式
1.最小化非本机依赖-为什么必须使用JsonNode或在本机Java中本身没有的等效物？特别是如果它有上述缺点。
如果你担心POJO附带的仪式，比如有getter，setter等，看看“Lombok”。这个库将帮助您以简洁的方式创建pojo，并仍然获得上述好处。
另一方面，如果你正在处理一个很难改变的API，它的响应是动态变化的，那么JsonNode是一个快速成功的候选者。

这实际上取决于您的应用程序的情况和性质。如果您接收的数据没有固定的结构/字段名称/数据类型，或者它一直在变化，那么使用JsonObject当然更有意义。
另一方面，如果它的结构是固定的，并且涉及访问字段的操作，那么最好使用pojo。它具有更好的可读性IMO。

视情况而定：
1.使用Pojo：
1.如果数据字段像它们的名称一样是固定的，则输入use Pojos，因为它将清晰易读。
1.如果在很多地方使用重构，它会更容易。
1.如果你想把这些数据保存在db中，那么修改数据也很容易。假设在你的pojo中有一个数据在执行计算时使用，但是你不想把它保存在db中（所以你可以简单地通过在java中使用@Transient关键字来完成，但是如果你使用了JsonObject，这需要一些代码更改）。
1.假设你不想在响应中传递空值，你可以通过在java中使用@JsonInclude(Include.NON_EMPTY)使用pojo轻松地实现。
1.使用JsonObject：
1.如果数据字段不像它们的类型或结构那样固定，那么你将无法在pojo中Map它。

我想补充一点：

• 对于POJO，您可以使用构建器模式。
• 未来的重构将更加容易。假设你有一个类Person，并且你在代码中的很多地方都使用了这个类。如果Person类需要更改其中一个字段，那么您可以很容易地找到更改它的位置。
• 使用POJO可以使你的代码与你的领域更加紧密。如果你正在为一家汽车公司编写代码，你会有Car、Wheels、Engine等类。你的代码将变得更加可读和可测试。

这个争论实际上可以归结为您是否希望使用POJO或Map来处理您正在处理的数据，因为这是两种处理数据风格之间的根本区别。
JsonObject（from jee7）只是一个Map（实际的类型签名扩展了Map<String, JsonValue>）。
使用POJO的（例如使用Jackson进行格式化）是真实的对象。
因此，如果您通常不使用域/模型类来存储数据，那么我想Map也可以。如果您这样做（像大多数开发人员一样），那么将此实践扩展到您的API合同是一个好主意。
关于具体问题：
JsonObject避免了不必要的数据序列化，同时大大减少了类的数量。
这两个JSON API都需要序列化/重新序列化，这是将线数据转换为对象的过程。我敢打赌，Jackson比JsonObject快，然而，正如Satyendra Kumar指出的那样，基准测试将以某种方式证明这一点。
在使用pojo时，我们与rest服务紧密绑定，而jsonObject则提供了自由
如果您使用的是来自API的数据，则您将绑定到数据模型，无论您是通过response.getFoo()还是response.get("foo")从属性foo获取数据。
要全面讨论类和Map之间的权衡，请参阅check out this SoftwareEngineering post。
值得指出的是，使用Jackson/POJO并不意味着您与REST响应的本地模型紧密耦合。Jackson对Tolerant Reader模式有很好的支持，这意味着API响应中的新字段将不会破坏规范化，还有一堆注解，如@JsonCreator、@JsonValue、@JsonIgnore，用于将API响应Map回本地域模型。
它还提供了处理集合和泛型的强大工具。
最后，如果您正在与之交互的服务是大型且复杂的，如果他们提供swagger/raml规范，那么您可以基于该规范进行generate the models，这将大大减少管理POJO所花费的时间。

他们的观点是，当使用pojo时，我们与rest服务紧密绑定，而jsonObject则提供了自由。
问他们这种自由需要多长时间？API模型会一直改变吗？它会在某个时候安定下来。还有，怎么绑的紧？如果模型的某些部分您不确定，您可以为该部分创建一个通用对象，这将为您提供所需的灵活性。
此外，它节省了不必要的数据序列化，同时大大减少了类的数量。
我觉得没必要。直接使用JsonObject非常麻烦。关于减少类的数量，无论如何都应该为正在交换的数据提供一些模型类。它提供了更多的清晰度。如果您使用Swagger，它将添加到REST端点的规范中。Swagger会自动创建表单，以便根据数据模型输入数据。API变得更容易维护（无需额外的文档）。测试变得更容易。
我不知 prop 体的成本，但不知何故，我有一种感觉，它不应该有太大的差异。
唯一确定的方法是基准测试。您可以以此为出发点，深入了解并比较当前的实现https://github.com/fabienrenaud/java-json-benchmark。