Long类型框架自动序列化成String失效问题排查

求知探索 1年前 ⋅ 835 阅读

问题描述

微服务架构下进行业务模块开发时,发现每次涉及到Long类型的字段时需要自己手动增加@JsonSerialize(using = ToStringSerializer.class)注解来序列化成字符串防止精度丢失

但是我觉得这样处理不合理,我认为太笨拙,肯定有全局的方式。所以了解原理后尝试通过修改框架源码,通过objectMapper.registerModule(new LongModule())的方式来全局解决这个问题。

修改完成之后本地测试没问题,但是部署到开发服务器就出问题了。

由于JS的Number类型只支持17位长度,后端返回Long类型是20位的,所以最后三位被自动转成0。

猜想

1. 写错了

首先想到的就是哪里写错了,我检查了代码,本地多次测试都是能得到期望值;

2. 重新使用

重新使用@JsonSerialize(using = ToStringSerializer.class)直接对字段进行序列化,部署之后问题得到解决,由此我判断是开发环境框架的jar包有问题导致我修改后的代码没生效;

验证猜想

1.验证猜想

开发环境的jar包是从maven仓库下载的,首先我就去maven下载了最新jar包,用jd-gui反编译工具查看之后发现jar包没问题,这就奇怪了。

2.继续猜想

因为我们开发环境做过一次迁移工作,所有的应用和仓库等等,宿主机IP都更新了,我怀疑当时安装maven的同事没有更新仓库的配置文件,所以去开发服务器上检查了maven的settings.xml配置,结果发现,是最新的配置。。。

3.再次猜想

会不会是打包的时候出问题了,打包过程中下载的jar包版本不对。

4.再次验证

所以我从Jenkins工作目录找到了对应应用的jar包,反编译之后一看,果然代码不对。

5.疑惑

maven是正确的配置,为什么打包的时候会下载错误的jar包呢?

6.找到原因,解决疑惑

maven是会根据settings.xml文件找到正确的仓库,这一步没问题。查看本地仓库中对于jar包的pom文件,发现pom文件是旧版的仓库地址,因为做迁移的时候,nexus应用是最后做的迁移,所以应用迁移完成后发布的时候,pom文件是从旧仓库下载的。为什么新的maven配置文件更新后,没有下载jar包最新的pom文件?因为我们更新框架jar包没有使用版本号,并且使用的是release仓库,maven的默认策略是不会去更新相同版本号的release版本jar包。

7.解决

删除本地仓库中框架jar包的pom文件,重新部署应用,发现自动下载了最新的pom文件,然后去掉@JsonSerialize(using = ToStringSerializer.class)注解上开发环境验证Long类型精度丢失的问题。Long传给前端没有丢失精度,至此问题解决。


全部评论: 0

    我有话说: