核心改造: - 增量算法:流量计算从覆盖式改为增量累加(gateway - lastReading),支持上游运营商重置检测 - 日流量缓冲:insertDataUsageRecord 改为 Redis INCRBYFLOAT,每日凌晨落盘到 tb_card_daily_usage - 运营商:新增 data_reset_day 字段(联通=27,其余=1) - IoT卡:新增 last_gateway_reading_mb 字段存储上次网关读数 - 查询层:新建 TrafficQueryService 合并 Redis(今日)+ DB(历史)数据源 - 清理:删除 DataUsageRecord model/store,移除 polling_handler 旧引用 迁移:000094-000097(carrier字段、iot_card字段、数据初始化、日流量表)
4.3 KiB
Capability: 客户端套餐购买
ADDED Requirements
Requirement: D1 创建套餐购买订单接口
系统 SHALL 提供 POST /api/c/v1/orders/create,并且 MUST 要求个人客户认证。请求体 MUST 包含 identifier、package_ids[]、app_type。接口流程 MUST 按顺序执行:归属校验 → 套餐校验(含加油包前置)→ 实名校验 → OpenID 查询 → 幂等检查 → 强充检查 → 分流创建。实名不满足时 MUST 返回 NEED_REALNAME。OpenID 缺失时 MUST 返回 OPENID_NOT_FOUND。幂等 MUST 使用 Redis 业务键 + 分布式锁。分流规则 MUST 为:
- 无强充:创建套餐订单并返回
order_type="package"、order、pay_config - 需强充:创建充值单并返回
order_type="recharge"、recharge、pay_config、linked_package_info
响应体 MUST 包含前端可直接渲染字段。错误码/消息 MUST 至少包含:INVALID_PARAM/参数错误、FORBIDDEN/无权限操作该资产或资源不存在、NEED_REALNAME/该套餐需实名认证后购买、OPENID_NOT_FOUND/未找到微信授权信息,请先完成授权、IDEMPOTENT_CONFLICT/请求处理中,请勿重复提交、PACKAGE_NOT_AVAILABLE/套餐不可购买。
Scenario: 命中强充返回 recharge 结构
- WHEN 客户购买套餐触发强充要求
- THEN 系统返回
order_type="recharge",包含充值单与关联套餐信息
Requirement: D2 套餐订单列表接口
系统 SHALL 提供 GET /api/c/v1/orders?identifier=xxx,并且 MUST 要求个人客户认证。接口 MUST 做归属校验并按资产当前 generation 过滤订单。请求参数 SHALL 支持 payment_status、page、page_size。响应体 SHALL 返回 list[]、total、page、page_size,列表项至少含 order_id、order_no、total_amount、payment_status、created_at。错误码/消息 MUST 至少包含:INVALID_PARAM/参数错误、FORBIDDEN/无权限操作该资产或资源不存在。
Scenario: 支持支付状态筛选
- WHEN 客户带
payment_status=paid查询订单 - THEN 系统仅返回当前 generation 且支付状态匹配的订单
Requirement: D3 套餐订单详情接口
系统 SHALL 提供 GET /api/c/v1/orders/:id,并且 MUST 要求个人客户认证。接口 MUST 基于订单关联资产执行归属校验(通过资产虚拟号匹配 PersonalCustomerDevice)。响应体 SHALL 返回订单详情、套餐明细、支付信息、状态流转时间。错误码/消息 MUST 至少包含:INVALID_PARAM/参数错误、FORBIDDEN/无权限操作该资产或资源不存在、ORDER_NOT_FOUND/订单不存在。
Scenario: 查询他人订单被拦截
- WHEN 客户请求不属于本人资产的订单详情
- THEN 系统返回 403,错误消息为无权限操作该资产或资源不存在
Requirement: AutoPurchaseAfterRecharge 异步任务
系统 SHALL 增加 AutoPurchaseAfterRecharge Asynq 任务处理强充二阶段。任务输入 MUST 包含 recharge_record_id。处理流程 MUST 为:从钱包扣款(payment_method=wallet)→ 创建套餐订单(source="client"、写入当前 generation)→ 激活套餐。任务失败 MUST 自动重试,最大 3 次。全部失败后 MUST 将 auto_purchase_status 标记为 failed,并保留钱包余额供用户手动购买。成功时 MUST 标记为 success。
Scenario: 异步任务连续失败
- WHEN AutoPurchaseAfterRecharge 连续执行失败且达到最大重试次数
- THEN 系统将充值记录
auto_purchase_status更新为failed
MODIFIED Requirements
Requirement: C端支付状态枚举统一
C端订单查询接口返回的 payment_status SHALL 直接使用管理端统一枚举值(1=待支付, 2=已支付, 3=已取消, 4=已退款),不再通过映射函数转换为 0/1/2。
Scenario: C端查询订单返回统一枚举
- WHEN C端客户查询订单列表或订单详情
- THEN 返回的
payment_statusSHALL 为 1/2/3/4 之一,与管理端一致
REMOVED Requirements
Requirement: C端支付状态映射
Reason: orderStatusToClientStatus() 函数将管理端 1/2/3/4 映射为 C端 0/1/2,造成前后端枚举不一致,增加维护负担。
Migration: C端前端需更新支付状态枚举解析:1=待支付, 2=已支付, 3=已取消, 4=已退款。