简介这是一套面向高校学生与企业开发者的企业活动积分微信小程序完整源码适用于毕业设计、课程设计及小程序开发练手场景。项目采用前后端分离架构前台支持成员登录、活动列表浏览、完成活动与积分兑换后台提供管理登录、活动发布、完成情况查看、积分统计排行、活跃度排行及历史积分与兑换记录查询覆盖企业内部活动积分管理的完整业务闭环。压缩包共约2000个文件整体31.49MB以png、css、html、js等前端资源为主另含java后端源码、sql建库脚本、json与xml配置及docx设计文档结构完整便于二次开发。资源同时附带部署文档与需求演示材料可帮助读者快速理解项目分层、数据库表设计与接口调用逻辑对照源码梳理积分统计与排行算法的实现思路。目前已有63人学习适合需要完整小程序项目参考的开发者。1. 企业活动积分小程序一套能跑起来的前后端源码到底长什么样公司行政每年都要搞几场活动签到、答题、抽奖、发积分、兑奖品流程重复但每次都得重新拉群、发问卷、手动统计。有人丢过来一个「企业活动积分小程序完整前后端mysqlLW」的源码包问能不能直接改成自己公司的。这类需求在微信小程序生态里非常典型前端是小程序后端是接口服务数据落 MySQL中间夹着一层活动积分业务逻辑。它解决的不是「从零学小程序」而是「拿到一套能跑通的活动积分系统知道怎么改、怎么部署、怎么避开重复提交和积分并发这些坑」。适合有基础前端或后端经验、需要快速交付内部活动系统的开发者也适合想拿一个完整前后端分离项目练手的人。下面按「先跑通、再改业务、最后防翻车」的顺序拆开讲。2. 先看清这套源码的技术栈与目录结构拿到一个 zip 包最忌讳直接双击打开就改代码。先花十分钟把技术栈和目录结构摸清楚后面部署和改需求能省掉大量返工。企业活动积分小程序这类项目常见组合是微信小程序原生或 uni-app 做前端Node.jsExpress/Koa或 JavaSpring Boot做后端MySQL 存用户、活动、积分流水、奖品兑换记录。标题里写了「完整前后端mysqlLW」LW 一般指论文或设计文档说明这套源码可能来自毕业设计或外包交付代码规范程度参差不齐更需要先做结构审查。2.1 前后端分离的目录长什么样一个典型的前后端分离项目根目录下通常分两大块小程序端和服务器端。小程序端包含 pages、components、utils、api 等目录服务器端包含 routes、controllers、models、config、middleware 等。下面是一个常见的目录骨架你可以对照自己手里的包检查。# 典型目录结构以 Node.js 后端为例 project-root/ ├── miniprogram/ # 微信小程序前端 │ ├── pages/ │ │ ├── index/ # 首页活动列表 │ │ ├── activity/ # 活动详情签到、答题 │ │ ├── points/ # 积分明细 │ │ └── exchange/ # 奖品兑换 │ ├── api/ # 接口封装 │ ├── utils/ # 工具函数 │ └── app.json # 全局配置 ├── server/ # 后端服务 │ ├── routes/ # 路由定义 │ ├── controllers/ # 业务逻辑 │ ├── models/ # 数据库模型 │ ├── config/ # 数据库配置 │ └── app.js # 入口文件 ├── sql/ # 数据库脚本 │ └── init.sql # 建表 初始数据 └── README.md先确认三件事小程序端用的是原生还是 uni-app后端是 Node 还是 Java数据库脚本有没有现成的 init.sql。如果 README 写得含糊直接看 app.json 里的页面注册和 server 入口文件的依赖声明比读文档快。2.2 数据库表设计的核心几张表活动积分系统的数据模型不复杂但表设计直接影响后面积分并发和流水追溯。常见做法是至少四张核心表用户表、活动表、积分流水表、奖品兑换表。下面用表格说明每张表的职责和关键字段。表名职责关键字段注意点user存微信用户信息openid、nickname、total_pointsopenid 必须唯一索引activity活动配置title、start_time、end_time、rule时间字段用 datetimepoints_log积分流水user_id、change、reason、created_at只增不改便于对账exchange兑换记录user_id、prize_id、status、created_atstatus 控制发货状态积分流水表是整个系统的黑匣子用户每得一分、扣一分都要落一条记录。很多翻车案例都是因为直接改 user 表的 total_points 而不写流水导致用户投诉时查不到依据。先确认源码里有没有 points_log 这张表没有的话后面一定要补上。2.3 本地跑通的最小步骤在改任何业务之前先让项目在本地跑起来。下面以 Node.js 后端 微信开发者工具为例给出最小启动流程。# 1. 导入数据库 mysql -u root -p sql/init.sql # 2. 配置后端数据库连接 # 编辑 server/config/db.js填入本地 MySQL 地址、用户名、密码 # 3. 安装后端依赖并启动 cd server npm install npm run dev # 4. 小程序端用微信开发者工具打开 miniprogram 目录 # 修改 api/base.js 里的请求地址为本地后端地址启动后先测三个接口获取活动列表、用户签到、查询积分。如果签到接口返回成功但积分没变优先查 points_log 有没有写入再看 user 表的 total_points 有没有更新。这两个动作要么在同一个事务里要么用消息队列补偿否则就是典型的「签到成功但积分丢了」。提示本地调试时微信开发者工具需要勾选「不校验合法域名」否则请求本地后端会被拦截。上线前必须换成备案域名并配置到小程序后台。3. 活动积分核心业务怎么改才不翻车跑通之后真正的工作量在业务改造。企业活动积分小程序的核心逻辑集中在三块签到/答题得分、积分兑换奖品、活动时间控制。这三块每一块都有并发和边界问题改的时候不能只看功能实现要看数据一致性。3.1 签到与答题得分的接口实现签到和答题是最常见的得分场景。签到通常限制每天一次答题可以限制每个活动一次。下面是一个签到接口的简化实现重点看事务和唯一约束。// server/controllers/pointsController.js const db require(../config/db); async function signIn(req, res) { const { userId, activityId } req.body; const today new Date().toISOString().slice(0, 10); const conn await db.getConnection(); try { await conn.beginTransaction(); // 1. 检查今天是否已签到依赖唯一索引兜底 const [exist] await conn.query( SELECT id FROM points_log WHERE user_id? AND reason? AND DATE(created_at)?, [userId, sign_in, today] ); if (exist.length 0) { await conn.rollback(); return res.json({ code: 400, msg: 今天已经签到过了 }); } // 2. 写积分流水 await conn.query( INSERT INTO points_log (user_id, change_points, reason, created_at) VALUES (?, ?, ?, NOW()), [userId, 10, sign_in] ); // 3. 更新用户总积分 await conn.query( UPDATE user SET total_points total_points ? WHERE id ?, [10, userId] ); await conn.commit(); res.json({ code: 0, msg: 签到成功, points: 10 }); } catch (err) { await conn.rollback(); res.json({ code: 500, msg: 签到失败 }); } finally { conn.release(); } }这段代码的关键点有三个。第一用事务包住「写流水」和「更新总分」两个动作任何一步失败都回滚。第二查询是否已签到时用 DATE(created_at) 做日期比较但真正防重复要靠数据库唯一索引比如在 points_log 上建 (user_id, reason, date) 的唯一键否则并发请求会同时通过检查。第三积分变更量用参数传入不要拼接 SQL。答题得分的逻辑类似只是把 reason 换成 answer并增加题目 ID 和正确性校验。3.2 积分兑换的并发扣减与库存控制兑换是比签到更容易出问题的场景。用户积分够、奖品有库存两个条件同时满足才能兑换。如果先查积分再查库存再扣减中间没有锁高并发下会出现超兑。常见做法是用数据库行锁或乐观锁。-- 兑换时用事务 行锁控制库存 START TRANSACTION; -- 锁定奖品行防止其他事务同时扣库存 SELECT stock FROM prize WHERE id ? FOR UPDATE; -- 检查库存 -- 如果 stock 0ROLLBACK 并返回库存不足 -- 扣库存 UPDATE prize SET stock stock - 1 WHERE id ? AND stock 0; -- 扣用户积分 UPDATE user SET total_points total_points - ? WHERE id ? AND total_points ?; -- 写兑换记录 INSERT INTO exchange (user_id, prize_id, status, created_at) VALUES (?, ?, pending, NOW()); COMMIT;这里有两个必须同时满足的条件库存大于零、积分足够。用 FOR UPDATE 锁住奖品行保证同一时间只有一个事务能扣库存。UPDATE 语句里的 stock 0 和 total_points ? 是第二道保险即使锁失效也不会扣成负数。兑换记录先落 pending 状态后续发货再改状态避免用户兑换后查不到记录。3.3 活动时间窗口与状态机活动不是永远开放的start_time 和 end_time 决定了用户能不能参与。很多源码只在前端判断时间后端不校验用户改手机时间就能绕过。正确做法是后端每次请求都校验当前时间是否在活动窗口内。// 活动状态校验中间件 async function checkActivityWindow(req, res, next) { const { activityId } req.body; const [rows] await db.query( SELECT start_time, end_time, status FROM activity WHERE id ?, [activityId] ); if (rows.length 0) { return res.json({ code: 404, msg: 活动不存在 }); } const now new Date(); const { start_time, end_time, status } rows[0]; if (status ! 1) { return res.json({ code: 403, msg: 活动未启用 }); } if (now new Date(start_time) || now new Date(end_time)) { return res.json({ code: 403, msg: 不在活动时间内 }); } next(); }活动状态建议用数字表示0 草稿、1 进行中、2 已结束。后端校验时间窗口和状态前端只做展示。这样即使前端被绕过后端仍然能拦住。时间字段统一用服务器时间不要相信客户端传过来的时间戳。4. 部署上线前必须排查的五个坑本地跑通不等于能上线。企业活动积分小程序上线后会面对真实用户下面五个坑是这类项目最常见的翻车点每一个都按「现象 → 原因 → 解决」写清楚。4.1 签到接口重复提交导致积分翻倍现象用户点一次签到积分加了两次甚至多次。原因前端按钮没有防抖或者网络慢用户连点后端接口没有幂等控制。解决前端按钮点击后立即置灰后端在 points_log 表上建唯一索引 (user_id, reason, DATE(created_at))插入冲突时直接返回已签到。不要只靠查询判断查询和插入之间有并发窗口。4.2 积分总和对不上流水现象用户 total_points 和 points_log 累加结果不一致。原因有的代码直接改 total_points 不写流水或者写流水和改总分不在同一事务。解决所有积分变更必须走同一个函数函数内部先写流水再更新总分用事务包住。上线前跑一次对账 SQL把 user 表和 points_log 做一次全量比对。-- 对账 SQL找出总分和流水不一致的用户 SELECT u.id, u.total_points, IFNULL(SUM(p.change_points), 0) AS log_sum FROM user u LEFT JOIN points_log p ON p.user_id u.id GROUP BY u.id HAVING u.total_points ! log_sum;4.3 小程序请求域名未配置导致线上接口全挂现象开发者工具里一切正常真机预览或上线后所有接口请求失败。原因小程序后台没有配置 request 合法域名或者配置的域名没有 HTTPS。解决上线前在小程序后台「开发管理 → 开发设置 → 服务器域名」里配置后端域名必须 HTTPS 且已备案。本地调试时勾选「不校验合法域名」只对开发者工具有效真机不生效。4.4 MySQL 连接数耗尽导致服务无响应现象活动高峰期接口大面积超时重启后端后短暂恢复又挂。原因数据库连接池配置过小或者有代码获取连接后没有 release。解决检查连接池配置Node.js 常用 mysql2 的 connectionLimit 建议设为 10 到 20根据并发调整。每个 getConnection 必须配 try/finally 里的 release事务回滚后也要 release。用 SHOW PROCESSLIST 看有没有大量 Sleep 连接堆积。4.5 活动结束后用户仍能兑换现象活动 end_time 已过用户还能提交兑换。原因兑换接口没有复用活动时间校验中间件或者只在前端隐藏了入口。解决所有涉及活动的写接口都挂上 checkActivityWindow 中间件包括签到、答题、兑换。前端隐藏入口只是体验优化不是安全措施。5. 用对账脚本和压测把积分系统验到放心上线前最后一件事不是再读一遍代码而是用数据验证。积分系统最怕的不是功能少而是账对不上。我一般会写一个对账脚本每天定时跑一次把 user 表的 total_points 和 points_log 的累加值做比对不一致就告警。这个脚本本身不复杂但能挡住绝大多数积分异常。-- 每日对账输出不一致用户供人工核查 SELECT u.id AS user_id, u.total_points AS user_total, IFNULL(SUM(p.change_points), 0) AS log_total, u.total_points - IFNULL(SUM(p.change_points), 0) AS diff FROM user u LEFT JOIN points_log p ON p.user_id u.id GROUP BY u.id HAVING diff ! 0;除了对账压测也不能省。用简单的并发脚本模拟 50 个用户同时签到和兑换观察三个指标接口响应时间、积分流水条数、库存扣减结果。如果签到接口在并发下出现重复流水说明唯一索引没建对如果库存扣成负数说明行锁没生效。压测不需要复杂工具一个 for 循环加并发请求就能暴露大部分问题。验证项方法通过标准签到幂等并发 50 次同一用户签到points_log 只增 1 条积分对账跑对账 SQLdiff 全为 0库存扣减并发兑换同一奖品stock 不小于 0活动时间改服务器时间到活动外接口返回 403连接释放压测后 SHOW PROCESSLIST无大量 Sleep 连接最后说一个我自己的习惯每次改完积分相关代码先不急着提交而是把对账 SQL 跑一遍再手动造几条异常数据看能不能查出来。这个习惯帮我挡过好几次「看起来没问题」的改动。企业活动积分小程序这类项目功能不难难的是数据一致性把对账和压测做扎实后面运营才敢放心发积分。希望帮到你。本文还有配套的精品资源点击获取