调试过程：
开始就采用debug看是不是数据库搞的鬼，发现数据从数据库拿出一切正常。
这就很怪异，为啥数据是对的接口响应就出问题了呢？
然后多测几组数据发现更诡异，有的日期就很正常，有的日期就不行，尤其是和这个用户生日相近的日期，出现少一天的几率很高。然后我就增加测试用例，多测几组数据将出错时间定在1886年-1991年。而且我将@JsonFormat(pattern = "yyyy-MM-dd", timezone = "GMT + 8") 调整为@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT + 8")判断它是不是因为时区造成的，发现这个日期只比正常的少一个小时，显然不是因为时区问题。
然后我就去百度搜索这个时间节点少一个小时，找到一个概念就是夏时制。
1986年到1991年的六个年度，除1986年因是实行夏时制的第一年，从5月4日开始到9月14日结束外，其它年份均按规定的时段施行，时间调快1小时。发现就是因为JsonFormat没有对夏时制进行处理，导致的。然后我从查询了相关的解决方案。
JsonFormat 是源于SpringBoot包下的，不确定的是高版本是否有相关优化。
解决方案：
一、使用虚拟机参数
-Duser.timezone=GMT+08
# 启动时加入
java -java test.jar -Duser.timezone=GMT+08二、使用SimpleDateFormat 格式化
SimpleDateFormat 格式化 Date 经测试没有这个问题，可以手动用这种方式格式化 或者用字符串拼接的方式，具体还要考虑业务场景。
