前几天的新坑，还热乎着呢，赶紧拿来给大家分享一下.我相信不认真看我的文章，你如果做这个功能，会有99%的挖坑的可能，哈哈！
声明：我这里都是用一些简单流程，简单表等做一个设想，实际业务场景会比举例复杂很多！
先列几个名词：
表 t_order_pay 有个支付状态pay_state 有这么几个值
I:init 初始状态
U:unknown 未知（处理中）状态
S:success 成功状态
F: fail 失败状态
用户在购买商品的时候，支付结果显示未知，但是购买商品状态已经是发货中. 导致我们的结果，跟实际代付的结果不一致!
发生这个问题的原因是：
我先上图哈！
0.数据入库状态 为I
1.请求代扣（耗时比较长或者网络问题导致）
2. 在第1步还在等待的时候，回调请求进来了,把状态I -> S，通知商家发货
3.第1步在等了好长时间后超时了，处理处理把状态修改为 U （注意，这里跟本没有检查库里的原来状态，直接修改为了U）
最终成我们上在说的状态不一致的结果！！
上重点：正确的处理方式
1.不要幻想，回调一定发生在请求之后！！
2. 每次一定要带上原状态值的条件，第三部的处理应该是update t_order_pay set pay_state = U where pay_order=XXX and pay_state = I 并且在必要时（看业务）通过update后影响的行数做后续处理！
这里更多的是提醒大家，在设计程序的时候要多考虑异常情况，错误情况发生后程序怎么处理。
我看过太多人。处理问题，只有成功，失败！跟本没有异常，超时等处理逻辑，一上线就是各种问题！！