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

目录

• 问题描述
  • 猜想
    • 1. 写错了
    • 2. 重新使用
  • 验证猜想
    • 1.验证猜想
    • 2.继续猜想
    • 3.再次猜想
    • 4.再次验证
    • 5.疑惑
    • 6.找到原因，解决疑惑
    • 7.解决

问题描述

微服务架构下进行业务模块开发时，发现每次涉及到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传给前端没有丢失精度，至此问题解决。
End