在spring boot项目中已经包含有json序列化的框架，具体在包com.fasterxml.jackson.annotation中，建议看看详细源码。
但在项目应用上还是会有一些坑会出现的，举个例子：
在一个复杂的业务模型中包含有200个字段，在查询列表时只查询其中某20个字段，在查询详情中需要把所有字段都查询出来。
一般情况下，如果是开始做一个新功能，那么我们的设计应该类似是这样的：
model
---- QueryModel ，包含20个字段，响应查询列表结果
---- DetailModel extend POJO ， 包含所有字段，响应查询实体结果
entity
---- POJO，包含所有字段
但维护从来都是一件蛋疼的事情，200个字段是迭代出来的，他们的逻辑是这样的：
entity
---- POJO，包含所有字段，响应查询列表和查询实体结果
这时候会发现一切蛋疼的原因就是直接把pojo拿来当model用了，导致所有参数和结果无法拓展。为什么会这么蛋疼呢？原因不重要，如何解决才重要。
方案1：代码解耦，改造成model和entity分离
此方案的好处是一劳永逸，后续的拓展也比较轻松，弊端也显而易见，会发费许多时间去理解业务重构业务，而且一个稳定的系统一般不会尝试大范围的改造，万一改后出现一堆bug呢？
方案2：把不输出到页面的字段忽略掉
这时候用到注解 @JsonIgnore，该注解既可以作用在字段上也可以作用在方法上（另外两种先不说），可以看看源码和注释：
package com.fasterxml.jackson.annotation;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
/**
* Marker annotation that indicates that the logical property that
* the accessor (field, getter/setter method or Creator parameter
* [of {@link JsonCreator}-annotated constructor or factory method])
* is to be ignored by introspection-based
* serialization and deserialization functionality.
*<p>
* Annotation only needs to be added to one of the accessors (often
* getter method, but may be setter, field or creator parameter),
* if the complete removal of the property is desired.
* However: if only particular accessor is to be ignored (for example,
* when ignoring one of potentially conflicting setter methods),
* this can be done by annotating other not-to-be-ignored accessors
* with {@link JsonProperty} (or its equivalents). This is considered
* so-called "split property" case and allows definitions of
* "read-only" (read from input into POJO) and "write-only" (write
* in output but ignore on output)
*<br>
* NOTE! As Jackson 2.6, there is a new and improved way to define
* `read-only` and `write-only` properties, using
* {@link JsonProperty#access()} annotation: this is recommended over
* use of separate <code>JsonIgnore</code> and {@link JsonProperty}
* annotations.
*<p>
* For example, a "getter" method that would otherwise denote
* a property (like, say, "getValue" to suggest property "value")
* to serialize, would be ignored and no such property would
* be output unless another annotation defines alternative method to use.
*<p>
* When ignoring the whole property, the default behavior if encountering
* such property in input is to ignore it without exception; but if there
* is a {@link JsonAnySetter} it will be called instead. Either way,
* no exception will be thrown.
*<p>
* Annotation is usually used just a like a marker annotation, that
* is, without explicitly defining ‘value‘ argument (which defaults
* to <code>true</code>): but argument can be explicitly defined.
* This can be done to override an existing `JsonIgnore` by explicitly
* defining one with ‘false‘ argument: either in a sub-class, or by
* using "mix-in annotations".
*/
@Target({ElementType.ANNOTATION_TYPE, ElementType.METHOD, ElementType.CONSTRUCTOR, ElementType.FIELD})
@Retention(RetentionPolicy.RUNTIME)
@JacksonAnnotation
public @interface JsonIgnore
{
/**
* Optional argument that defines whether this annotation is active
* or not. The only use for value ‘false‘ if for overriding purposes
* (which is not needed often); most likely it is needed for use
* with "mix-in annotations" (aka "annotation overrides").
* For most cases, however, default value of "true" is just fine
* and should be omitted.
*/
boolean value() default true;
}
因此在使用的时候需要注意，如果只需要在查询的时候忽略，在保存的时候不忽略，那么需要在getter方法上注解@JsonIgnore，在setter方法上注解 @JsonProperty，（这时候如果使用的lombok就很尴尬了），举个例子：
public class TestEntity{private String name;
/**
* getter
*/
@JsonIgnore
public String getName() {
return name;
}
/**
* setter
*/
@JsonProperty
public void setName(String name) {
this.name= name;
}
}
然后在sql上从select *改成select 指定字段，解决查询列表问题。
然而，在查询单个实体详情的时候这些被忽略的字段也无法传到前端了，这是一条乍一看很理想的死胡同。
但从sql的角度上可以看出select 指定字段的时候，在反序列化到pojo的时候其他字段是没有值的，那么可以把方案换一下，让有值得字段序列化出去，没有值的不序列化
方案3：让有值得字段序列化出去，没有值的不序列化
把sql上从select *改成select 指定字段
在pojo里用上@JsonInclude(JsonInclude.Include.NON_NULL)，
此时既满足查询列表，又满足查询详情，解决问题。
原文地址：https://www.cnblogs.com/zqyx/p/10221244.html