前因
在dev和qa环境正常获取到用户的userId,dev和qa环境的userId长度都不长，通过userId查询数据，显示数据完全正常。
但是上线之后，很快有运营反馈使用userId查询不出结果，经过验证发现确实这样，开始排查问题
排查过程
由于我们项目后端使用的是接口层与业务层隔离的架构，所以先在业务层加上日志，拿到日志之后和web层获取到的数据进行对比。对比结果发现该userId在较长时候确实
出现了不一致的情况，但是业务层的数据和数据库中的数据完全一致，哪一步操作导致精度丢失了呢？
进一步排查，在接口层打输入输出日志，发现接口层的输入输出与业务层完全一致，在此种情形下，我们有点摸不着头脑，还以为是我们读错了库的原因。
验证数据库后发现，库没读错，数据完全和库一致，那只能是传输过程中出现问题了。
我们使用的是chrome浏览器，接口层数据是直接使用network扩展里面的preview，经过仔细排查发现，preview的数据和response里面的数据不一致，至此问题找到：
前端接受json数据时，精度丢失。
解决方案
因为字段固定的缘故，我们不准备从后端进行更改，准备web层直接进行修改，经过一番修改，查询的传输的userId并没有出现丢失的情况，但是展示的问题前端确实没法解决。
由于业务层和接口层分离的原因，我们不能为了一个字段去改动业务层（业务层的接口是公共接口，并且是完全对应db字段），直接从接口层去修改，使用一个新类继承老类来进行操作，将该long数据转化成字符串，经验证，该问题解决。
后果
该问题经过紧张迅速排查并解决，并且让我们意识到数据不会骗人，但是浏览器会骗人，在long型数据上，我们进行展示和操作时，需要谨慎对待，丢失精度成本很高。
