1. 项目概述与核心价值
这个基于SpringBoot的商家优惠活动微信小程序毕业设计项目，本质上是一个典型的O2O营销系统解决方案。我在2018年参与过某连锁餐饮集团的类似系统开发，当时用原生PHP实现，现在看到SpringBoot+小程序的组合方案，不得不感叹技术栈的演进确实让开发效率提升了至少3倍。
这个系统的核心价值在于打通了三个关键场景：商家后台的活动配置、用户端的优惠获取、线上线下核销的闭环验证。其中最精妙的设计点是优惠券的"三态转换"机制——未领取（库存状态）、已领取未使用（用户持有状态）、已核销（完成状态），这种状态机设计能有效避免超发和重复使用问题。
2. 技术架构解析
2.1 前后端分离架构
采用SpringBoot 2.7 + Vue.js + 微信小程序的三端架构，实测在2023年仍是性价比最高的技术选型方案。特别说明几个关键配置：
- SpringBoot关键依赖：
xml复制<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-data-redis</artifactId> <!-- 优惠券库存管理 -->
</dependency>
<dependency>
<groupId>com.github.binarywang</groupId>
<artifactId>weixin-java-miniapp</artifactId> <!-- 微信SDK -->
<version>4.4.0</version>
</dependency>
- 小程序端特色实现：
- 使用
<scroll-view>实现瀑布流优惠展示 - 通过
wx.getLocation()获取用户坐标实现"附近优惠"筛选 - 自定义分享卡片带参数跳转（关键裂变手段）
2.2 数据库设计要点
优惠券系统的表结构设计有三大陷阱需要规避：
- 券基础表(coupon)：
sql复制CREATE TABLE `coupon` (
`id` bigint NOT NULL AUTO_INCREMENT,
`title` varchar(50) NOT NULL COMMENT '如"新客立减20元"',
`type` tinyint NOT NULL COMMENT '1折扣券 2满减券 3代金券',
`value` decimal(10,2) NOT NULL COMMENT '具体优惠值',
`min_order` decimal(10,2) DEFAULT NULL COMMENT '满减门槛',
`stock` int NOT NULL COMMENT '初始库存',
`start_time` datetime NOT NULL,
`end_time` datetime NOT NULL,
`valid_days` int DEFAULT NULL COMMENT '领取后有效天数',
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
- **用户券表(user_coupon)**的特殊字段：
status字段必须包含使用中/已使用/已过期三种状态- 需要
used_time和order_sn关联核销订单 - 建议添加
source字段记录领取途径（自主领取/分享获得）
特别注意：券的过期检查应该用定时任务+缓存双重机制，避免实时查询的性能问题。
3. 核心业务实现
3.1 优惠券发放策略
在实际运营中，我们总结出四种高效发放模式：
- 精准投放（基于用户画像）
java复制public void sendTargetedCoupon(Long userId, Integer couponId) {
// 1. 校验用户标签匹配度
UserTag tag = userService.getUserTags(userId);
if(!tagMatcher.match(tag, couponRule.getTarget())){
throw new BusinessException("用户不符合领取条件");
}
// 2. 使用Redis原子操作防止超发
Long remain = redisTemplate.opsForValue().decrement("coupon:stock:"+couponId);
if(remain < 0){
redisTemplate.opsForValue().increment("coupon:stock:"+couponId);
throw new BusinessException("优惠券已领完");
}
// 3. 落库记录
userCouponMapper.insert(buildUserCoupon(userId, couponId));
}
- 裂变发放（分享得券）
- 时段限量（整点抢券）
- 消费返券（提升复购）
3.2 核销流程设计
线下核销的可靠性是这类系统最大的挑战，我们采用"双码验证+异步确认"机制：
- 前端生成动态核销码（含时间戳+随机数）
- 商家端扫码后先本地验证格式
- 服务端二次校验（防止篡改）：
java复制public boolean verifyCoupon(String verifyCode, Long couponId) {
// 1. 解析核销码中的时间戳
long genTime = decodeTime(verifyCode);
if(System.currentTimeMillis() - genTime > 5*60*1000){
return false; // 5分钟有效期
}
// 2. 检查券状态
UserCoupon coupon = userCouponMapper.selectById(couponId);
return coupon != null
&& coupon.getStatus() == 1
&& coupon.getExpireTime().after(new Date());
}
4. 性能优化实践
4.1 缓存策略三级设计
- 一级缓存（本地缓存）：
- 使用Caffeine缓存基础券信息（变更少）
- 配置示例：
java复制@Bean
public Caffeine<Object, Object> caffeineConfig() {
return Caffeine.newBuilder()
.expireAfterWrite(10, TimeUnit.MINUTES)
.maximumSize(1000);
}
- 二级缓存（Redis）：
- 库存计数用Redis原子操作
- 用户券列表用Hash结构存储
- 防穿透设计：
- 对不存在的券ID缓存空值（设置短过期时间）
- 使用BloomFilter过滤非法ID请求
4.2 并发控制方案
在高并发领券场景下，我们对比过三种方案：
| 方案 | 吞吐量(QPS) | 实现复杂度 | 适用场景 |
|---|---|---|---|
| 数据库乐观锁 | 约1200 | 低 | 中小型活动 |
| Redis原子操作 | 约8500 | 中 | 秒杀类活动 |
| 令牌桶限流 | 约3000 | 高 | 保护后端系统 |
最终选择Redis Lua脚本实现原子操作：
lua复制local key = KEYS[1]
local remain = tonumber(redis.call('GET', key))
if remain and remain > 0 then
redis.call('DECR', key)
return 1
else
return 0
end
5. 典型问题排查实录
5.1 券状态同步延迟
现象：用户已使用优惠券，但小程序端仍显示可用
根本原因：微信小程序缓存机制与后端状态不同步
解决方案：
- 在核销接口返回强制刷新指令
- 小程序端添加手动刷新按钮
- 使用WebSocket推送状态变更
5.2 地理位置偏差问题
现象："附近优惠"功能显示3公里外的商家
排查过程：
- 检查微信返回的坐标是否GCJ-02坐标系
- 确认数据库存储的是WGS-84坐标
- 发现未做坐标系转换
修复方案：
java复制// 坐标转换工具类
public class CoordinateConverter {
private static final double X_PI = 3.14159265358979324 * 3000.0 / 180.0;
public static double[] gcj02ToWgs84(double lng, double lat) {
// 转换算法实现...
}
}
6. 扩展功能建议
在基础功能之上，可以考虑添加这些提升用户体验的功能：
- 智能推荐引擎：
- 基于用户历史领取偏好推荐相似优惠
- 使用协同过滤算法实现
- 券包功能：
- 将多张券组合成"开学季大礼包"
- 设置统一过期时间和使用规则
- 动态效果：
- 即将过期的券添加倒计时动画
- 限量券显示剩余百分比进度条
- 数据分析看板：
sql复制-- 核销率统计SQL示例
SELECT
c.id,
c.title,
COUNT(uc.id) AS send_count,
SUM(CASE WHEN uc.status=2 THEN 1 ELSE 0 END) AS used_count,
CONCAT(ROUND(SUM(CASE WHEN uc.status=2 THEN 1 ELSE 0 END)/COUNT(uc.id)*100,2),'%') AS usage_rate
FROM coupon c
LEFT JOIN user_coupon uc ON c.id=uc.coupon_id
GROUP BY c.id;
这个项目最让我印象深刻的是它完整展现了如何用主流技术栈实现商业闭环。在实际部署时，建议将核销功能做成独立微服务，因为这是系统压力最大的部分。另外，优惠券的ID生成一定要用趋势递增的算法（如雪花算法），避免被恶意遍历。