商城产品 · 积分体系
整合积分抽奖与积分兑换，贯通参与资格、积分扣减、库存、支付、履约与售后的一体化业务闭环
01 / BACKGROUND
积分商城同时承载“积分抽奖”和“积分兑换”两类业务。二者虽然都以积分作为核心资产，但业务规则并不相同：抽奖强调活动周期、参与资格、总次数与每日次数、中奖概率与奖品库存、中奖后的地址和运费处理；兑换则进一步涉及商品限购、积分与现金组合支付、运费、库存锁定、订单履约和售后退款。如果仅按页面功能拆分需求，而没有统一积分、库存、支付、订单和状态口径，就容易在并发请求、支付失败、退款、重复点击或后台人工操作时出现积分重复扣减、库存超扣、金额错误、订单状态无法追溯等问题。因此该项目的核心并不是简单新增一个商城入口，而是建立一套能够支撑用户参与、后台运营、履约和售后的完整业务闭环。
02 / MY ROLE
梳理积分商城首页、抽奖活动列表与详情、参与确认、抽奖结果、中奖记录、兑换商品列表与详情、订单确认、地址选择、支付、订单查询及售后等用户端流程；定义活动未开始、进行中、已结束、停用、奖品抽完等展示状态，以及兑换商品的积分、现金、运费、库存和限购规则；设计总参与次数、每日参与次数、积分余额、用户资格、商品限购和库存等校验逻辑；明确中奖后在规定期限内填写地址并完成运费处理，待支付支持重试，超时后自动失效；明确积分兑换支持“积分+现金+运费”的组合支付模式，其中现金或运费均允许为0，用户端商品列表不展示运费，订单确认与详情中单独展示运费并统一金额合计口径；同步设计管理端活动配置、奖品配置、兑换商品规则、参与限制、抽奖记录、兑换订单、物流发货、退款处理和数据导出能力；针对积分不足、参与次数不足、限购、库存不足、重复请求、支付失败、退款失败、导出失败、状态重复提交等场景补充异常与测试规则，并参与交互评审、联调和上线验收。
03 / CORE PROBLEMS
第一，抽奖与兑换共用积分资产，但参与条件、库存扣减方式、订单结构和履约链路不同，需要在统一积分体系下保持业务边界清晰；第二，抽奖侧同时存在活动时间、总参与次数、每日参与次数、积分余额和奖品库存等多重校验，兑换侧则叠加限购、现金、运费和商品库存；第三，用户端列表、详情、订单确认、订单详情和管理端必须使用一致的积分、现金、运费及合计口径，避免前后台认知不一致；第四，中奖记录和兑换订单都会经历待处理、待支付、待发货、已发货、已退款、已失效等状态，需要明确状态流转条件并保留完整操作记录；第五，积分、库存、现金支付和退款必须保证一致性，尤其要防止重复请求导致重复扣积分、重复发奖、重复创建订单或重复退款；第六，后台批量或人工操作要能够处理成功、失败、部分失败和异常补偿，避免单点异常影响整批数据。
04 / SOLUTION
以“积分商城入口—抽奖/兑换分支—资格与库存校验—记录或订单生成—支付与履约—后台处理—售后追踪”为统一主线设计。抽奖业务先校验活动状态、参与资格、总次数、每日次数、积分余额和奖品库存，成功后生成唯一抽奖记录，并根据结果进入未中奖或中奖履约流程；中奖后根据是否需要运费进入待处理或待支付状态，支付失败可重试，超过规定期限未完成则自动失效。兑换业务按商品状态、限购、积分余额、现金金额、运费和库存进行校验，生成包含积分、现金、运费明细的兑换订单。用户端与管理端共用统一状态定义和金额口径；所有积分扣减、库存变化、订单创建、支付确认与退款等关键写操作均要求具备幂等能力，并通过事务或补偿机制保证失败时能够回滚相关数据。退款时同步处理积分、现金、运费、库存和订单状态，确保用户看到的结果、后台运营操作和底层数据记录保持一致。
05 / PROCESS & RULES
用户进入积分商城，根据需求选择积分抽奖或积分兑换
抽奖活动根据启停状态、活动时间与库存展示未开始、进行中、已结束、奖品抽完等状态
发起抽奖前统一校验活动状态、参与资格、总参与次数、每日参与次数、积分余额与奖品库存
抽奖请求通过幂等控制避免重复点击或重试造成重复扣积分、重复开奖，并为每次有效抽奖生成唯一记录
抽奖结果进入未中奖或中奖履约流程；中奖用户在规定期限内选择地址并完成必要的运费处理，支付失败可重试，逾期自动失效
积分兑换前统一校验商品状态、用户限购、积分余额、现金金额、运费与商品库存
兑换成功后生成订单，分别记录积分、现金、运费及最终应付金额，现金或运费允许为0
商品列表不展示运费，订单确认与详情中单独展示运费，并确保用户端与管理端金额口径一致
管理端统一维护抽奖活动、奖品、参与限制、兑换商品与兑换规则
管理端查询抽奖记录与兑换订单，并处理发货、物流、退款和数据导出
退款或异常结束时同步处理积分、现金、运费、库存及订单状态，避免部分退款或前后台状态不一致
关键操作保留完整状态与操作记录，并通过事务、幂等与异常补偿机制降低重复扣积分、库存超扣、重复下单和重复退款风险
06 / RESULT & REVIEW
最终形成一套覆盖积分抽奖、积分兑换、用户端、管理端、订单履约与售后的完整产品方案。方案统一了积分、次数、限购、库存、现金、运费、支付、物流、退款及失效等关键业务口径，并对正常流程与异常流程进行系统化梳理。开发可以依据明确的状态与数据规则实现核心逻辑，测试也能够围绕积分扣减、库存变化、组合支付、重复请求、支付失败、退款和状态流转建立完整用例。相比单纯按页面堆叠功能，该方案更强调业务一致性和可追溯性，重点降低重复请求、库存超扣、金额不一致、退款不完整及前后台状态不同步等高风险问题。
复盘这个项目让我进一步确认：积分商城的难点并不在页面数量，而在于多个资产和状态之间的联动。积分、库存、现金、运费、订单和履约一旦进入同一条链路，任何一步失败都可能影响其他数据。因此产品设计不能只描述“用户点击后看到什么”，还要明确每一次操作发生了哪些数据变化、失败后如何恢复、重复请求如何处理、状态如何追踪。对于类似涉及积分、库存、支付和售后的复杂业务，状态机、幂等、事务边界、异常补偿和操作记录应在需求阶段提前定义，这样才能让用户体验、后台运营和技术实现真正形成闭环。