有一天，我们系统服务的依赖者找到了我们，问我们为什么这些数据存在于时间类型的字段中？导致他们在分析时报错。

{"sloganEndtime": "20211-03-10 11:30:00"}// 字段类型private Date sloganEndtime;

所以我们开始调电脑查，最后发现数据源来自于导入表的功能，业务运营商在导入数据时写错了，导致了非常离谱的问题。

利用原生JDK来转换时间 代码截图如下:

我们换FastJson试试，代码如下：发现会报错！

SkuMainBean mainBean = JSON.parseObject("{\\"sloganEndTime\\":\\"20211-03-1011:30:00\\"}", SkuMainBean.class);System.out.println(mainBean);# 异常信息Exception in thread "main" com.alibaba.fastjson.JSONException: For inputstring: "20211-03-10 11:30:00"atcom.alibaba.fastjson.parser.DefaultJSONParser.parseObject(DefaultJSONParser.java:627)at com.alibaba.fastjson.JSON.parseObject(JSON.java:361)为什么FastJson会出问题

跟代码，我们发现FastJson有自己的默认时间格式：

// 电脑com.alibaba.fastjson.JSON#DEFFAULT_DATE_FORMATpublic static String DEFFAULT_DATE_FORMAT = "yyyy-MM-dd HH:mm:ss";

但判断逻辑的使用是提前验证的FORMAT参与长度：

电脑 if (strVal.length() == parser.getDateFomartPattern().length()){DateFormat dateFormat = parser.getDateFormat();try{return (T) dateFormat.parse(strVal);}catch (ParseException e){// ski }// ...return (T) new java.util.Date(longVal);解决方案(3种)

1.积极增加格式化注释，特别是在需要转换未知参与时，需要提前确定

@JSONField(format="yyyy-MM-dd HH:mm:ss")private Date sloganEndtime;利用时间戳（Long）替换Date当数据传输时，类型本身的系统，保证数据的合理性，增加相关验证反思为什么FastJson（1.2.36版)使用日期格式化时应提前验证长度？

PS：为什么不检测无注解直接转换失败？