问题

主要与后端转json使用的FastJson序列化方式有关，Long类型的数据，如果我们在后端将结果序列化为json，直接传给前端的话，在Long长度大于17位时会出现精度丢失的问题。
java中的long能表示的范围比js中number大,也就意味着部分数值在js中存不下(变成不准确的值)，比如此案例中Id最后两位直接变成了0。

解决方式一：

在Long类型字段上加序列化注解。

    @JsonSerialize(using = ToStringSerializer.class)
    private Long id;

缺点1： 此种方式需要手动在所有此类型下添加，比较麻烦。
缺点2： 在使用了JSON.parseObject（）进行反序列化时，反序列化的对象传给前端又变成了long类型。还会出现精度丢失问题。

解决方式二

通过重写WebMvcConfigurer中的configureMessageConverters方法来重新配置转换器。

    @Override
    public void configureMessageConverters(List<HttpMessageConverter<?>> converters) {
        //1.需要定义一个convert转换消息的对象
        FastJsonHttpMessageConverter converter = new FastJsonHttpMessageConverter();

        //2.添加fastJson的配置信息
        FastJsonConfig fastJsonConfig = new FastJsonConfig();
        SerializeConfig serializeConfig = SerializeConfig.getGlobalInstance();
        //3.设置Long为字符串
        serializeConfig.put(BigInteger.class, ToStringSerializer.instance);
        serializeConfig.put(Long.class, ToStringSerializer.instance);
        serializeConfig.put(Long.TYPE, ToStringSerializer.instance);
        fastJsonConfig.setSerializeConfig(serializeConfig);
        converter.setFastJsonConfig(fastJsonConfig);
        converters.add(converter);

缺点： 后端返回的数据，只要是Long类型的字段，都会被转成String返回，导致扩大了转换范围，不过可以解决所有long类型带来的精度问题。