首先说一下，支付宝支付时容易出现理解偏差的两个字段
一个是timeout_express
另一个是time_expire字段
timeout_express字段可以理解为，用户输入支付密码/或签约支付发起扣费，支付宝开始进行轮询用户可用支付方式的开始(好像支付宝收银台的话，如果用户欠费，会直接给打回来)
说一下，出现问题的两个场景
场景一：
使用的是支付宝收银台支付，送的字段是timeout_express，本以为此字段的意思为，后端产生送支付宝表单后过XXmin后给判定为超时的一个设置，就这样送了，没想到后来，接到客诉，用户支付成功，扣款成功，在咱们系统中却返回了失败。
经过排查可以看到，咱们这边送出的timeout_express字段，设置的是15min，之后，我们的系统设置了15分钟的异步查证，一直显示订单不存在，之后15分钟时，结束异步查证，判定最终结果为失败，但是，支付宝在1h2min的时候通知了系统，用户支付成功，由于订单已经处理为终态了，所以不做修改，造成了这个问题。
咨询小蚂哥才知道，这个timeout_express假设在收银台场景，代表的是用户正确输入密码支付宝受理这笔订单业务开始计时15分钟，在已签约支付宝代扣的业务情况下，则是轮询扣费的轮询定时时间，并不是之前臆想的，后端送的请求时间timestamp+timeout_express是过期时间。
这个用户可能就是停留在支付宝收银台页面1h后发起了支付，等支付宝通知的时候，我们的订单已经终态，不会再受理了。
所以后来建议使用的time_expire，这个参数是绝对超时时间，也就是支付宝在time_exipre时间点后，就不会对订单进行受理处理。所以在使用这两个字段前，注意自己的业务场景，看应该使用什么字段。
场景二：
先说一个支付宝枚举的状态设置
WAIT("WAIT_BUYER_PAY", "交易创建，等待买家付款"), //
CLOSED("TRADE_CLOSED", "未付款交易超时关闭，或支付完成后全额退款"), //
SUCCESS("TRADE_SUCCESS", "交易支付成功"), //
FINISHED("TRADE_FINISHED", "交易结束，不可退款");支付宝签约代扣，同步请求返回的报文中会有状态码和业务返回码描述
但是，一般情况下，我们选择的都是异步查证，根据查证结果进行最终结果的确定
现在有这么一个场景，用户支付失败，原因为用户余额不足，在同步发起交易的时候，返回的状态码和返回码描述，我们有操作入库，但是订单状态在同步处理之后，定为处理中状态，等待异步查证结果进行订单状态改变。
当返回的tradeStatus字段为WAIT_BUYER_PAY状态时，订单会继续进行补偿查询(在这里提一下场景一中的两个字段，可以选择适当的字段进行表单的递送，亲测在使用timeout_express字段时，可能中间mq的发送等原因，会产生一到几分钟的延迟，测试时设置的15分钟，实际支付宝最终补偿了17分钟--从生成表单开始计算)。
但是建议不要本地设置订单任务，走完定时补偿后，确定订单最后状态，最好是以tradeStatus字段最后返回终态为准（不是WAIT都为终态）
我们遇到的问题就是，在由处理中状态变为终态的时候，把这次查询作为最后一次补偿，同时MQ通知到上游系统，送的状态是没有问题的，但是取不到返回码描述，仔细看蚂蚁提供的文档才知道......查询接口是不提供返回码描述的......
如果需要向上游送错误信息的话，可以在这方面注意一下了，不要直接把查询结果进行返回，最好是依赖状态变更对DB的保存或Redis的保存进行返回.....多测试一下
都是因为开发时粗心出现的两点小问题，分享出来丢丢脸......哈哈哈
