71 lines
5.8 KiB
Markdown
71 lines
5.8 KiB
Markdown
# 黄金矿工 VIP 礼包
|
||
|
||
本次保留普通周四至周日活动周期及未付费累计进度规则；未采用支付后 168 小时、支付后才累计的个人周期。测试临时期继续由管理员指定开始和结束时间。
|
||
|
||
## 六档数值
|
||
|
||
| VIP | 价格（分） | 满领金币 | 最终累计通关 |
|
||
| --- | --- | --- | --- |
|
||
| 0 | 300 | 6000 | 50 |
|
||
| 1 | 600 | 6000 | 60 |
|
||
| 2 | 1200 | 8000 | 80 |
|
||
| 3 | 3000 | 15000 | 100 |
|
||
| 4 | 6800 | 28000 | 150 |
|
||
| 5 | 12800 | 45000 | 200 |
|
||
|
||
每档十个任务，具体关数和金币逐项采用需求中的表格。完整可发布请求在 [vip-tiers.example.json](vip-tiers.example.json)，示例生效期为 2026-10-01。发布前修改 adminToken、configVersion、生效期，并核对支付渠道商品 ID；普通配置必须在目标周四开始前发布。
|
||
|
||
## 临时期发布：指定开始和结束时间
|
||
|
||
使用 [vip-test-period.publish.example.json](vip-test-period.publish.example.json)，它包含完整六档礼包，可作为 `POST /goldMiner/admin` 的请求体。普通周配置示例的 action=publish；临时期示例的 action=publish_test_period，不要混用。
|
||
|
||
起止时间字段准确名称是 **startsAt / endsAt**（不是 startAt / endAt），均为 Unix 毫秒时间戳，放在请求顶层，与 config 同级：
|
||
|
||
```json
|
||
{
|
||
"action": "publish_test_period",
|
||
"enabled": true,
|
||
"adminToken": "REPLACE_WITH_ADMIN_TOKEN",
|
||
"periodId": "goldMiner:test:vip-20260925-v1",
|
||
"startsAt": 1790301600000,
|
||
"endsAt": 1790305200000,
|
||
"config": { "configVersion": "goldMinerVipTemporaryV1", "...": "此处简写，请使用链接中的完整 JSON" }
|
||
}
|
||
```
|
||
|
||
示例时间为北京时间 **2026-09-25 10:00:00 至 11:00:00**，开始包含、结束不包含。测试前修改时间、adminToken 和唯一 periodId；endsAt 必须晚于 startsAt，发布时活动不能已结束，不能与已配置的其他测试临时期重叠。若需要立即开始，将 startsAt 设置为当前时间附近、endsAt 设置为未来时间。已发布期不可修改；每次新建使用新的 periodId。
|
||
|
||
测试服需设置 PAYMENT_APP_ENV=test、GOLD_MINER_TEST_PERIODS_ENABLED=true。临时期不必填写 config.effectiveFromPeriodId，服务器会使用顶层 periodId；nextPeriodId 可省略，默认顺延到本期结束后的下一普通周活动期。
|
||
|
||
可将文件全文复制到 Postman 的 Body → raw → JSON；如使用已有 06-04 发布请求，把 config 对象放入 tempConfig，顶层 periodId/startsAt/endsAt 分别放入 tempPeriodId/tempStartsAt/tempEndsAt。
|
||
|
||
## 配置与选择
|
||
|
||
activityConfigs 仍使用 activityId=goldMiner 的版本配置，不增加集合。公共字段为 configVersion、effectiveFromPeriodId、unlockPassedLevel、timezone、currency；vipTiers 包含按 vipLevel=0～5 排列的六个对象，每个对象包含 vipLevel、productId、priceFen、tasks。各 VIP 使用独立商品 ID，每档必须十个任务。发布会验证任务内部递增、非 VIP0 目标严格高于 VIP0 对应目标、相邻 VIP 对应目标不下降及最终目标逐档提高。
|
||
|
||
管理员发布接口和临时期发布接口均支持此结构；旧的 productId/priceFen/tasks 单档配置继续有效。现有已参与期的旧快照不自动替换，需通过新期或新的测试临时期验证 VIP 配置。
|
||
|
||
后端从 users.vip_level 选择档位，不信任客户端 VIP/金额参数；允许数字或数字字符串 0～5，缺失、无效及超出范围回退 VIP0。按本次确认，VIP0 不再检查从未付费或是否使用过破冰价，不符合此前首次付费条件仍可展示并购买。
|
||
|
||
## 快照与支付
|
||
|
||
玩家期存储 vipConfigSnapshot 保存入期时六档配置，configSnapshot 保存当前选中档位。未创建订单时，可随 users.vip_level 更新选中档位，同时保留进度。未锁定报价前最多计至六档中的最高最终目标，避免 VIP 升档后丢失原先已通过的关数。
|
||
|
||
创建订单时以同一玩家期记录的条件更新设置 offerLockedAt，锁定本期价格、商品、任务和奖励。页面旧 productId 与最新礼包不匹配时拒绝下单，前端重新查询 info；已有订单不能通过更换 requestId 或 VIP 重选另一规格。普通支付、原生 iOS 和旧客服渠道共用这份快照。订单 goldMiner 中保存 vipLevel 和所选快照哈希；已付费权益发生顺延时同样保留原购买礼包，不切换到用户新 VIP 或新期的其他价格档位。
|
||
|
||
创建订单即锁定报价，包含尚未支付的订单；这样支付签名、回调核验与实际奖励保持一致。提前领完不开始新一期。现有每期一次购买、支付可信确认、到期服务器结算流程继续生效。
|
||
|
||
## 任务与确认
|
||
|
||
- locked：尚未达标。
|
||
- pending_unlock：已达标、未付费，前端显示“已达标待解锁”。
|
||
- claimable：已付费且已达标，可领取任意任务。
|
||
- issuing：已授权，等待客户端保存金币并确认。
|
||
- claimed：已确认领取。
|
||
|
||
手动 claim、confirm_delivery 和到期 confirm_settlement_delivery 均取消前档限制；任务仍按目标关数排序展示。原 claimedThrough 字段仅兼容保留“从第一档起连续已确认的数量”，不是已领总数，也不能作为下一档领取条件。授权去重、账号校验和确认幂等保持有效；金币仍由前端串行保存，保存成功后才确认，不能因放开档位顺序而并发覆盖总余额。
|
||
|
||
## 更新范围
|
||
|
||
云端业务模块更新 goldMiner/config、goldMiner/service、goldMiner/payment，随后发布六档活动配置。goldMiner/admin、goldMiner/testPeriods 复用新的校验器，无需额外新接口；若平台按依赖打包函数，按该平台规则重新发布对应依赖入口。前端按 FRONTEND-API.md 接入 pending_unlock、任意档位领取和服务器返回的 productId。此次仓库改动不直接部署云端或修改前端代码。
|