一般情况下，我们会对集合有判空操作。但是往往我们只会做如下的判空：
list == null || list.size()==0
可是经常忽略了可能出现的这种情况。
list.size()==1&&null==list.get(0)
而这种情况其实很容易出现。
比如我们写了一个sql，去获取一些记录。
对于唯一的记录，返回的null值，我们通常会想到处理它。因为是惟一的记录啊，所以，有值还是没值的问题，对程序员的迷惑性很低。
而当我们使用List<T>接收时，其实是很容易被迷惑的。
来看实际的问题吧。
还是sql。sql是很容易产生null值的。
以下两种常见的坑，我来写一下。
1、T为一条完整的记录
如果sql直接查的就是一条完整的sql，那么它有，没有，这两种场景是十分明确的，是有一条分界线的。id存在就是存在。
所以如果用List接收，只可能出现[null]这一种情况。所以，稍微注意到这个问题之后，就很容易用我上面那条语句规避，并且笃定，不可能出现第二条null值。
然而现实是残酷且戏剧性的，因为通常我们可能只需要获取到的sql记录中的某个字段的值。这样就出现了第二种情况。
2、T不是一条完整的记录
如果sql只是查一个字段，然后用String来接收，可能这条记录在数据库中是存在的，但是这个字段是不存在的。因此当查询到多条数据时，奇妙的bug产生了。你发现你发送了一连串的null值。如：[null,null,null,null,null]
并且会大呼奇怪，怎么可能有这样的情况！我的sql，我的sql明明！！！诶，当你细想之后，意识到sql可能出现这种问题的时候，可能你的代码已经上线，在疯狂告警中被diss。
所以，建议对于集合接收的sql记录，在使用前，都可以做一个去null处理
我提供了一个utils方法
/**
* 去除List<String>中的所有null值。
* 如果本身为空/null，则返回空list
*/
public static List<String> getNonNullObjList(List<String> oriList ){
if(CollectionUtils.isEmpty(oriList)){
return Collections.EMPTY_LIST;
}
return oriList.stream().filter(Objects::nonNull).collect(Collectors.toList());
}
当你使用list之前，判空之前，先去除其中的不应该存在的null值，避免参数检查混淆视线。
以上。
