简介：这份商城积分系统资源面向Web开发初学者与课程设计、毕业设计人群，围绕会员积分获取、积分管理、积分兑换、会员等级特权等核心业务，提供一套可运行的完整实现参考。压缩包共93个文件，约2.31MB，以35个cs后端逻辑文件、13个aspx页面与12个ascx用户控件为主体，配合6个config配置、2个master母版页、1个sitemap站点地图及css样式与jpg界面素材，另含mdf与ldf数据库文件、一份PPT说明文档，覆盖从数据库设计到前后台页面的完整链路。已有3097人学习下载。读者可据此理解积分计算、有效期管理、商品兑换与库存校验、后台发放与统计等模块的组织方式，并参考其分层结构与页面划分，快速搭建自己的积分管理原型或在此基础上二次开发。

1. 商城积分系统：从“签到送分”到“积分当钱花”的完整闭环

很多商城项目做到一定阶段都会遇到同一个坎：用户下单之后除了收货，跟平台再没有第二次互动。运营想拉复购，只能靠发券，券发多了利润扛不住，发少了没人理。积分体系就是在这个节点被推上台面的——签到给分、下单返分、积分抵现、积分换购，一套组合拳把“一次性买家”变成“会回来看一眼的人”。这份商城积分系统源码要解决的就是这件事：它不是一个孤立的积分记录表，而是一套覆盖积分获取、账户管理、消费抵扣、过期清算的完整模块，能直接挂到现有商城后端上跑。适合正在做会员体系的后端开发、需要给电商项目加留存手段的团队，以及想拆一套真实业务模块练手的开发者。下面按“它是什么 → 怎么跑起来 → 核心代码怎么写的 → 怎么改”的顺序往下拆。

2. 技术栈与目录结构：一套能直接挂进商城的积分服务

2.1 技术选型与依赖关系

从项目定位看，这是一套典型的 Java 后端服务，常见做法是 Spring Boot + MyBatis-Plus + MySQL + Redis 的组合。选这套不是跟风，而是积分场景本身有几个硬需求：积分变动必须落库可追溯（MySQL 事务保证），高频的签到和余额查询要扛住并发（Redis 缓存账户余额），积分规则又要能配置化（数据库表驱动而非硬编码）。前端如果是管理后台，多半是 Vue + Element UI 那一套；如果是嵌在商城 H5 里，就是原生或轻量框架。项目正文没有给具体版本号，我按这个场景下最稳妥的搭配来理解：Spring Boot 2.7 系列、JDK 8 或 11、MySQL 5.7/8.0、Redis 5 以上，这套组合在多数公司的基础设施上都能直接落地，不会因为版本太新卡在部署环节。

依赖上除了 Spring Boot 全家桶，通常还会引入 MyBatis-Plus（省掉大量单表 CRUD）、Hutool（工具类）、Lombok（少写 getter/setter），如果涉及定时清算积分过期，还会用到 Spring 的@Scheduled或者 XXL-Job。这些依赖不是装饰，后面讲核心代码时会看到它们各自出现在哪。

2.2 目录结构逐层说明

一个能跑的积分系统，目录大致长这样（按分层架构组织，这是国内后端项目最通用的做法）：

mall-points/ ├── pom.xml ├── src/main/java/com/example/points/ │ ├── PointsApplication.java # 启动类 │ ├── controller/ # 对外接口层 │ │ ├── PointsAccountController.java │ │ ├── PointsRuleController.java │ │ └── PointsRecordController.java │ ├── service/ # 业务逻辑层 │ │ ├── PointsAccountService.java │ │ ├── PointsRuleService.java │ │ └── impl/ │ ├── mapper/ # 数据访问层 │ ├── entity/ # 数据库实体 │ ├── dto/ # 请求/响应对象 │ ├── config/ # 配置类（Redis、拦截器等） │ └── task/ # 定时任务（积分过期清算） └── src/main/resources/ ├── application.yml ├── mapper/ # MyBatis XML └── sql/init.sql # 建表脚本

这个结构的关键在于controller / service / mapper三层职责清晰：controller 只做参数校验和响应封装，service 承载积分增减的全部业务规则，mapper 只管 SQL。二次开发时最常改的是 service 层和sql/init.sql，前者改规则，后者加字段。task目录单独放定时任务，是因为积分过期清算这类逻辑不该混在用户请求链路里，跑批和在线请求要隔离，否则一次全表扫描能把接口拖慢。

2.3 核心数据表设计

积分系统的表不多，但每张都承担明确职责。常见做法是四张核心表：

points_account里把总积分、可用积分、冻结积分分开存，是为了处理“下单时先冻结、支付成功才扣减、取消订单要回滚”这种场景。如果只存一个余额字段，并发下很容易出现超扣。points_record的biz_no是业务单号，用来做幂等——同一笔订单重复回调时，靠它判断流水是否已存在，这是积分系统里最容易翻车的地方之一，后面避坑章节会细说。

3. 本地跑通：从建库到第一个积分接口返回

3.1 环境准备与建库脚本

先把 MySQL 和 Redis 起起来，这是硬前提。建库脚本在src/main/resources/sql/init.sql，执行方式很直接：

# 登录 MySQL 后执行 mysql -u root -p CREATE DATABASE mall_points DEFAULT CHARACTER SET utf8mb4; USE mall_points; SOURCE /path/to/init.sql;

utf8mb4不能省，积分规则名称、商品名里带表情符号或生僻字时，utf8会直接报错。建完表后检查一下points_account的user_id有没有唯一索引——没有的话并发签到会给同一用户建出多条账户记录，这是血泪经验，建表时就得加上。

Redis 这边只需要一个可用的库，配置里默认连127.0.0.1:6379，没有密码。如果你的环境有密码，改application.yml里的spring.redis.password即可。

3.2 配置文件与启动

application.yml里要改的其实就三处：数据库连接、Redis 连接、服务端口。其余保持默认就能跑：

server: port: 8080 spring: datasource: url: jdbc:mysql://127.0.0.1:3306/mall_points?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: your_password redis: host: 127.0.0.1 port: 6379

serverTimezone=Asia/Shanghai这个参数别漏，漏了之后积分流水的创建时间会差 8 小时，排查问题时看着时间对不上会怀疑人生。配置改完，在项目根目录执行mvn spring-boot:run，看到Started PointsApplication就说明起来了。第一次启动如果报 mapper 找不到，检查@MapperScan注解的包路径是否覆盖了mapper目录。

3.3 用接口验证积分链路

服务起来后，先用签到接口验证整条链路通不通：

# 用户签到，预期返回本次获得积分和当前余额 curl -X POST http://localhost:8080/api/points/sign \ -H "Content-Type: application/json" \ -d '{"userId": 1001}'

正常返回类似{"code":0,"data":{"gainPoints":10,"availablePoints":10}}。如果返回积分规则未配置，去points_rule表插一条rule_code='SIGN_IN'的记录；如果返回账户不存在，说明签到逻辑里没有做“账户不存在则初始化”的处理，这属于业务代码要补的分支。再调一次查询余额接口GET /api/points/account?userId=1001，确认 Redis 和 MySQL 的数据一致。这两步走通，说明数据库、缓存、业务逻辑三层都接上了，后面改代码心里有底。

4. 核心模块拆解：积分增减、幂等与过期清算怎么写的

4.1 积分账户服务：增减积分的事务与并发控制

积分变动是整个系统的心脏，写法上必须同时解决两个问题：事务一致性和并发安全。先看核心方法：

@Service public class PointsAccountServiceImpl implements PointsAccountService { @Autowired private PointsAccountMapper accountMapper; @Autowired private PointsRecordMapper recordMapper; @Override @Transactional(rollbackFor = Exception.class) public void changePoints(Long userId, String changeType, Integer points, String bizNo) { // 1. 幂等校验：同一业务单号只处理一次 int exist = recordMapper.countByBizNo(bizNo); if (exist > 0) { return; } // 2. 行锁更新账户，避免并发超扣 PointsAccount account = accountMapper.selectForUpdate(userId); if (account == null) { accountMapper.initAccount(userId); account = accountMapper.selectForUpdate(userId); } int newAvailable = account.getAvailablePoints() + points; if (newAvailable < 0) { throw new BizException("积分不足"); } accountMapper.updateAvailable(userId, newAvailable); // 3. 写流水，bizNo 唯一索引兜底 recordMapper.insert(buildRecord(userId, changeType, points, bizNo)); } }

逐段说：@Transactional保证账户更新和流水写入同生共死，rollbackFor = Exception.class是为了让受检异常也回滚，默认只回滚运行时异常，这个坑踩过的人不少。幂等校验放在最前面，靠biz_no查流水，重复请求直接返回，不重复加分。selectForUpdate是SELECT ... FOR UPDATE的行锁，把同一用户的并发请求串行化，这是防超扣最直接的手段；代价是并发量集中在单个用户时会排队，但积分场景下单用户并发本来就低，这个取舍合理。最后newAvailable < 0的判断是业务兜底，防止扣成负数。参数changeType建议用枚举值（SIGN_IN、ORDER_REWARD、EXCHANGE_DEDUCT），别用中文，后面统计和对账会感谢这个决定。

4.2 积分规则引擎：配置化而非硬编码

规则如果写死在代码里，运营每改一次签到分值就得发一次版，这不现实。项目里用points_rule表驱动，service 按rule_code查规则再算分：

public int calculatePoints(String ruleCode, BigDecimal orderAmount) { PointsRule rule = ruleMapper.selectByCode(ruleCode); if (rule == null || rule.getStatus() == 0) { return 0; } // 固定分值规则，如签到 if ("FIXED".equals(rule.getCalcType())) { return rule.getPointsValue(); } // 按金额比例规则，如消费返积分 if ("RATIO".equals(rule.getCalcType())) { return orderAmount.multiply(rule.getRatio()).setScale(0, RoundingMode.DOWN).intValue(); } return 0; }

calcType区分固定值和比例两种计算方式，ratio存的是返分比例（比如 0.01 表示消费 1 元返 1 分）。RoundingMode.DOWN是向下取整，宁可少给不可多给，避免出现 0.99 元返 1 分这种被薅的情况。规则表加status字段是为了支持停用而不删除，历史流水还要靠规则 code 回溯。二次开发时想加“阶梯返分”，在这里扩一个calcType='LADDER'分支即可，不用动调用方。

4.3 积分过期清算：定时任务与分批处理

积分不能无限累积，否则平台负债越滚越大。过期清算放在task目录，用定时任务扫流水：

@Component public class PointsExpireTask { @Autowired private PointsRecordMapper recordMapper; @Autowired private PointsAccountService accountService; // 每天凌晨 2 点执行 @Scheduled(cron = "0 0 2 * * ?") public void expirePoints() { // 分批查过期未清算的流水，每批 500 条 int pageSize = 500; int offset = 0; while (true) { List<PointsRecord> list = recordMapper.selectExpired(offset, pageSize); if (list.isEmpty()) { break; } for (PointsRecord r : list) { accountService.changePoints(r.getUserId(), "EXPIRE", -r.getRemainPoints(), "EXP_" + r.getId()); } offset += pageSize; } } }

分批查而不是一次select *，是因为流水表会越来越大，全量加载进内存迟早 OOM。每批 500 条是经验值，太小数据库往返多，太大单次事务时间长。bizNo拼上流水 id 保证每笔过期只扣一次，即使任务重跑也不会重复扣。cron表达式放在凌晨 2 点，避开业务高峰。这里有个注意点：过期扣减走的是同一个changePoints方法，所以行锁和幂等逻辑自动复用，不用另写一套，这是把核心方法设计成通用入口的好处。

5. 避坑与排查：积分系统上线后最容易翻车的五件事

5.1 重复回调导致积分翻倍

现象：用户支付成功后积分加了两次，对账时发现流水重复。原因：支付平台回调可能重试，接口没做幂等。解决：points_record的biz_no建唯一索引，插入冲突时捕获异常直接返回成功，让回调方停止重试。光靠代码里countByBizNo查询不够，并发下两个请求可能同时查到 0，唯一索引才是最后一道防线。

5.2 缓存与数据库余额不一致

现象：用户查余额显示 100，实际扣减时提示积分不足。原因：余额缓存在 Redis，扣减走 MySQL，两边更新时序错乱。解决：扣减以数据库为准，Redis 只做读缓存，每次变动后删除缓存而非更新缓存（Cache Aside 模式），下次读时回填。别在事务提交前删缓存，否则并发读会把旧值又写回去。

5.3 积分扣成负数

现象：并发兑换时账户余额变成 -50。原因：先查余额再更新，中间没有锁。解决：用UPDATE points_account SET available_points = available_points - #{points} WHERE user_id = #{userId} AND available_points >= #{points}，靠 SQL 的原子性和 where 条件兜底，影响行数为 0 就说明余额不足。这比先查后改可靠得多。

5.4 定时任务重复执行

现象：过期清算跑了两遍，用户积分被扣两次。原因：多实例部署时每个节点都触发了@Scheduled。解决：要么用分布式锁（Redissetnx）保证同一时刻只有一个节点执行，要么把定时任务迁到 XXL-Job 这类调度中心统一触发。单机开发时看不出问题，一上集群就暴露。

5.5 时间字段时区错乱

现象：流水创建时间比实际早 8 小时，过期判断提前触发。原因：JDBC 连接没指定serverTimezone，或服务器时区是 UTC。解决：连接串加serverTimezone=Asia/Shanghai，JVM 启动参数加-Duser.timezone=Asia/Shanghai，两处都对齐。这个坑排查起来最费劲，因为数据看着“没错”，只是时间偏了。

6. 二次开发：把积分体系改成适合自己业务的形状

拿到这套代码，多数人不会原样用，而是按自己商城的玩法改。改之前先想清楚一件事：积分对你来说是成本还是杠杆。如果是成本，重点在过期和上限控制；如果是杠杆，重点在获取场景的丰富度。下面几个改造方向按投入产出排了序。

第一个改规则表。加“首单返双倍”“评价返分”“邀请好友返分”这类场景，只需要在points_rule插记录、在对应业务节点调calculatePoints，不用动核心逻辑。我一般会先加一个rule_code枚举类，把字符串常量收口，避免各处拼错。

第二个改账户模型。如果要做积分等级（不同等级返分比例不同），在points_account加level字段，calculatePoints里按等级查不同 ratio。注意等级变更时不要重算历史流水，只影响后续获取，否则对账会乱。

第三个改过期策略。现在是按流水逐笔过期，如果业务要求“先进先出、先获得的先过期”，需要在流水表加remain_points字段记录每笔剩余，扣减时优先扣最早未过期的。这个改动量不小，但逻辑更贴近真实财务口径。

验证改造是否正确的办法很朴素：写一个对账脚本，把points_record按用户汇总，和points_account.available_points比对，差值不为 0 就是有 bug。我习惯在每次改完积分逻辑后跑一遍这个脚本，比看日志快得多。

-- 对账 SQL：流水汇总应等于账户可用积分 SELECT r.user_id, SUM(r.change_points) AS record_sum, a.available_points FROM points_record r JOIN points_account a ON r.user_id = a.user_id GROUP BY r.user_id, a.available_points HAVING record_sum <> a.available_points;

这条 SQL 返回空才算干净。有段时间我图省事跳过了对账，结果上线三天后运营发现某批用户积分对不上，回头查流水查了一下午，从那以后每次动积分相关代码，我都强制先跑一遍对账再提测。希望这套拆解能帮你少走点弯路。

本文还有配套的精品资源，点击获取