这套系统的选题很讨巧Java后端加微信小程序前端的英语学习激励系统看起来是个标准的毕设项目但仔细拆一遍会发现它把学习类产品最常见的“用户坚持不下去”问题用一套完整的积分、打卡、排行榜和消息提醒机制串了起来。登录、打卡、积分流水、排行统计、订阅消息推送该有的模块一个不少还带源码和文档说明拿来当课程设计、毕业设计或者自己练手学全栈都很合适。我从0到1搭这套系统时踩了不少坑也趟出了一些经验。下面按实际开发的路径来聊从整体设计思路、表结构到核心接口和小程序页面再到真机调试和上线部署尽量把一个新手也能照着复现的完整流程讲清楚。1. 项目定位与整体架构设计1.1 需求拆解为什么“激励”才是这类系统的灵魂很多人第一次看这个题目会觉得它就是个“背单词打卡App”。但如果只做打卡和记录那本质上就是个电子表格用户装完用两天就删了。英语学习最大的痛点不是没有内容而是缺乏持续的动力。今天加班太累、明天朋友约饭、后天心情不好任何一个理由都能让学习中断。激励系统的核心作用是把“坚持”这件事变成可量化的反馈回路。每完成一次打卡积分增加连续打卡天数越多额外奖励越高排行榜上能看到自己和别人的差距到点没打卡小程序推送一条提醒。这套机制背后是行为心理学里的“即时奖励”和“社会比较”技术上并不复杂但设计对了留存数据会明显好于纯工具类应用。所以做这个项目时我建议把“激励”当主线而不是当附加功能。打卡是行为触发点积分是即时反馈排行榜是外部压力订阅消息是挽回机制。四个模块互相咬合才构成一个完整的激励闭环。功能可以先少一点但这个闭环不能断。1.2 技术选型Java后端搭配原生小程序的逻辑后端选择Java和Spring Boot原因很实际。Spring Boot生态成熟、资料多MyBatis-Plus操作数据库够简洁Maven管理依赖也方便这套组合在大学课程里学得最多遇到问题搜得到答案对新手最友好。JDK版本建议用1.8或11不要一上来就上17甚至21部分老教程和依赖在新版本下会出现兼容问题。小程序端我用的是原生框架而不是uni-app或Taro。原生小程序虽然写起来啰嗦一点但调试时定位问题最直接微信官方API的适配也是最好的。尤其是登录、订阅消息、支付这类强依赖微信能力的场景原生框架的坑更少。如果你以后想一套代码跑微信、支付宝、抖音多端再迁移到跨端框架也不迟但作为学习项目先把原生基本功打牢更重要。数据库选的MySQL缓存方面如果用户量不大初期可以不用Redis直接查MySQL也扛得住。但如果排行榜并发访问高后面可以再引入Redis做缓存项目文档里建议把这一步写成“后期优化方向”作为答辩亮点很加分。1.3 整体功能地图与数据流我把系统拆成五个模块基本覆盖了一个激励类学习小程序的核心流程。模块核心功能关键数据登录模块微信授权登录、用户注册、Token签发openid、session_key、token打卡模块每日打卡、连续天数计算、防重复校验checkin_date、points积分模块积分变动、流水记录、排名统计change_type、change_points排行榜模块周榜/总榜、Top N列表total_points消息模块订阅消息发送、定时任务提醒access_token、模板ID数据流转的逻辑是小程序通过wx.login()获取临时code传给后端后端用code换取openid确认用户身份后签发自己的登录token后续小程序所有业务请求都携带这个token后端识别用户身份后返回对应数据。这个链路里openid是用户在微信体系里的唯一身份标识但绝不直接暴露给前端反复使用而是作为后端识别用户的内部依据这个细节很多新手会踩坑后面详细说。2. 核心功能模块细节与设计原理2.1 登录态设计别把openid直接当用户凭证微信小程序的登录流程官方标准是wx.login()获取code然后把code传到后端后端调用code2Session接口用code换回openid和session_key。openid是用户在你的小程序里的唯一ID同一个用户在不同小程序里openid是不同的这个字段适合做用户表的主业务标识。但openid有一个问题它是个长期固定值如果前端拿到openid就等于拿到了用户的“永久身份证”存在泄露风险。正确做法是后端拿到openid后先用它查用户表查到就更新最近登录时间查不到就创建新用户。然后生成一个你自己控制的token比如UUID或JWT返回给小程序端存储。后续请求都校验这个token不再直接依赖openid。很多初学者直接把前端传过来的code存进用户表或者把openid直接返回到小程序本地存储这两种做法都不可取。code有效期只有五分钟而且只能用一次不能当身份凭证openid虽然稳定但业务接口全用它做参数一旦被恶意抓包整个系统就裸奔了。session_key的作用也容易被忽略。它是用来解密微信侧敏感数据的比如手机号快速验证、用户信息加密数据。后端换到session_key后只应在需要解密时使用绝不能下发到前端。开发调试时可以看Network面板确认这个字段没出现在响应体里。2.2 打卡逻辑一天一次的“防重复”设计打卡是整个系统的核心动作设计要点只有一个保证同一个用户同一天最多只能打一次卡。这里最容易踩的坑是在用户表里设计一个“今日是否已打卡”的布尔字段打卡时判断一下再更新。这种设计的致命问题有两个一是“今天”这个概念需要每天凌晨重置定时任务一旦挂了整个功能就乱套二是并发请求时两个请求同时通过判断就会产生两条打卡记录。我采用的方案是新建一张checkin_record打卡记录表每一条记录代表用户某一天的一次打卡用(user_id, checkin_date)建唯一索引。数据库层面的唯一约束是防并发重复的最终兜底比在业务代码里做校验可靠得多。打卡接口的逻辑是先查当天有没有记录有就返回“今日已打卡”没有就插入新记录同时计算连续打卡天数和奖励积分。还有一个细节判断“今天”的标准必须统一。前端传日期不可信因为用户可以改手机时间后端处理时使用服务器时间但要注意服务器时区设置。MySQL连接串里建议显式加上serverTimezoneAsia/Shanghai接口层统一使用LocalDate.now()避免线上和本地的日期判定差异。2.3 积分与排行榜别急着上Redis也别全表乱查积分流水和积分余额一定要分开。score_record积分流水表记录每一次积分变动比如“每日打卡10分”“连续7天奖励30分”用户表里的total_points是积分余额用于排行榜和展示。只维护一个字段的后果是用户哪天发现积分算错了你连追踪的依据都没有。排行榜的实现方案需要根据用户量分级。几千、几万用户量级直接SQL查询就可以从积分流水表按用户分组求和再按总量排序取前50。联合user表查出昵称头像一个LEFT JOIN就能搞定。前提是给score_record的user_id和created_at建好索引否则数据量上来后查询会变慢。如果用户量到了几十万级别再上Redis的 ZSET以积分作为score用户ID作为member每次积分变动时ZINCRBY排行榜直接ZREVRANGE取TopN。但这就是课程设计能吹的“架构升级”了实际开发中大部分场景直接查MySQL都够用。周榜和总榜的区别无非是SQL查询时加不加时间过滤条件或者Redis里用不同的key区分周期。2.4 激励消息定时任务加订阅消息的配合微信小程序的订阅消息是召回用户的重要手段。但它有两个限制一是必须用户主动点击授权你才能推送二是普通的一次性订阅用户授权一次只能推一条。所以产品层面不能天天骚扰要在关键节点推比如连续打卡断签提醒、排行榜名次变化提醒。后端使用Spring Boot自带的Scheduled定时任务就够了不需要一上来就引入xxl-job这类分布式调度框架。项目启动类上加上EnableScheduling然后在定时任务方法上写cron表达式。每天固定时间扫描用户找出昨天打过卡今天还没打的调用微信订阅消息接口推送提醒。推送接口的核心是access_token这是调用微信所有接口的通行证。它有两个要点有效期只有7200秒必须缓存起来复用不能每次推送前都重新获取否则高频场景下必被限流。我建议用一个定时任务每100分钟刷新一次token存到内存或者Redis里。这里要特别提醒订阅消息的模板ID需要在微信公众平台申请个人主体的小程序能申请到的模板类型有限开发前先确认好你要用的模板类目是否可用。开发调试时预览模式下订阅消息是收不到的必须用体验版或正式版测试。3. 关键实操环节与核心代码实现3.1 后端工程结构与数据库表设计后端工程结构我按Spring Boot标准分层来组织src/main/java/com/example/english/ ├── controller/ // 接口层LoginController、CheckinController、RankingController ├── service/ // 业务层登录、打卡、积分、排行、消息推送 ├── mapper/ // 数据访问层MyBatis-Plus Mapper接口 ├── entity/ // 实体类User、CheckinRecord、ScoreRecord ├── config/ // 配置类WebMvc拦截器、定时任务配置 └── common/ // 通用返回体、异常处理、Token工具类数据库建表脚本核心四张表就够了。用户表主存身份和积分余额打卡记录表管每日动作积分流水表管每一笔积分变动学习记录表记录用户的学习行为明细比如背了多少单词、读了多久文章。CREATE TABLE user ( id bigint NOT NULL AUTO_INCREMENT, openid varchar(64) NOT NULL COMMENT 微信openid, nickname varchar(64) DEFAULT COMMENT 昵称, avatar_url varchar(255) DEFAULT COMMENT 头像地址, total_points int DEFAULT 0 COMMENT 总积分, checkin_days int DEFAULT 0 COMMENT 连续打卡天数, created_at datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;CREATE TABLE checkin_record ( id bigint NOT NULL AUTO_INCREMENT, user_id bigint NOT NULL COMMENT 用户ID, checkin_date date NOT NULL COMMENT 打卡日期, points int NOT NULL COMMENT 本次获得积分, created_at datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_user_date (user_id, checkin_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;CREATE TABLE score_record ( id bigint NOT NULL AUTO_INCREMENT, user_id bigint NOT NULL, change_type varchar(32) NOT NULL COMMENT 变更类型checkin/bonus/task, change_points int NOT NULL COMMENT 变动积分正数增加负数减少, remark varchar(128) DEFAULT COMMENT 备注, created_at datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), INDEX idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;字符集统一用utf8mb4用户昵称和表情符号都能正常存储。注意每张表都建了索引用户表openid唯一索引打卡记录表联合唯一索引积分流水表用户ID索引。数据库层面把该防的重复和慢查询问题提前防掉比业务代码里写一堆判断更省心。3.2 登录接口与Token签发实现后端登录接口的代码逻辑就是三步接收前端传来的code调用微信接口换openid然后签发自己的token。下面这段是核心实现完整项目里的WxAuthService会再封装一层但主体逻辑就是这样。PostMapping(/api/auth/login) public Result login(RequestBody LoginRequest req) { // 1. 用code调用微信接口获取openid和session_key String url https://api.weixin.qq.com/sns/jscode2session?appid appid secret secret js_code req.getCode() grant_typeauthorization_code; String json HttpUtil.get(url); JSONObject obj JSONObject.parseObject(json); if (obj.getString(openid) null) { return Result.error(微信登录失败 obj.getString(errmsg)); } String openid obj.getString(openid); // 2. 查用户表不存在则注册新用户 User user userMapper.selectByOpenid(openid); if (user null) { user new User(); user.setOpenid(openid); user.setNickname(微信用户); user.setAvatarUrl(); user.setTotalPoints(0); user.setCheckinDays(0); userMapper.insert(user); } // 3. 签发自己的token并返回 String token UUID.randomUUID().toString().replace(-, ); redisUtil.set(token: token, user.getId(), 7 * 24 * 3600); LoginResult result new LoginResult(); result.setToken(token); result.setUserInfo(user); return Result.ok(result); }注意这里我把token存到了Redis并设置7天过期。如果你不用Redis也可以放到数据库表里但千万记得查接口前先校验token是否存在和过期。Web层可以写一个拦截器统一从请求头拿token再查用户信息放到ThreadLocal里业务代码不用每次都写一遍“根据token取用户”的重复逻辑。微信接口响应里还有一个session_key上面的示例代码没提它因为登录场景用不到。当你需要解密手机号或微信运动数据时才从Redis里把auth会话信息取出来配合使用。openid、session_key、token三者的关系新手容易搞混记住一条原则openid是微信给你的身份标识session_key是解密钥匙token是你自己签发的临时凭证。3.3 打卡接口与连续天数计算打卡接口需要事务保证数据一致性因为打卡涉及三步操作插入打卡记录、写入积分流水、更新用户累计积分。任何一个失败都会造成数据不一致。所以方法上直接加Transactional这三步操作要么全部成功要么全部回滚。Transactional public CheckinResult doCheckin(Long userId) { LocalDate today LocalDate.now(); // 1. 防重复打卡查记录有则直接返回已打卡 CheckinRecord exist checkinRecordMapper.findByUserIdAndDate(userId, today); if (exist ! null) { return CheckinResult.alreadyChecked(); } // 2. 计算连续天数和积分奖励 LocalDate yesterday today.minusDays(1); CheckinRecord yesterdayRecord checkinRecordMapper.findByUserIdAndDate(userId, yesterday); int streak 1; if (yesterdayRecord ! null) { streak userMapper.selectById(userId).getCheckinDays() 1; } int basePoints 10; int bonusPoints 0; if (streak 7) { bonusPoints 30; } else if (streak 3) { bonusPoints 15; } // 3. 插入打卡记录和积分流水更新用户累计数据 CheckinRecord record new CheckinRecord(); record.setUserId(userId); record.setCheckinDate(today); record.setPoints(basePoints bonusPoints); checkinRecordMapper.insert(record); ScoreRecord scoreRecord new ScoreRecord(); scoreRecord.setUserId(userId); scoreRecord.setChangeType(checkin); scoreRecord.setChangePoints(basePoints bonusPoints); scoreRecord.setRemark(每日打卡); scoreRecordMapper.insert(scoreRecord); User user userMapper.selectById(userId); user.setTotalPoints(user.getTotalPoints() basePoints bonusPoints); user.setCheckinDays(streak); userMapper.updateById(user); return CheckinResult.success(streak, basePoints bonusPoints); }这里最容易被忽视的是连续天数的计算逻辑。如果只依赖yesterdayRecord判断“昨天有没有打”用户断签后再打卡连续天数就会从1重新开始这没问题。但要注意一种边界情况用户今天连续第7天打卡如果他在第8天漏了第9天再打卡连续天数应该重置为1而不是继续累加。实现的关键是每次打卡时用“昨天记录 当前记录的连续天数”推导而不是拿数据库里存的数字无脑加。积分流水里我记录了change_type以后如果要加任务积分、分享奖励只需要扩展这个字段排行榜统计也能按类型过滤。这也是为什么我一直强调“流水归流水、余额归余额”开发到后面你会感谢这个设计。3.4 小程序端核心页面与接口调用小程序端的目录结构按页面划分足够了。全局逻辑里最重要的就是登录态的封装。app.js里做一个login()的Promise封装启动时先检查本地有没有token有就直接用没有就调wx.login()拿code再请求后端接口换取token。// app.js App({ globalData: { userInfo: null, token: }, onLaunch() { this.login(); }, login() { return new Promise((resolve, reject) { const token wx.getStorageSync(token); if (token) { this.globalData.token token; resolve(token); return; } wx.login({ success: (res) { wx.request({ url: https://your-domain.com/api/auth/login, method: POST, data: { code: res.code }, success: (resp) { wx.setStorageSync(token, resp.data.data.token); this.globalData.token resp.data.data.token; resolve(resp.data.data.token); } }); } }); }); } });首页打卡页面的核心逻辑是拉取当天打卡状态后控制打卡按钮的可用状态。日期显示直接用new Date()格式化不需要引入第三方日历组件。打卡请求发出后后端返回最新连续天数和获得积分前端做一个简单动画提示用户激励反馈的即时感很重要。排行榜页面涉及小程序最常见的“列表加载更多”需求。onReachBottom是页面滚动到底部时自动触发在里面把当前页码加1请求下一页数据拼接。请求携带page和size参数后端用LIMIT offset, size实现分页。我记得第一版直接把所有用户塞到一个列表里setData一次传了上千条数据页面卡成PPT改成page1size20后流畅很多。分页逻辑看起来基础但它是小程序项目的标配考点。顶部导航栏的处理也提一下。如果你想自定义导航栏而不是用微信默认的需要处理胶囊按钮的位置。官方apiwx.getMenuButtonBoundingClientRect()可以拿到胶囊的坐标再结合wx.getSystemInfoSync()的状态栏高度就能精确算出导航栏高度。这个值不同机型差异很大只用固定数值适配样式一定会错位。项目源码里我写了一个navigation-bar组件直接复用到各页面省去了反复计算的麻烦。3.5 后端排行榜与小程序的配置联调排行榜接口实现时我踩过一次不合理的坑想着用定时任务提前把排名算好存表结果一次排名更新不及时用户反复刷新看到旧数据反而投诉。后来改成实时查询一次数据量不大时响应在几十毫秒内完全够用。GetMapping(/api/ranking) public Result getRanking( RequestParam(defaultValue total) String type, RequestParam(defaultValue 1) Integer page, RequestParam(defaultValue 20) Integer size) { LocalDateTime startTime null; if (week.equals(type)) { startTime LocalDate.now().minusDays(7).atStartOfDay(); } ListRankingVO ranking scoreRecordMapper.selectRanking(startTime, (page - 1) * size, size); return Result.ok(new PageResult(ranking, page, size)); }对应的SQL在ScoreRecordMapper.xml里用动态SQL拼接时间条件。统计口径是按用户ID分组对积分流水求和再按总额倒序。别在SELECT里直接写*只查需要的字段MySQL查询效率和传输体积都会好一些。SELECT u.id, u.nickname, u.avatar_url, IFNULL(SUM(sr.change_points), 0) AS total_points FROM user u LEFT JOIN score_record sr ON sr.user_id u.id if teststartTime ! null AND sr.created_at gt; #{startTime} /if GROUP BY u.id ORDER BY total_points DESC LIMIT #{offset}, #{size}小程序端开发调试时有两个配置要提前设好一是微信开发者工具右上角“详情-本地设置”里勾选“不校验合法域名”这样开发环境请求http://localhost:8080不会被拦截二是后端需要开启CORS跨域配置否则浏览器环境调试小程序的请求时会被跨域策略挡掉。上线后这些都要关掉换成HTTPS正式域名并配置到小程序后台的“服务器域名”白名单里。4. 常见问题与排查技巧实录4.1 登录相关报错code失效、appid不匹配与10002类问题登录接口联调时会遇到各种报错我把高频的几个整理成了一张速查表。报错表现原因解决办法invalid codecode已过期或已使用code有效期5分钟且只能用一次重新调wx.login()invalid appidappid和secret不匹配检查小程序后台的AppID与密钥是否对应每次登录都生成新用户把code当openid用了错误地拿code作为用户身份应该用code换openid请求报10002appid、secret或参数校验失败检查请求参数和服务端配置重点核对secret是否过期重置线上能登录、开发者工具不行开发者工具未配合法域名开发阶段勾选“不校验合法域名”上线必须配正式域名10002这个错误码具体出现在支付和部分接口参数校验场景里本质上提示的是请求参数或系统配置不合法。遇到它先别急着查网上结论最有效的排查路径是第一步核对appid和secret是否和当前小程序匹配尤其注意secret在公众平台重置过但没有同步到后端第二步检查请求参数格式尤其是JSON体字段名和后端实体类的对应关系第三步看后端日志里微信接口返回的原始错误信息很多时候微信已经在errmsg里写清楚了原因。还有一个用户反馈很典型的场景某用户永远登不上但别人都正常。排查到最后是用户微信版本太老不支持新版登录接口。这个问题在开发者工具里完全复现不了必须真机测试才能暴露所以登录功能上线前一定至少借身边三台不同机型的手机测一遍。4.2 包体积超2MB限制与列表性能优化微信小程序主包体积限制是2MB超过后上传直接失败。项目开发到中期如果图片、第三方库、页面代码一股脑全塞主包很容易就撞线。我在项目里加了一个在线学习图片资源后主包就涨到了2612KB上传时被拒。首选方案是图片外链化。所有静态图片传到对象存储或图床小程序只存URL本地不保留任何二进制图片。这是最立竿见影的方案一张高清图片轻松几百KB换成URL后体积可以忽略不计。其次是清理未引用的组件和代码尤其是不知什么时候引入的旧UI组件库检查一遍所有页面的usingComponents没用的全部删掉。如果做了上面两步还是超限就用分包加载。把非首屏的页面比如排行榜、个人设置中心移到subpackages分包目录。主包只保留首页打卡页和公共组件分包的体积单独计算每个分包限制也是2MB整个项目总上限变成了更多。配置方式很直接在app.json里加一段{ pages: [pages/index/index, pages/mine/mine], subpackages: [ { root: packageRank, pages: [pages/rank/rank] } ] }分包加载的页面跳转时用wx.navigateTo的目标路径改成packageRank/pages/rank/rank其他逻辑不用变。数据加载时还要注意setData的频率和体量列表一次只渲染当前页的20条不要把所有数据一次性setData到页面下拉刷新时只更新数据不重置整个列表否则用户会看到列表闪跳。4.3 真机调试、体验版分发与用户试用反馈收集把小程序发给朋友试用不是直接把二维码发给对方就行。正规做法是在开发者工具点“上传”按钮填版本号和备注然后在微信公众平台后台的“版本管理”里把上传的版本设为“体验版”再在“成员管理”里添加体验成员。体验成员用微信扫码后就能在“最近使用的小程序”里找到这个版本。相比“预览”生成的临时二维码体验版有效期长适合收集几天的试用反馈。预览二维码的问题在于它默认每次打开都要开发者工具作为调试端在线依赖开发电脑的网络和工具状态体验效果不稳定。而体验版是独立跑在微信服务器上的跟正式版唯一的区别就是访问成员受限更适合做小范围试用。真机调试时还有一个高频问题后端接口能通但H5页面里点“打开小程序”却提示无法访问。原因是微信小程序的链接只能在微信内置浏览器或扫码场景触发普通浏览器直接打开必然失败。这不是代码问题而是平台限制做分享功能时注意提示用户“请在微信内打开”。4.4 Java后端启动失败与环境配置排查项目跑不起来的时候别急着网上搜按顺序排查十有八九能解决。第一步命令行执行java -version确认JDK安装成功第二步执行mvn -v确认Maven用的JDK和项目要求的版本一致这里经常出现命令行能跑但IDE启动失败的情况大概率是IDE配置的JDK版本和项目不匹配第三步看Spring Boot启动日志端口被占用会直接告诉你换个端口或者找到占用进程结束掉即可。数据库连接报错是最常见的启动失败原因。检查三项MySQL服务是否启动、3306端口能不能连通、连接串里的用户名密码是否正确。连接串里一定要带时区参数我项目里最早用的连接串是jdbc:mysql://localhost:3306/english?useSSLfalseLinux服务器上部署时启动报时区错误加上serverTimezoneAsia/ShanghaicharacterEncodingutf8就好了。打包部署命令我一般用mvn clean package -DskipTests跳过测试可以节省时间。生成的可执行jar包用nohup java -jar english.jar --server.port8080 app.log 21 后台运行日志输出到文件方便排查。线上环境如果经常遇到内存不足可以在启动命令里加-Xms256m -Xmx512m限制JVM内存占用避免和服务器上的其他应用抢资源。4.5 定时任务与订阅消息的开发坑定时任务这个模块开发过程中最常见的坑是“跑不起来”和“重复执行”。跑不起来多半是忘了在启动类加EnableScheduling或者定时任务类没有被Spring扫描到重复执行则通常是因为部署了多个实例每个实例都在跑同一个定时任务。多实例部署时建议用分布式锁或在配置文件里加开关保证同一时间只有一个实例在执行推送任务。订阅消息的测试开发工具里点“编译”不会触发真实推送必须用体验版或真机。而且用户授权订阅时如果连续点了“总是保持以上选择”会直接把授权标记存到微信侧后端推送到额度用完后不会报错但是静默失败。排查时可以在后端打印每次发送结果的返回码errCode为0才是成功其他码按照文档查原因。我在做消息提醒时还发现一个问题用户授权了一次订阅但我每天定时任务都在尝试推送结果用户只收到第一条后面全部静默失败。后来改成在推送前查询用户剩余的可用推送次数没有额度就跳过同时前端在打卡结果页展示“开启每日提醒”的按钮引导用户再次授权。5. 收尾前说几句实在话这套系统整体做完你会在一个项目里同时碰遍微信生态和Java后端的常见模块这对综合能力的提升非常明显。我最后再分享一个小技巧打卡日期这种核心字段后端一定要用服务器时间别信前端传的时间。别问我怎么知道的——改手机系统时间刷积分这种事真的有人干得出来。
这套系统的选题很讨巧Java后端加微信小程序前端的英语学习激励系统看起来是个标准的毕设项目但仔细拆一遍会发现它把学习类产品最常见的“用户坚持不下去”问题用一套完整的积分、打卡、排行榜和消息提醒机制串了起来。登录、打卡、积分流水、排行统计、订阅消息推送该有的模块一个不少还带源码和文档说明拿来当课程设计、毕业设计或者自己练手学全栈都很合适。我从0到1搭这套系统时踩了不少坑也趟出了一些经验。下面按实际开发的路径来聊从整体设计思路、表结构到核心接口和小程序页面再到真机调试和上线部署尽量把一个新手也能照着复现的完整流程讲清楚。1. 项目定位与整体架构设计1.1 需求拆解为什么“激励”才是这类系统的灵魂很多人第一次看这个题目会觉得它就是个“背单词打卡App”。但如果只做打卡和记录那本质上就是个电子表格用户装完用两天就删了。英语学习最大的痛点不是没有内容而是缺乏持续的动力。今天加班太累、明天朋友约饭、后天心情不好任何一个理由都能让学习中断。激励系统的核心作用是把“坚持”这件事变成可量化的反馈回路。每完成一次打卡积分增加连续打卡天数越多额外奖励越高排行榜上能看到自己和别人的差距到点没打卡小程序推送一条提醒。这套机制背后是行为心理学里的“即时奖励”和“社会比较”技术上并不复杂但设计对了留存数据会明显好于纯工具类应用。所以做这个项目时我建议把“激励”当主线而不是当附加功能。打卡是行为触发点积分是即时反馈排行榜是外部压力订阅消息是挽回机制。四个模块互相咬合才构成一个完整的激励闭环。功能可以先少一点但这个闭环不能断。1.2 技术选型Java后端搭配原生小程序的逻辑后端选择Java和Spring Boot原因很实际。Spring Boot生态成熟、资料多MyBatis-Plus操作数据库够简洁Maven管理依赖也方便这套组合在大学课程里学得最多遇到问题搜得到答案对新手最友好。JDK版本建议用1.8或11不要一上来就上17甚至21部分老教程和依赖在新版本下会出现兼容问题。小程序端我用的是原生框架而不是uni-app或Taro。原生小程序虽然写起来啰嗦一点但调试时定位问题最直接微信官方API的适配也是最好的。尤其是登录、订阅消息、支付这类强依赖微信能力的场景原生框架的坑更少。如果你以后想一套代码跑微信、支付宝、抖音多端再迁移到跨端框架也不迟但作为学习项目先把原生基本功打牢更重要。数据库选的MySQL缓存方面如果用户量不大初期可以不用Redis直接查MySQL也扛得住。但如果排行榜并发访问高后面可以再引入Redis做缓存项目文档里建议把这一步写成“后期优化方向”作为答辩亮点很加分。1.3 整体功能地图与数据流我把系统拆成五个模块基本覆盖了一个激励类学习小程序的核心流程。模块核心功能关键数据登录模块微信授权登录、用户注册、Token签发openid、session_key、token打卡模块每日打卡、连续天数计算、防重复校验checkin_date、points积分模块积分变动、流水记录、排名统计change_type、change_points排行榜模块周榜/总榜、Top N列表total_points消息模块订阅消息发送、定时任务提醒access_token、模板ID数据流转的逻辑是小程序通过wx.login()获取临时code传给后端后端用code换取openid确认用户身份后签发自己的登录token后续小程序所有业务请求都携带这个token后端识别用户身份后返回对应数据。这个链路里openid是用户在微信体系里的唯一身份标识但绝不直接暴露给前端反复使用而是作为后端识别用户的内部依据这个细节很多新手会踩坑后面详细说。2. 核心功能模块细节与设计原理2.1 登录态设计别把openid直接当用户凭证微信小程序的登录流程官方标准是wx.login()获取code然后把code传到后端后端调用code2Session接口用code换回openid和session_key。openid是用户在你的小程序里的唯一ID同一个用户在不同小程序里openid是不同的这个字段适合做用户表的主业务标识。但openid有一个问题它是个长期固定值如果前端拿到openid就等于拿到了用户的“永久身份证”存在泄露风险。正确做法是后端拿到openid后先用它查用户表查到就更新最近登录时间查不到就创建新用户。然后生成一个你自己控制的token比如UUID或JWT返回给小程序端存储。后续请求都校验这个token不再直接依赖openid。很多初学者直接把前端传过来的code存进用户表或者把openid直接返回到小程序本地存储这两种做法都不可取。code有效期只有五分钟而且只能用一次不能当身份凭证openid虽然稳定但业务接口全用它做参数一旦被恶意抓包整个系统就裸奔了。session_key的作用也容易被忽略。它是用来解密微信侧敏感数据的比如手机号快速验证、用户信息加密数据。后端换到session_key后只应在需要解密时使用绝不能下发到前端。开发调试时可以看Network面板确认这个字段没出现在响应体里。2.2 打卡逻辑一天一次的“防重复”设计打卡是整个系统的核心动作设计要点只有一个保证同一个用户同一天最多只能打一次卡。这里最容易踩的坑是在用户表里设计一个“今日是否已打卡”的布尔字段打卡时判断一下再更新。这种设计的致命问题有两个一是“今天”这个概念需要每天凌晨重置定时任务一旦挂了整个功能就乱套二是并发请求时两个请求同时通过判断就会产生两条打卡记录。我采用的方案是新建一张checkin_record打卡记录表每一条记录代表用户某一天的一次打卡用(user_id, checkin_date)建唯一索引。数据库层面的唯一约束是防并发重复的最终兜底比在业务代码里做校验可靠得多。打卡接口的逻辑是先查当天有没有记录有就返回“今日已打卡”没有就插入新记录同时计算连续打卡天数和奖励积分。还有一个细节判断“今天”的标准必须统一。前端传日期不可信因为用户可以改手机时间后端处理时使用服务器时间但要注意服务器时区设置。MySQL连接串里建议显式加上serverTimezoneAsia/Shanghai接口层统一使用LocalDate.now()避免线上和本地的日期判定差异。2.3 积分与排行榜别急着上Redis也别全表乱查积分流水和积分余额一定要分开。score_record积分流水表记录每一次积分变动比如“每日打卡10分”“连续7天奖励30分”用户表里的total_points是积分余额用于排行榜和展示。只维护一个字段的后果是用户哪天发现积分算错了你连追踪的依据都没有。排行榜的实现方案需要根据用户量分级。几千、几万用户量级直接SQL查询就可以从积分流水表按用户分组求和再按总量排序取前50。联合user表查出昵称头像一个LEFT JOIN就能搞定。前提是给score_record的user_id和created_at建好索引否则数据量上来后查询会变慢。如果用户量到了几十万级别再上Redis的 ZSET以积分作为score用户ID作为member每次积分变动时ZINCRBY排行榜直接ZREVRANGE取TopN。但这就是课程设计能吹的“架构升级”了实际开发中大部分场景直接查MySQL都够用。周榜和总榜的区别无非是SQL查询时加不加时间过滤条件或者Redis里用不同的key区分周期。2.4 激励消息定时任务加订阅消息的配合微信小程序的订阅消息是召回用户的重要手段。但它有两个限制一是必须用户主动点击授权你才能推送二是普通的一次性订阅用户授权一次只能推一条。所以产品层面不能天天骚扰要在关键节点推比如连续打卡断签提醒、排行榜名次变化提醒。后端使用Spring Boot自带的Scheduled定时任务就够了不需要一上来就引入xxl-job这类分布式调度框架。项目启动类上加上EnableScheduling然后在定时任务方法上写cron表达式。每天固定时间扫描用户找出昨天打过卡今天还没打的调用微信订阅消息接口推送提醒。推送接口的核心是access_token这是调用微信所有接口的通行证。它有两个要点有效期只有7200秒必须缓存起来复用不能每次推送前都重新获取否则高频场景下必被限流。我建议用一个定时任务每100分钟刷新一次token存到内存或者Redis里。这里要特别提醒订阅消息的模板ID需要在微信公众平台申请个人主体的小程序能申请到的模板类型有限开发前先确认好你要用的模板类目是否可用。开发调试时预览模式下订阅消息是收不到的必须用体验版或正式版测试。3. 关键实操环节与核心代码实现3.1 后端工程结构与数据库表设计后端工程结构我按Spring Boot标准分层来组织src/main/java/com/example/english/ ├── controller/ // 接口层LoginController、CheckinController、RankingController ├── service/ // 业务层登录、打卡、积分、排行、消息推送 ├── mapper/ // 数据访问层MyBatis-Plus Mapper接口 ├── entity/ // 实体类User、CheckinRecord、ScoreRecord ├── config/ // 配置类WebMvc拦截器、定时任务配置 └── common/ // 通用返回体、异常处理、Token工具类数据库建表脚本核心四张表就够了。用户表主存身份和积分余额打卡记录表管每日动作积分流水表管每一笔积分变动学习记录表记录用户的学习行为明细比如背了多少单词、读了多久文章。CREATE TABLE user ( id bigint NOT NULL AUTO_INCREMENT, openid varchar(64) NOT NULL COMMENT 微信openid, nickname varchar(64) DEFAULT COMMENT 昵称, avatar_url varchar(255) DEFAULT COMMENT 头像地址, total_points int DEFAULT 0 COMMENT 总积分, checkin_days int DEFAULT 0 COMMENT 连续打卡天数, created_at datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_openid (openid) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;CREATE TABLE checkin_record ( id bigint NOT NULL AUTO_INCREMENT, user_id bigint NOT NULL COMMENT 用户ID, checkin_date date NOT NULL COMMENT 打卡日期, points int NOT NULL COMMENT 本次获得积分, created_at datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_user_date (user_id, checkin_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;CREATE TABLE score_record ( id bigint NOT NULL AUTO_INCREMENT, user_id bigint NOT NULL, change_type varchar(32) NOT NULL COMMENT 变更类型checkin/bonus/task, change_points int NOT NULL COMMENT 变动积分正数增加负数减少, remark varchar(128) DEFAULT COMMENT 备注, created_at datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), INDEX idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;字符集统一用utf8mb4用户昵称和表情符号都能正常存储。注意每张表都建了索引用户表openid唯一索引打卡记录表联合唯一索引积分流水表用户ID索引。数据库层面把该防的重复和慢查询问题提前防掉比业务代码里写一堆判断更省心。3.2 登录接口与Token签发实现后端登录接口的代码逻辑就是三步接收前端传来的code调用微信接口换openid然后签发自己的token。下面这段是核心实现完整项目里的WxAuthService会再封装一层但主体逻辑就是这样。PostMapping(/api/auth/login) public Result login(RequestBody LoginRequest req) { // 1. 用code调用微信接口获取openid和session_key String url https://api.weixin.qq.com/sns/jscode2session?appid appid secret secret js_code req.getCode() grant_typeauthorization_code; String json HttpUtil.get(url); JSONObject obj JSONObject.parseObject(json); if (obj.getString(openid) null) { return Result.error(微信登录失败 obj.getString(errmsg)); } String openid obj.getString(openid); // 2. 查用户表不存在则注册新用户 User user userMapper.selectByOpenid(openid); if (user null) { user new User(); user.setOpenid(openid); user.setNickname(微信用户); user.setAvatarUrl(); user.setTotalPoints(0); user.setCheckinDays(0); userMapper.insert(user); } // 3. 签发自己的token并返回 String token UUID.randomUUID().toString().replace(-, ); redisUtil.set(token: token, user.getId(), 7 * 24 * 3600); LoginResult result new LoginResult(); result.setToken(token); result.setUserInfo(user); return Result.ok(result); }注意这里我把token存到了Redis并设置7天过期。如果你不用Redis也可以放到数据库表里但千万记得查接口前先校验token是否存在和过期。Web层可以写一个拦截器统一从请求头拿token再查用户信息放到ThreadLocal里业务代码不用每次都写一遍“根据token取用户”的重复逻辑。微信接口响应里还有一个session_key上面的示例代码没提它因为登录场景用不到。当你需要解密手机号或微信运动数据时才从Redis里把auth会话信息取出来配合使用。openid、session_key、token三者的关系新手容易搞混记住一条原则openid是微信给你的身份标识session_key是解密钥匙token是你自己签发的临时凭证。3.3 打卡接口与连续天数计算打卡接口需要事务保证数据一致性因为打卡涉及三步操作插入打卡记录、写入积分流水、更新用户累计积分。任何一个失败都会造成数据不一致。所以方法上直接加Transactional这三步操作要么全部成功要么全部回滚。Transactional public CheckinResult doCheckin(Long userId) { LocalDate today LocalDate.now(); // 1. 防重复打卡查记录有则直接返回已打卡 CheckinRecord exist checkinRecordMapper.findByUserIdAndDate(userId, today); if (exist ! null) { return CheckinResult.alreadyChecked(); } // 2. 计算连续天数和积分奖励 LocalDate yesterday today.minusDays(1); CheckinRecord yesterdayRecord checkinRecordMapper.findByUserIdAndDate(userId, yesterday); int streak 1; if (yesterdayRecord ! null) { streak userMapper.selectById(userId).getCheckinDays() 1; } int basePoints 10; int bonusPoints 0; if (streak 7) { bonusPoints 30; } else if (streak 3) { bonusPoints 15; } // 3. 插入打卡记录和积分流水更新用户累计数据 CheckinRecord record new CheckinRecord(); record.setUserId(userId); record.setCheckinDate(today); record.setPoints(basePoints bonusPoints); checkinRecordMapper.insert(record); ScoreRecord scoreRecord new ScoreRecord(); scoreRecord.setUserId(userId); scoreRecord.setChangeType(checkin); scoreRecord.setChangePoints(basePoints bonusPoints); scoreRecord.setRemark(每日打卡); scoreRecordMapper.insert(scoreRecord); User user userMapper.selectById(userId); user.setTotalPoints(user.getTotalPoints() basePoints bonusPoints); user.setCheckinDays(streak); userMapper.updateById(user); return CheckinResult.success(streak, basePoints bonusPoints); }这里最容易被忽视的是连续天数的计算逻辑。如果只依赖yesterdayRecord判断“昨天有没有打”用户断签后再打卡连续天数就会从1重新开始这没问题。但要注意一种边界情况用户今天连续第7天打卡如果他在第8天漏了第9天再打卡连续天数应该重置为1而不是继续累加。实现的关键是每次打卡时用“昨天记录 当前记录的连续天数”推导而不是拿数据库里存的数字无脑加。积分流水里我记录了change_type以后如果要加任务积分、分享奖励只需要扩展这个字段排行榜统计也能按类型过滤。这也是为什么我一直强调“流水归流水、余额归余额”开发到后面你会感谢这个设计。3.4 小程序端核心页面与接口调用小程序端的目录结构按页面划分足够了。全局逻辑里最重要的就是登录态的封装。app.js里做一个login()的Promise封装启动时先检查本地有没有token有就直接用没有就调wx.login()拿code再请求后端接口换取token。// app.js App({ globalData: { userInfo: null, token: }, onLaunch() { this.login(); }, login() { return new Promise((resolve, reject) { const token wx.getStorageSync(token); if (token) { this.globalData.token token; resolve(token); return; } wx.login({ success: (res) { wx.request({ url: https://your-domain.com/api/auth/login, method: POST, data: { code: res.code }, success: (resp) { wx.setStorageSync(token, resp.data.data.token); this.globalData.token resp.data.data.token; resolve(resp.data.data.token); } }); } }); }); } });首页打卡页面的核心逻辑是拉取当天打卡状态后控制打卡按钮的可用状态。日期显示直接用new Date()格式化不需要引入第三方日历组件。打卡请求发出后后端返回最新连续天数和获得积分前端做一个简单动画提示用户激励反馈的即时感很重要。排行榜页面涉及小程序最常见的“列表加载更多”需求。onReachBottom是页面滚动到底部时自动触发在里面把当前页码加1请求下一页数据拼接。请求携带page和size参数后端用LIMIT offset, size实现分页。我记得第一版直接把所有用户塞到一个列表里setData一次传了上千条数据页面卡成PPT改成page1size20后流畅很多。分页逻辑看起来基础但它是小程序项目的标配考点。顶部导航栏的处理也提一下。如果你想自定义导航栏而不是用微信默认的需要处理胶囊按钮的位置。官方apiwx.getMenuButtonBoundingClientRect()可以拿到胶囊的坐标再结合wx.getSystemInfoSync()的状态栏高度就能精确算出导航栏高度。这个值不同机型差异很大只用固定数值适配样式一定会错位。项目源码里我写了一个navigation-bar组件直接复用到各页面省去了反复计算的麻烦。3.5 后端排行榜与小程序的配置联调排行榜接口实现时我踩过一次不合理的坑想着用定时任务提前把排名算好存表结果一次排名更新不及时用户反复刷新看到旧数据反而投诉。后来改成实时查询一次数据量不大时响应在几十毫秒内完全够用。GetMapping(/api/ranking) public Result getRanking( RequestParam(defaultValue total) String type, RequestParam(defaultValue 1) Integer page, RequestParam(defaultValue 20) Integer size) { LocalDateTime startTime null; if (week.equals(type)) { startTime LocalDate.now().minusDays(7).atStartOfDay(); } ListRankingVO ranking scoreRecordMapper.selectRanking(startTime, (page - 1) * size, size); return Result.ok(new PageResult(ranking, page, size)); }对应的SQL在ScoreRecordMapper.xml里用动态SQL拼接时间条件。统计口径是按用户ID分组对积分流水求和再按总额倒序。别在SELECT里直接写*只查需要的字段MySQL查询效率和传输体积都会好一些。SELECT u.id, u.nickname, u.avatar_url, IFNULL(SUM(sr.change_points), 0) AS total_points FROM user u LEFT JOIN score_record sr ON sr.user_id u.id if teststartTime ! null AND sr.created_at gt; #{startTime} /if GROUP BY u.id ORDER BY total_points DESC LIMIT #{offset}, #{size}小程序端开发调试时有两个配置要提前设好一是微信开发者工具右上角“详情-本地设置”里勾选“不校验合法域名”这样开发环境请求http://localhost:8080不会被拦截二是后端需要开启CORS跨域配置否则浏览器环境调试小程序的请求时会被跨域策略挡掉。上线后这些都要关掉换成HTTPS正式域名并配置到小程序后台的“服务器域名”白名单里。4. 常见问题与排查技巧实录4.1 登录相关报错code失效、appid不匹配与10002类问题登录接口联调时会遇到各种报错我把高频的几个整理成了一张速查表。报错表现原因解决办法invalid codecode已过期或已使用code有效期5分钟且只能用一次重新调wx.login()invalid appidappid和secret不匹配检查小程序后台的AppID与密钥是否对应每次登录都生成新用户把code当openid用了错误地拿code作为用户身份应该用code换openid请求报10002appid、secret或参数校验失败检查请求参数和服务端配置重点核对secret是否过期重置线上能登录、开发者工具不行开发者工具未配合法域名开发阶段勾选“不校验合法域名”上线必须配正式域名10002这个错误码具体出现在支付和部分接口参数校验场景里本质上提示的是请求参数或系统配置不合法。遇到它先别急着查网上结论最有效的排查路径是第一步核对appid和secret是否和当前小程序匹配尤其注意secret在公众平台重置过但没有同步到后端第二步检查请求参数格式尤其是JSON体字段名和后端实体类的对应关系第三步看后端日志里微信接口返回的原始错误信息很多时候微信已经在errmsg里写清楚了原因。还有一个用户反馈很典型的场景某用户永远登不上但别人都正常。排查到最后是用户微信版本太老不支持新版登录接口。这个问题在开发者工具里完全复现不了必须真机测试才能暴露所以登录功能上线前一定至少借身边三台不同机型的手机测一遍。4.2 包体积超2MB限制与列表性能优化微信小程序主包体积限制是2MB超过后上传直接失败。项目开发到中期如果图片、第三方库、页面代码一股脑全塞主包很容易就撞线。我在项目里加了一个在线学习图片资源后主包就涨到了2612KB上传时被拒。首选方案是图片外链化。所有静态图片传到对象存储或图床小程序只存URL本地不保留任何二进制图片。这是最立竿见影的方案一张高清图片轻松几百KB换成URL后体积可以忽略不计。其次是清理未引用的组件和代码尤其是不知什么时候引入的旧UI组件库检查一遍所有页面的usingComponents没用的全部删掉。如果做了上面两步还是超限就用分包加载。把非首屏的页面比如排行榜、个人设置中心移到subpackages分包目录。主包只保留首页打卡页和公共组件分包的体积单独计算每个分包限制也是2MB整个项目总上限变成了更多。配置方式很直接在app.json里加一段{ pages: [pages/index/index, pages/mine/mine], subpackages: [ { root: packageRank, pages: [pages/rank/rank] } ] }分包加载的页面跳转时用wx.navigateTo的目标路径改成packageRank/pages/rank/rank其他逻辑不用变。数据加载时还要注意setData的频率和体量列表一次只渲染当前页的20条不要把所有数据一次性setData到页面下拉刷新时只更新数据不重置整个列表否则用户会看到列表闪跳。4.3 真机调试、体验版分发与用户试用反馈收集把小程序发给朋友试用不是直接把二维码发给对方就行。正规做法是在开发者工具点“上传”按钮填版本号和备注然后在微信公众平台后台的“版本管理”里把上传的版本设为“体验版”再在“成员管理”里添加体验成员。体验成员用微信扫码后就能在“最近使用的小程序”里找到这个版本。相比“预览”生成的临时二维码体验版有效期长适合收集几天的试用反馈。预览二维码的问题在于它默认每次打开都要开发者工具作为调试端在线依赖开发电脑的网络和工具状态体验效果不稳定。而体验版是独立跑在微信服务器上的跟正式版唯一的区别就是访问成员受限更适合做小范围试用。真机调试时还有一个高频问题后端接口能通但H5页面里点“打开小程序”却提示无法访问。原因是微信小程序的链接只能在微信内置浏览器或扫码场景触发普通浏览器直接打开必然失败。这不是代码问题而是平台限制做分享功能时注意提示用户“请在微信内打开”。4.4 Java后端启动失败与环境配置排查项目跑不起来的时候别急着网上搜按顺序排查十有八九能解决。第一步命令行执行java -version确认JDK安装成功第二步执行mvn -v确认Maven用的JDK和项目要求的版本一致这里经常出现命令行能跑但IDE启动失败的情况大概率是IDE配置的JDK版本和项目不匹配第三步看Spring Boot启动日志端口被占用会直接告诉你换个端口或者找到占用进程结束掉即可。数据库连接报错是最常见的启动失败原因。检查三项MySQL服务是否启动、3306端口能不能连通、连接串里的用户名密码是否正确。连接串里一定要带时区参数我项目里最早用的连接串是jdbc:mysql://localhost:3306/english?useSSLfalseLinux服务器上部署时启动报时区错误加上serverTimezoneAsia/ShanghaicharacterEncodingutf8就好了。打包部署命令我一般用mvn clean package -DskipTests跳过测试可以节省时间。生成的可执行jar包用nohup java -jar english.jar --server.port8080 app.log 21 后台运行日志输出到文件方便排查。线上环境如果经常遇到内存不足可以在启动命令里加-Xms256m -Xmx512m限制JVM内存占用避免和服务器上的其他应用抢资源。4.5 定时任务与订阅消息的开发坑定时任务这个模块开发过程中最常见的坑是“跑不起来”和“重复执行”。跑不起来多半是忘了在启动类加EnableScheduling或者定时任务类没有被Spring扫描到重复执行则通常是因为部署了多个实例每个实例都在跑同一个定时任务。多实例部署时建议用分布式锁或在配置文件里加开关保证同一时间只有一个实例在执行推送任务。订阅消息的测试开发工具里点“编译”不会触发真实推送必须用体验版或真机。而且用户授权订阅时如果连续点了“总是保持以上选择”会直接把授权标记存到微信侧后端推送到额度用完后不会报错但是静默失败。排查时可以在后端打印每次发送结果的返回码errCode为0才是成功其他码按照文档查原因。我在做消息提醒时还发现一个问题用户授权了一次订阅但我每天定时任务都在尝试推送结果用户只收到第一条后面全部静默失败。后来改成在推送前查询用户剩余的可用推送次数没有额度就跳过同时前端在打卡结果页展示“开启每日提醒”的按钮引导用户再次授权。5. 收尾前说几句实在话这套系统整体做完你会在一个项目里同时碰遍微信生态和Java后端的常见模块这对综合能力的提升非常明显。我最后再分享一个小技巧打卡日期这种核心字段后端一定要用服务器时间别信前端传的时间。别问我怎么知道的——改手机系统时间刷积分这种事真的有人干得出来。
