企业官网建设流程全解析

用户等级功能，光听名字感觉没那么复杂——无非就是用户表里加个 level 字段，再按条件更新一下。但你真在线上跑起来就会发现，等级只是浮在水面上的冰山一角，底下连着成长值怎么算、流水怎么记、升级降级怎么触发、权益怎么发怎么收，还有并发、幂等、性能这些老朋友。我最近刚好把一个用户等级功能从零做完推上线，前后改了四版设计，踩了挺多坑，这篇就把最终方案和踩坑过程完整复盘一遍，给准备做同样功能的人一个参考。

整篇会从等级体系设计、数据模型、核心实现、权益发放、生产环境排障、运营化扩展六个方面展开，不涉及具体业务账号数据，只讲通用的设计思路和可复用的代码逻辑，适合后端开发、全栈工程师以及需要评审技术方案的产品负责人阅读。

1. 先把等级体系想清楚：成长值口径是地基

很多团队做用户等级功能，第一步就掉进“定几个等级、起什么名字”的细节里，吵了好几轮，结果最重要的成长值口径反而没人拍板。等级只是一个壳，壳里面装的是成长值。成长值怎么来、往哪里去、会不会被消耗、是不是只增不减，这些规则直接决定整个体系的合理性和可维护性。

1.1 等级只升不降，还是动态升降

我见过最简单的做法是给用户表加一个“累计积分”字段，积分够了就升一级，永远不会掉。这种模式我把它叫“累计制”。它的优点是用户安全感很强，等级是攒出来的，一旦升上去就是自己的，心理负担小；缺点是老用户升到顶之后没有任何持续激励，后面你做活动、做签到，他都觉得无所谓，因为等级已经满了。

另一类是“周期制”，按最近 30 天或 90 天的活跃数据评定等级，周期结束重新结算，活跃度不够就降级。电商平台和 OTA 平台用得最多。这类模式对持续活跃的驱动力非常强，但用户压力也大，一不小心就会因为短期不活跃被打回原形，引发客诉。

还有一类是“混合制”，累计门槛决定你最高能到什么等级，周期保级决定你能不能留在这个等级。这是多数中大型平台的最终形态，但也是实现复杂度最高的。

我自己的选型建议很简单：如果你第一次做用户体系，先做累计制。原因非常现实：累计制逻辑简单、不误伤用户、不需要做降级保护期，也不牵扯周期结算任务，团队可以快速上线拿到数据。等运营确实提出了“用户不活跃但等级高、权益成本扛不住”的问题，再叠加周期保级也不迟。

1.2 成长值的来源口径：哪几类行为算数

成长值来源是等级体系里最容易拍脑袋的部分。常见来源大致有四类：

• 交易类：实付金额，通常按比例换算成成长值，比如 1 元 = 1 成长值。
• 内容互动类：发帖、评论、点赞、被点赞、被收藏，按次数计分。
• 活跃签到类：每日签到、连续签到奖励、完成任务。
• 邀请类：邀请新用户注册并完成首单。

这里有一个非常容易踩的坑：交易类一定要用“实付金额”，不要用“下单金额”，否则退款和刷单会让你的成长值变成注水数据。我见过一个团队用下单金额算成长值，被羊毛党用“下单即退”刷了几十万分，最后全部用户等级重算，客服被打爆。

另外，成长值单位从一开始就要统一。不要一会儿用“分”，一会儿用“元”，把账算清楚最好的方式是大一统：成长值内部永远用整数，变化粒度最小是 1，转换比例全部由上层业务配置。这样做的好处是流水表、状态表、对账任务全部按同一单位处理，不会出现小数误差。

还有一个经验教训：成长值来源宁可一开始只接一两个高价值行为，也不要贪多。来源越多，账越难算，防刷点越多，运营规则越复杂。首版最好只接交易和签到，等稳定性验证完，再开放内容互动和邀请。

1.3 阈值怎么定：等级配置表而不是写死在代码里

等级阈值最忌讳写在代码里，比如 if (growth > 10000) return 5。因为阈值一定会被运营调整，每次调整都要发版，非常被动。

正确做法是一张等级配置表，用最小成长值和最大成长值来界定等级区间。下面是我常用的配置示例：

用 min_growth 和 max_growth 而不是直接存一个“升级到下一级需要的成长值”，好处是区间天然支持扩展。最高等级 max_growth 设为 NULL，表示上不封顶。运营后台调整区间后，只需要触发一次全量等级重算，不需要改任何业务代码。

等级数量我也提一个个人观点：5 到 8 级是最舒服的。少了没有梯度感，多了用户记不住，运营要维护的权益和每级成本核算也会指数级膨胀。等级名字虽然看起来只是文案，但会影响用户感知，钻石、王者这种已经被游戏玩烂的词要慎用，最好结合自己产品的调性来起名。

2. 数据模型设计：三张表撑起整个等级体系

等级体系的数据模型，一定要从一开始就把“账本”和“状态”分开。用户等级可不是用户表里一个字段那么简单的，成长值流水必须单独建表，这是整个体系安全的根基。我最终落地的方案是三张表：等级配置表、成长值流水表、用户等级状态表。

2.1 等级配置表

等级配置表负责存储所有等级定义和权益配置，结构如下：

CREATE TABLE `user_level_config` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `level` smallint(6) unsigned NOT NULL COMMENT '等级值，从1开始', `level_name` varchar(32) NOT NULL COMMENT '等级名称', `min_growth` bigint(20) unsigned NOT NULL DEFAULT '0' COMMENT '达到该等级所需最小成长值', `max_growth` bigint(20) unsigned DEFAULT NULL COMMENT '该等级成长值上限，NULL表示最高级', `benefits` json DEFAULT NULL COMMENT '权益配置，JSON格式存储', `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_level` (`level`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户等级配置表';

这里唯一键是 level，因为我们内部按等级值定位。benefits 字段我用 JSON 存储，因为等级权益的种类和数量都在变，每次上线都可能增加新权益类型，比如头衔、折扣、专属客服、生日礼包，如果每个权益都建一个字段，表结构会越来越臃肿，完全没有必要。

当然 JSON 字段有一个缺点，就是不能对里面的某个字段建索引。如果你后续要按权益类型统计用户覆盖量，建议另外建一张 user_level_benefit 表，把权益拆成正则化的行。但首版用 JSON 足够，简单灵活。

2.2 成长值流水表

成长值流水表是整个等级体系的“账本”，所有成长值变动都必须落这一张表。它的关键点在于：只要有来源就写流水，流水越完整，对账、防刷、追溯就越轻松。

CREATE TABLE `user_growth_log` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `user_id` bigint(20) unsigned NOT NULL COMMENT '用户ID', `change_type` tinyint(4) NOT NULL COMMENT '成长值类型：1签到 2消费 3内容 4活动 5补偿', `change_value` int(11) NOT NULL COMMENT '本次成长值变动，正数增加，负数扣减', `balance_after` bigint(20) NOT NULL COMMENT '本次变动后的成长值总额，冗余存储便于对账', `source_id` varchar(64) NOT NULL COMMENT '业务来源ID，用于幂等去重，如订单号', `remark` varchar(128) DEFAULT NULL COMMENT '备注，如订单号关联信息', `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_source` (`source_id`), KEY `idx_user_created` (`user_id`, `created_at`), KEY `idx_created` (`created_at`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户成长值流水表';

source_id 这一列是重中之重。签到记录有签到记录 ID，订单有订单号，只要你的业务事件有唯一 ID，就一定要把它填到 source_id 上，然后建唯一索引。这个唯一索引的作用是幂等兜底：就算消息队列重复投递、接口被重复调用，第二次插入会因为违反唯一约束被数据库拒绝，成长值绝对不会翻倍。

balance_after 这个冗余字段也很重要，它记录了本次变动后的余额，对账的时候不用回放全部流水，只需要校验最新余额和流水累加值是否一致。

2.3 用户等级状态表

用户等级状态表是一个“当前快照”，专门服务高频查询。它的核心思路和缓存一样：真实数据源是流水表，但每次查等级都去累加流水肯定不行，所以需要一张状态表冗余当下的成长值和等级。

CREATE TABLE `user_level_info` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `user_id` bigint(20) unsigned NOT NULL, `level` smallint(6) unsigned NOT NULL DEFAULT '1' COMMENT '当前等级', `growth_value` bigint(20) unsigned NOT NULL DEFAULT '0' COMMENT '当前成长值', `downgrade_grace_start` datetime DEFAULT NULL COMMENT '降级保护开始时间，保护期内不降级', `demoted_at` datetime DEFAULT NULL COMMENT '最近一次降级时间，用于控制降级频率', `last_growth_at` datetime DEFAULT NULL COMMENT '最近一次成长值变化时间', `updated_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_user_id` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户等级状态表';

我这里带上了降级保护相关字段，就算首版用累计制用不上，也建议提前留着。因为后期一旦改周期制，降级保护几乎是必须的。downgrade_grace_start 记录保护期开始时间，demoted_at 记录最近一次降级时间，用于限制降级频率，避免用户刚降级又马上因为小波动再次降级。

三张表之间的关系可以这样理解：流水表是账本，状态表是余额快照，配置表是规则字典。所有写入必须保证“先记流水，再更状态”，状态和流水在同一事务内完成，后续的等级事件和权益发放则靠异步解耦。

3. 成长值计算与等级更新的执行路径

数据模型搭完之后，核心就是成长值如何发放、等级如何计算与变更。这一章我直接给出代码骨架，并解释每个设计决策背后的原因。

3.1 入口抽象：对外只暴露一个发成长值的接口

不管来源是签到、订单还是内容互动，内部只保留一个发放入口，统一处理幂等、流水、余额、等级变更：

@Service public class GrowthService { @Transactional public GrowthResult grant(GrowthGrantRequest req) { // 1. 幂等判断：先尝试插入流水，source_id 已存在则说明是重复事件 int inserted = 0; try { inserted = growthLogMapper.insertIgnore(req.toLog()); } catch (DuplicateKeyException e) { return GrowthResult.duplicated(); } // 2. 行锁锁定用户等级状态，防止并发更新覆盖 UserLevelInfo info = userLevelInfoMapper.lockByUserId(req.getUserId()); // 3. 计算新余额 long newBalance = info.getGrowthValue() + req.getChangeValue(); if (newBalance < 0) { throw new IllegalStateException("成长值余额不足"); } // 4. 根据新余额计算新等级 int newLevel = levelConfigService.findLevelByGrowth(newBalance); // 5. 更新状态表 info.setGrowthValue(newBalance); info.setLevel(newLevel); info.setLastGrowthAt(new Date()); userLevelInfoMapper.update(info); return GrowthResult.success(newLevel, newBalance); } }

这个接口有几个细节值得展开。

第一步为什么用 insertIgnore 而不是先查再插？因为查再插在高并发下还是有窗口期，两条相同的 source_id 同时进来，都查到不存在，然后都插入，就重复了。直接用数据库唯一索引兜底，是最简单可靠的做法。捕获到 DuplicateKeyException 就说明是重复事件，直接返回，什么都不改。

第二步为什么要锁行？因为状态表更新是读改写三步，如果两个不同请求同时读到 growth_value=990，各自加 10，最后都写回 1000，但正确结果应该是 1020。这是经典的 lost update。用SELECT ... FOR UPDATE或者UPDATE ... SET growth_value = growth_value + ${delta}可以避免。我选择锁行是因为后面还要根据新余额查等级，需要拿到完整的新状态。

第 4 步 findLevelByGrowth 是一个纯函数，输入余额，输出等级，不涉及任何外部状态，所以非常容易测试和复用。

3.2 等级计算的二分查找

等级配置按 min_growth 升序存放，最直观的算法是遍历，但等级配置多了之后，每次遍历也是浪费。用二分查找更优雅：

public int findLevelByGrowth(long growth) { List<LevelConfig> list = levelConfigList; // 按 min_growth 升序 int left = 0, right = list.size() - 1; int ans = 1; while (left <= right) { int mid = (left + right) >>> 1; if (list.get(mid).getMinGrowth() <= growth) { ans = list.get(mid).getLevel(); left = mid + 1; } else { right = mid - 1; } } return ans; }

这段逻辑本质上是在找最后一个 min_growth 小于等于当前余额的等级。边界情况要特别注意：growth=0 时返回 level=1，growth 非常大时返回最高等级。由于配置表是后台维护，量级通常只有十行左右，二分查找的收益其实不大，但这个函数本身是纯的，写对之后几乎不用改，所以值得多花一点心思。

3.3 升级与降级事件：等级变化不能只改字段

等级变化会牵动权益、消息推送、甚至用户身份标识的变化，所以不能只改状态表字段。一定要发事件，让下游系统各自处理。

我定义了一个 LevelChangedEvent：

{ "eventType": "LEVEL_UP", "userId": 10001, "oldLevel": 2, "newLevel": 3, "growthValue": 6200, "eventId": "b3f2a1c0-89d1-4e7a-9f0c-2d0b45a6f8e1", "ts": 1699999999999 }

eventType 只有两种：LEVEL_UP 和 LEVEL_DOWN。这里要强调一个容易被忽略的点：事件里必须同时带 oldLevel 和 newLevel，因为消费者要判断是升级还是降级。如果只带 newLevel，消费端根本不知道用户变化方向。

事件通过 MQ 异步发出去，权益服务、消息服务、数据仓库各取所需。为什么不把等级变更和权益发放放在同一个事务里？因为权益发放往往要调用外部服务，比如券系统、短信服务，这些服务的成功率和数据库事务不在一个边界内。事务里调外部服务是最容易拖垮数据库的操作，坚决不要做。正确的姿势是本地事务只负责改状态表，然后发 MQ，下游消费失败可以重试。

消费端必须做好幂等，按 eventId 去重。这不是可选项，是必选项。MQ 的重试机制加上消费端宕机，同一个事件被投递多次是常态。

3.4 定时任务与实时计算如何取舍

关于等级计算是实时好还是定时好，网上争议很多。我给出自己的经验结论：成长值发放必须实时，等级变更也建议实时，但实现上可以把压力从主链路拆出去。

首版可以这样做：

1. 成长值流水实时写，这是硬性要求，因为流水是真相源，失之毫厘谬以千里。
2. 状态表余额实时更新，用上面的行锁方案，成本很低。
3. 等级变更判断可以放到 MQ 消费者里异步执行。成长值写完后发一个 GrowthChanged 消息，消费者拿到用户最新余额后计算等级、更新状态、触发 LevelChangedEvent。延迟控制在秒级，用户基本无感知。

为什么不用每天定时任务统一算？因为延迟一天，用户就会觉得等级是僵尸数据，签到后看不到成长值上涨，体验很差。定时任务还有一个风险：如果当天任务跑挂，恢复后要追一大批数据，压力很大。实时更新反而把压力摊平了，单个用户更新成本微乎其微。

我在第三版设计里曾经尝试过先用消息异步再批量合并，后来发现多此一举。单条成长值更新在 MySQL 里就是一次带行锁的 update，压力完全可控。所以不要为了“优化”而优化，简简单单实时算才是正解。

4. 等级权益的配置、发放与回收

用户为什么在乎等级？因为等级能带来实际好处。权益设计的好坏，直接决定用户等级功能是“自嗨功能”还是“留存利器”。权益这一块，我单独建了一个发放记录表，把所有发放、回收轨迹都记录下来。

4.1 权益怎么配置：从静态字段到动态扩展

最简单的方式是在等级配置表的 benefits 字段里存 JSON，比如：

[ { "benefit_type": "discount", "config": { "rate": 0.9, "scene": "all" } }, { "benefit_type": "badge", "config": { "badge_id": 10001 } }, { "benefit_type": "permission", "config": { "permission": "unlock_long_video" } } ]

权益类型大致分成三类：

• 展示型权益：头衔、徽章、专属昵称色、等级图标。这类权益开发成本最低，前端换个样式就行，但对用户的心理激励很直接。
• 功能型权益：解锁某些功能权限，例如高等级用户才可以发长视频、上传大文件、使用专属客服入口。接入方需要在功能入口处校验等级。
• 价值型权益：折扣券、成长值加速倍数、每月福利。这类有真金白银的成本，财务核算一定要跟上。

权益系统的设计关键是要支持动态扩展。首版不要试图把所有权益做成通用规则引擎，那会陷入过度设计的泥潭。只需要定义好枚举、配置好 JSON，后续新增权益类型时扩展枚举和下发逻辑即可。

4.2 发放与回收的幂等设计

升级时发权益、降级时收权益，这个流程必须幂等，否则用户会拿到重复券，或者降级后权益没收回。

我设计了一张权益发放记录表：

CREATE TABLE `user_benefit_record` ( `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `user_id` bigint(20) unsigned NOT NULL, `benefit_type` varchar(32) NOT NULL, `event_id` varchar(64) NOT NULL COMMENT '触发事件ID，用于幂等', `status` tinyint NOT NULL DEFAULT '0' COMMENT '0待发放 1已发放 2已回收', `expire_at` datetime DEFAULT NULL, `created_at` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_event_benefit` (`event_id`, `benefit_type`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户权益发放记录表';

发放逻辑：

1. 消费 LevelChangedEvent。
2. 根据 event_id + benefit_type 尝试插入权益记录，如果唯一键冲突说明已经处理过，跳过。
3. 调用权益服务发放权益。
4. 发放成功，更新 status=1；失败则保持 status=0 等待重试。

回收逻辑与之类似，只是 status 改为 2。这里有个经验：回收权益不要立刻把用户已经领取的券作废，而是控制“未来的发放”。比如钻石会员每月送一张 50 元券，用户降级后，已领取但未使用的券可以继续用，但下个月不再发放。直接作废已领取的权益会引起强烈反弹，这一步极其容易被客服当典型投诉案例。

4.3 权益成本要提前算清楚

等级权益越往上，成本越高。钻石会员如果每人每月发 50 元券，那么一万个钻石就是每个月 50 万的成本。这个账一定要在等级阈值定稿前就算清楚，否则上线后财务找你对账，你会非常被动。

可以做一个简单的成本估算公式：

预估成本 = 每个权益的边际成本 × 该等级预期用户数

例如钻石会员：50 元券 × 1 万人 = 50 万元/月。如果这个数字超出运营预算，就要调整阈值、权益档位，或者改成“限量领取”的模式，控制总成本。上线后还要定期统计各等级权益的实际兑换率，用真实数据修正预估。

5. 生产环境血泪坑：并发、幂等、性能与数据一致性

这一章是整篇的干货所在。用户等级功能看似简单，一旦上生产，各种隐藏的坑都会冒出来。下面这些坑我全都踩过，而且每一种都能单独写一篇复盘。

5.1 并发更新覆盖：同一用户同时多端操作

真实场景：用户同一秒在 App 签到、在网页下单、在直播间发弹幕领到成长值，三个请求同时到达。如果状态表更新走的是“先查余额、内存计算、再写回”，就极容易互相覆盖。

排查过程是这样的：我的第一版实现用的是普通 select 再 update，上线第二天就发现对账异常，有用户成长值变少了。查日志发现两个请求读到的余额都是 990，各自加了 10，都写回 1000，正确的 1020 被丢了。

修复方案有两个方向：

一是原子更新，不再查后写：

UPDATE user_level_info SET growth_value = growth_value + #{delta} WHERE user_id = #{userId}

然后回查最新余额，再算等级更新 level。

二是行锁，也就是我在第三节代码里展示的SELECT ... FOR UPDATE。原子更新在简单场景下更高效，但如果后面还需要读完整的用户实体做判断，行锁更合适。我自己最终选的是行锁，因为等级判断逻辑往往不止余额一个条件，锁住整行后处理更统一。

如果你用消息队列做异步消费，还要注意同一个用户的多条成长值消息不能并发消费。最好按 user_id 做分区，保证同一个用户的消息串行处理。RocketMQ 支持 MessageQueueSelector，Kafka 可以用 key 保证分区，这些都是标准方案。

5.2 重复消息导致成长值翻倍

重复消息是最隐蔽的坑。测试环境消息量小，基本发现不了；一上生产，MQ 只要发生一次重平衡或消费者重启，就会有消息被重复投递。

我遇到过一次比较经典的事故：订单支付成功后，支付回调消息被 MQ 重投递了两次。当时流水表没有 source_id 唯一索引，消费代码里也没有幂等判断，结果同一笔订单给用户加了两笔成长值。用户反馈成长值不对，我们一查流水，发现同一订单号出现两行。这类问题的第一道防线永远是表结构唯一索引，而不是代码里的 if 判断。因为代码在并发窗口下可能出现两个线程同时判断“不存在”，然后同时插入。只有数据库约束才是严格可靠的。

这个坑我在 2.2 节里已经埋了伏笔：source_id 唯一索引是成长值流水表的灵魂。如果你的表已经上线了，赶紧加索引；如果还在设计阶段，请务必留好这一列。

5.3 查询性能：不要在用户信息接口里算等级

有些人图省事，用户信息接口里每次现算等级：

SELECT level FROM user_level_config WHERE min_growth <= #{growth} ORDER BY min_growth DESC LIMIT 1

等级配置只有五六行的时候，这个查询确实没问题。但问题是这个接口通常会被用户信息页、列表页、评论区高频调用，一旦并发上来，每次都查一次就是浪费。而且如果配置表数据被运营改成几十个等级，查询成本还会增加。

正确做法是状态表直接存 level，查询只走 user_level_info 表。为了进一步降低数据库压力，可以加一层 Redis 缓存：

key: user_level_info:{userId} value: { level, growthValue } 过期时间: 一个合理的时间窗口，比如 30 分钟

缓存 miss 时回源 DB，如果 DB 也没有记录，就初始化一个默认等级 1 的状态写入缓存。更新等级时不要只删缓存，而是先更新 DB，再主动刷新缓存。这比 delete 缓存更稳，可以防止并发下缓存穿透，也避免删缓存和写库之间的时间窗口内出现不一致。

5.4 流水与状态不一致：对账与补偿

流水表和状态表分开存储后，最怕的就是两边数据对不上。如果不做对账，问题可能会潜伏几周甚至几个月，直到用户投诉或者财务核对时才暴露。

对账任务建议每天凌晨跑一次，比对状态表的 growth_value 和流水表按用户聚合的 sum。核心 SQL 类似：

SELECT l.user_id, l.growth_value AS state_growth, COALESCE(SUM(g.change_value), 0) AS log_growth FROM user_level_info l LEFT JOIN user_growth_log g ON g.user_id = l.user_id GROUP BY l.user_id, l.growth_value HAVING state_growth != log_growth LIMIT 100;

注意，这张 SQL 在数据量大的时候会非常慢，所以对账任务不要直接在生产库跑，应该把数据同步到分析库或者离线数仓，在那边对账。首版用户量小的话可以直接跑，但用户量过百万后就要考虑迁移到数仓了。

发现不一致后如何补偿？原则是“以流水为真相源，重算状态”。具体做法是：找到不一致的用户，重新累加流水得到正确余额，再更新状态表的 growth_value 和 level。补偿一定要在低峰期执行，并且要记录操作日志，防止反向覆盖。

5.5 降级误伤核心用户

周期制等级体系最怕误伤核心用户。我见过一个年消费几十万的大客户，因为一个月没登录，等级从 V5 直接掉到 V4，当月专属权益失效，用户直接投诉到客服。

处理方案有三道防线：

第一道是降级保护期。到期前 30 天，系统要发预警通知，告诉用户“当前等级即将到期，还差多少成长值可以保级”。保护期内不执行降级，给用户缓冲时间。

第二道是白名单机制。核心用户、客服标记的高级用户，在等级模块加一个 is_exempt 标记，降级任务跳过这些用户。白名单可以由运营后台手动配置，也可以接入用户价值评分自动标记。

第三道是降级后的柔和处理。已领取的权益不立即作废，而是保留到有效期自然结束；下个月的周期性权益停止发放。这样用户虽然降级了，但不会感觉被“一刀切”，体验上会缓和很多。

6. 从能用走向好用：等级体系运营化扩展

一个用户等级功能上了线、跑通了流程，只是完成了 30% 的工作。真正让这个体系产生长期价值的，是后续的运营化扩展。

6.1 成长值和积分分开，别混为一谈

这是我见过最多团队犯的错误：把成长值和商城积分放在同一个字段里。用户兑换了商品，积分扣减了，结果等级也跟着掉了，体验极差。因为这两个东西的语义完全不同：成长值只反映等级，不可消耗，只增或周期重置；积分是可消耗资产，能兑换商品或抵扣现金。

正确做法是两套账本、两套流水、两套状态表。它们可以联动，比如消费积分可以获得成长值，但余额绝不能共用。我建议在设计阶段就把两个体系隔离，否则后期拆分会非常痛苦。

6.2 保级策略与荣誉体系

采用周期制后，保级策略是绝对必要的。我在 5.5 节已经讲了避免误伤用户的兜底方案，这里再补充一个运营侧的常见规则：

• 当前成长值达到待保等级阈值的 60% 以上，且上一周期也达到过该等级，可以保留原等级一个周期。
• 连续 N 个周期不活跃才降级，中间出现一次活跃就重置计数。

这两个规则结合起来，可以有效降低“因为一次偶然波动就降级”的概率。

荣誉体系是低成本高回报的功能。历史最高等级、升级时刻的分享卡片、等级勋章的收集墙，都能给用户提供额外的情感激励。我做过一个升级卡片，用户升到新等级时生成一张带有成长轨迹的分享图，朋友圈一发，当周新用户注册量涨了不少，属于性价比非常高的运营活动。

6.3 数据分析和效果评估

等级体系上线后，要持续观察几个核心指标：

• 等级分布曲线：如果 80% 的用户都集中在 V1，说明阈值定得太高，挫伤积极性；如果大家轻松到顶，说明阈值太低，没有成长感。
• 各等级权益兑换率：折扣券没人领、权限没人用，说明权益没有吸引力，或者用户根本不知道有这些权益。
• 升级前后用户行为差异：用户在升级后一周的活跃度、消费频次有没有明显提升？这是衡量等级激励效果的核心指标。
• 降级用户的留存率变化：降级后是否有明显的流失，如果流失严重，说明降级策略过于激进。

我的个人经验是：等级体系上线后的第一个月，不要盯着留存率提升多少，先盯着有没有因为降级、权益 bug 造成客诉。稳定比增长重要，用户体系一旦让用户“感觉被算计”，非常难挽回。等系统稳定一个季度，再去做阈值调优和权益加码。

6.4 阈值动态调整

阈值不是定了一次就永远不变的。运营会定期调整，但你调整时要注意三点：

第一，不要在跑批任务执行的中途修改配置，否则同一批用户可能用了两套规则。

第二，修改配置后要触发一次全量等级重算。注意，全量重算不能直接在生产库 UPDATE，应该先根据历史数据模拟一遍，看有多少用户会升降级，评估影响面后再执行。

第三，如果会影响大量用户降级，建议提前发站内信通知，给用户一个缓冲周期。突然降级引发投诉的案例太多了，上线前和客服团队同步好话术，会省很多事。

整个用户等级功能做完，我最深的体会是：真正花时间的不是写代码，而是把规则想清楚、把幂等和账务做好、把运营侧的权益成本算明白。等级只是一个展示给用户的名片，名片背后是一整套账务和风控逻辑。如果你正准备做这个功能，先从成长值口径和流水表设计开始，这两块地基打稳了，后面盖多少层楼都不会塌。