@test public void test(){ String date1="{createTime:"1570636800000"}"; String date2="{createTime:1570636800000}"; LoginRequestDTO dto=JSON.parseObject(date1,LoginRequestDTO.class); } 注：createTime 对象是LocalDateTime 的格式，用的是JDK8的格式
解析date1 则报错 解析date2 不报错 两者差的是 引号，或者说是 一个是text文本传递过来的格式，一个是long 格式 在requestBody里，如果是date1格式，那么因为直接会转成对象，那么date1 格式直接报错。 如果是 Date 格式的，就没有这个问题，LocalDateTime 就有这个问题
这应该属于使用不当吧，当date1中createTime是字符串时候应该以格式化的时间字符串，比如 String date1="{createTime:\"2019-08-19\"}"这样就没问题了。
date1 编译都不通过，如果是requestBody传过来的数据 首先应该自己先看一下 格式对不对吧，在IDEA里面String date1="{createTime:"1570636800000"}"; 编译直接就报错
已经支持，等新版本吧
总是喜欢“修复”这些奇怪的bug，估计一般都会引入新bug~
@wenshao
举个可能会造成新bug的例子
@JSONField(format="yyyyMMddhhmmss")
配置了这东西之后，日期时间类型的字段也会变成很长的纯数字，如果你改成了无配置自动按毫秒数来转换，会与这种配置有冲突。如果已经有人这样用了，你为了向下兼容，还得判断有没有设置format，并且format是不是纯数字格式的~
已经支持，等新版本吧
谢谢温少支持，赞
总是喜欢“修复”这些奇怪的bug，估计一般都会引入新bug~ @wenshao 举个可能会造成新bug的例子
@JSONField(format="yyyyMMddhhmmss")配置了这东西之后，日期时间类型的字段也会变成很长的纯数字，如果你改成了无配置自动按毫秒数来转换，会与这种配置有冲突。如果已经有人这样用了，你为了向下兼容，还得判断有没有设置format，并且format是不是纯数字格式的~
主要因为FASTJSON 在传输LONG 很长的数字过程中，因为精确度问题，需要使用STRING方式 自动转换，但另一端接收此API过程中localDateTime，不认识String的时间戳（Date就没有此问题）。 这个算是比较大的问题了。
这应该属于使用不当吧，当date1中
createTime是字符串时候应该以格式化的时间字符串，比如String date1="{createTime:\"2019-08-19\"}"这样就没问题了。
这样问题更多了，你在一个时区内还好，你夸时区，做全球生意的话，那时间就乱套了，根本不知道String下的时间格式 是什么时区的，增加复杂性。
date1 编译都不通过，如果是requestBody传过来的数据 首先应该自己先看一下 格式对不对吧，在IDEA里面String date1="{createTime:"1570636800000"}"; 编译直接就报错
是因为引号问题， 需要加转义\才能通过编译。