一、背景
涉及到的项目是 SDK， 用户量 几千万级别，需要调整的是 订单购买整个逻辑，已经发现了低概率问题，影响到的订单不到 0.001% ，但是每周总有几个用户向客服反馈问题。整个逻辑问题，在我入职时候代码Review时候已经发现了，当时和大家讨论的结果是，反馈的用户很少，暂时不动，由客服处理这部分用户。
不动的原因有几点：
1. 当时用户是个别 ，另外用户反馈不及时，当成网络问题处理了，当前版本相对稳定；
2. 总监并不是特别重视（那会儿总监准备离职创业），所以失去了推进；
3. 鉴于我是刚过来，在对项目没有完全熟悉情况下，修改有一定的风险，毕竟用户挺多，每天订单也挺多；
4. 各个项目组研发那边 也是忙于自身版本迭代，也没有提出改进的需求；
二、导火索
随着项目的熟悉，楼主对项目的 错误码 、 订单状态、订单跟踪log 重新梳理分类了一遍，也有跟服务器相关同学多次会议商讨了存在的问题，确定了购买逻辑确实存在一定的问题。后来，我也接手了整个SDK移动端的负责权（说白了我可以动手了）。加上新项目上线了，由于花了不少钱的推广，上线前几天用户量也挺大，又出现了几个case。新项目公司给的标准比较高，所以他们也希望我们能够优化。接着，海外有个项目在测试的时候阴差阳错 在某个时机 会触发这个 bug，也在给我们提出强烈需求。到了不得不动手修改了。
但是，修改的话，服务器需要修改固有的接口，内部逻辑改动较大。SDK移动端 因为涉及到Android 和 iOS ，之前的结构并不是很友好，改动起来 也是挺大。改动大 意味着风险也大，加上是低概率的问题，就算优化了，也不一定短期能获得验证，同时也需要大用户量去验证。 待续。。。。