恼人的bom头

65279 ，记事本中常见的bom头。

万万没想到，居然出现在了数据里。

前两天程序突然出现了一个字符串判等错误。原本以为是客户填错了，后来翻数据一看，这怎么俩字符串一模一样？

---

本来就是一个equals返回false的问题。看数据是相同的字符串，然后去翻日志，日志里也是相同的。

尝试了很多办法都没看出有什么不同。

于是后来一气之下一个字符一个字符的判断过去，结果就发现了问题所在。

两个字符串居然长度不一样，有一个字符串开头多出一个不可见字符，将字符转成int后发现，这第一个字符就是65279。

这东西就是bom头，我经常看到的地方就是各种文本编辑器保存文件的时候可能会加上这个头。

---

所以其实这个问题解决方案就很简单，把数据改一下就行了。

但是这个头是怎么出来的呢？出问题的字符串来源是一个不应该被修改过的数据，而这个数据在以前是可行的，这就很奇怪。

当时得出结论已经快下班了，于是就保留事故现场，第二天再来找源头。

结果第二天上班之后发现，这个问题又消失了，客户已经正常使用了。

---

事故现场消失，无法排查原因，只能做些推测。

数据是存储在redis中的，怀疑是序列化中出现问题，序列化方案是FastJson提供的序列化工具类GenericFastJsonRedisSerializer