今天我们回顾一个线上bug，bug的背景是这样的：

携程收购了去哪儿，但是携程的用户体系和去哪儿的用户体系还没有完全的统一，也就是说用户要区分携程用户和去哪儿用户。

携程和去哪儿各有一个app，分别叫做携程旅行和去哪儿旅行，携程的用户使用携程旅行app，而去哪儿用户，则使用去哪儿旅行用户。

现在有一个页面叫程信分首页，这个页面携程和去哪儿用户都可以看到，页面的地址是：http://{domain}?originChannel={originChannel}，其中 originChannel 参数就是用来标识这个用户是从哪个app过来的，如果是携程用户，originChannel=CTRIP，如果是去哪儿用户，originChannel=QUNAR

因为一些原因，携程旅行app里面的跳转链接originChannel参数配置错误了，导致用户在携程端访问这个页面的时候，使用了地址：http://{domain}?originChannel=QUNAR。

程信分首页会解析originChannel参数，并且用于发后端请求，由于是携程的用户，但是传递给后端的确实QUNAR，导致后端判断用户类型错误，引发了异常。

最终这个线上bug产生的影响是，用户在携程端，进入程信分首页后会报错。

这个bug怎么解决呢？

有两个方案，一个是修改携程端的originChannel参数，修改为CTRIP就好了；另外一个方案是，不要让后端信任前端的参数，后端自己根据用户的登录态来判断是携程的用户还是去哪儿的用户，这样，前端免除了配置originChannel的工作，因为没有配置，也就不会发生配置出错的可能了，另外后端根据用户的登录态来进行判断，会更准确，更安全(防止有人篡改originChannel)。

其实之前已经发生过一次这种线上问题，不过当时受影响的用户量比较小，所以后端同学当时没有引起注意，也没有按照第二种方案来修复。

由此产生的一个影响是，更多的用户在这次bug中受到了影响，而且为了排查和解决这个问题，前端、后端、产品、测试等一票人，耗费了周六一早上的时间，有个前端同事已经去门了，不得不打了半个多小时的车回来修复问题，还有一个后端同事，因为修复问题，公司的年会也没来得及去。

一次疏忽，换来了百倍的成本，谨记！