【坑】时效性数据传参的后果

版权声明：本文为博主原创文章，未经博主允许不得转载。 https://cloud.tencent.com/developer/article/1434174

前几天在测试的时候发现一个bug，刚开始还很莫名奇妙，反复找原因都找不到，后来分析请求和返回报文的时候，才发现这个问题产生原因。为了让大家可以少走弯路、少掉坑，这边和大家一起分享一下。

应用场景：

app可以用手机号来兑换别的系统金币，运营平台拥有修改绑定手机号的功能。正确的流程应该是运营平台修改用户对应的绑定手机号之后，兑换产生的分值也会发放到我们已经修改后的手机号码中。

bug场景：

在测试的过程中就发现一个问题，不管我们怎么修改绑定手机号，兑换的一直都是第一个绑定的手机号码。只有当app刷新的时候，重新进入兑换页面才会用修改后的绑定手机号，进行分值兑换。

问题分析：

刚开始以为是对方系统出现问题了，后面发现分值可以兑换成功，只是号码不是我们最新绑定的号码。然后继续分析，也有可能是运营平台修改没有成功，但是查看数据库，发现确实是已经成功了。最后根据app那边反馈过来的情况，最终定位为有可能app是直接拿缓存的绑定手机号，来进行分值兑换操作，查询一下app请求报文，发现还真实这个问题。

方案制定：

这种情况其实很好解决，app那边不需要传绑定的手机号来兑换，只要传一个用户id，然后服务端通过这个用户id，去查询对应的绑定手机号，然后通过查询到的绑定手机号去兑换。这样就可以保证每次用户兑换，都是最新修改那个绑定手机号了。

问题反思：

问题是已经解决了，但是我们不能仅仅解决问题就可以了，一定要思维扩展、举一反三，看看系统中有没有可能存在类似的情况，火速找到马上解决，然后分析产生这样问题的原因。之所以会产生这样的bug，最根本的原因就是：没有拿不变的参数来请求服务端接口，这句话的意思是：app接口请求的时候千万不要拿一个可能会被修改的字段作为请求参数，一个要拿一个不可改变的参数作为请求参数，通俗的来说就是要拿不具备时效性的数据来请求。

总结：

看了上面的例子，以后大家要是遇到类似的应用场景，一定知道怎么处理了吧。刚刚说到举一反三，其实电商系统中有很多这样的例子，比如提交订单，我们在订单预览的时候，可以看到这一单所对应的积分值，但是千万不要直接拿这个预览的积分值作为实际的积分值，一定是传一个订单id（不具备时效性），然后通过后台自己去计算积分值。好了今天的内容就介绍到这边了，谢谢大家的阅读～