ThinkPHP6.x会员体系：等级会员权益与成长值计算方案

在ThinkPHP 6.x框架中构建一套完整的会员体系，核心思路可归纳为五个方面：配置化、服务化、实时判定、解耦存储、多维限流。将这五个环节串联起来，才能设计出具备可扩展性和可落地性的会员体系。

以下分步骤详细说明具体实现方式。

一、会员等级与对应权益配置

等级本身通过level字段标记即可。关键在于将权益与等级绑定，并便于后期调整。推荐将所有等级对应的权益以键值对形式统一存储在配置文件或数据库中，避免在代码中硬编码。这样运营人员调整参数时无需修改任何代码。

1、在 config/member.php 中定义等级数组，每个等级包含 level、name、discount（折扣率）、max_upload_size（上传上限）、service_priority（客服优先级）等字段。字段命名应清晰明确，便于后续维护。

2、对于VIP3及以上等级，可开启 专属客服通道标识 is_vip_support = true。工单系统读取该字段后，将自动执行高优分发逻辑。该通道对提升用户体验尤为重要，尤其是在处理高客单价用户问题时。

3、权益数据建议缓存至Redis，键名使用 member:level:rules，TTL设置为24小时。配置变更后最多等待一天即可全局生效，无需每次修改都清空缓存。

二、成长值获取规则设计

成长值（growth_value）是决定用户能否升级的核心指标。增长与扣减规则需明确覆盖两类场景：用户主动行为和系统被动行为。所有加减操作必须通过统一的服务类执行，避免分散修改导致后期排查困难。

1、用户注册时直接赠送 100 点成长值。写入前需校验手机号是否唯一、验证码是否有效，防止恶意刷取。

2、每完成一笔实付金额 ≥ 10 元的订单，按 订单实付金额 × 10 计算成长值。订单金额不足10元的不计成长值。发生退款时，需等额扣减成长值——注意单笔扣减金额不得超过账户当前成长值余额，避免扣成负数。

3、每日首次登录奖励 5 点成长值。使用Redis的SETNX命令确保一天仅发放一次，key格式建议设为 member:growth:login:{uid}:{date}。该逻辑虽简单，但正确实现可有效减少无意义的数据库查询。

三、等级晋升与降级判定逻辑

等级变动不依赖定时任务扫描，而是在每次成长值变更后即时触发评估。这种方式的优势在于低延迟和低资源消耗。晋升与降级共用同一判定函数，仅阈值方向相反。

1、等级阈值表建议配置为：LV1（0）、LV2（300）、LV3（1200）、LV4（5000）。按升序排列并缓存，便于每次读取时保持稳定。

2、调用 MemberLevelService::checkLevelChange($uid, $new_growth) 方法，传入用户ID和更新后的成长值总和。该方法为整个判定逻辑的核心枢纽。

3、若新成长值 ≥ 下一级阈值，则执行晋升流程：更新level字段 → 写入等级变更日志 → 触发 member.level.upgraded 事件广播，通知积分模块同步发放等级礼包。三步操作缺一不可。

4、若成长值连续365天低于当前等级最低阈值的50%，则在次日零点自动降级。降级前需推送站内信通知用户，避免用户毫无准备。

四、成长值与等级解耦存储方案

该设计虽看似不起眼，但决定了后续能否支持运营活动，例如成长值清零重计、等级临时冻结等。核心原则是：等级字段仅反映当前有效状态，不与成长值耦合。

1、用户主表（member）中仅保留 level（当前等级）、growth_value（累计成长值） 两个整型字段。避免添加冗余字段，以免后续修改困难。

2、新增成长值明细表（member_growth_log），记录每次变动的 type（register/login/order/refund）、related_id（关联订单号或活动ID）、change_amount（变动值）、created_at。该表是审计退款、排查刷量问题的关键工具。

3、前端展示等级信息时，不要直接使用level数值进行硬编码渲染。应通过 MemberLevelService::getCurrentLevelInfo($uid) 获取包含 name、icon、next_level_need 等完整信息的数组。等级名称、图标、下一个等级所需成长值均可动态调整。

五、多维度成长值叠加控制

在营销活动高频发放成长值的场景下，需要限制单日、单活动、单用户维度的获取上限。若无此限流设计，一场活动可能让少数老账户刷出大量成长值。所有发放入口必须强制走限流网关，未授权调用直接拒绝。

1、活动配置中设置 daily_cap（单日上限）、total_cap（活动总上限）、per_user_cap（每人上限）。创建时写入 activity:growth:config:{aid} 缓存，便于后续快速读取。

2、发放前先在Redis中查询 activity:growth:used:{aid}:{uid} 当前值是否已达 per_user_cap。若已满，直接返回错误码 GROWTH_LIMIT_EXCEEDED，不提供额外说明。

3、成功发放后，使用INCR原子指令更新三个维度的计数器：用户计数器、活动全局计数器、日期分区计数器（key包含Ymd）。三个计数器均命中后，才写入明细表。若任一检查不通过，则不写入数据，避免产生脏数据。