运营侧需要查看订单是否已支付，以及支付宝交易号等排障信息。
# 任务
实现
事实上，订单状态和流水在项目里是两套数据，mallrpc只有paytime，其他的都在paymentrpc的表里
因此要先设计一条不会让网关直连数据库、也不会在列表中逐单调用支付宝的查询链路
可以在mallrpc的订单查询读模型，而不是直接接paymentrpc，因为mallorders已经保存了最终确认的订单号，时间等，若在admin网关逐条查流水，会产生n+1调用，并且分页也不准确
n+1查询（n+1调用）本质在于程序为了获取一个“主对象”列表及其关联的“子对象”信息，错误地执行了“一次”用于查询主列表的查询，以及紧随其后的“N次”用于查询每个主对象所关联子对象的、额外的独立查询，从而总共向数据库发起了“N+1”次查询
首先，我们需要自己定义一套支付状态枚举，而不是把订单状态作为支付状态，因为订单状态包括更多业务状态
- -1表示全部，用于筛选请求
- 1表示未支付，支付相关的字段全为空（out_trade_no、trade_no、pay_time）
- 2表示已支付，上面三个字段全存在
- 3表示异常，只有一部分存在
修改mallRPC相关字段，让他带上payment侧特有的字段包括我们定义的枚举
在common.go添加相对应的状态计算和rpc映射函数，根据传入的支付凭证完整性计算运营侧支付状态
并且需要在数据库分页前应用筛选，在mall的model中更改，并且需要在count之前
接下来在admin API文件中补充字段，并修改order_list逻辑向rpc传递status
# 验收标准
# 测试
测试支付状态计算：在logic下新建common_test文件，构造多种状态对应枚举的test
新建vars_test文件，测试订单返回的status是否是符合预期的
最后是全链路测试，模拟一次支付看最后是否是预期的payment_status