简介：面向计算机相关专业毕业生的投票评选系统小程序毕业设计项目，包含微信小程序前端、SSM后端与MySQL数据库完整源码，并附演示视频，可直观了解项目运行效果。项目由个人大四完成，经导师评审认可，得分99分，代码完整可运行，适合正在准备毕业设计、课程设计或期末大作业的学生，同样适合需要JavaWeb实战练手的学习者。压缩包共881个文件、36.45MB，主要类型包括png/svg/jpg前端页面与图标、vue/js前端逻辑、java后端实现、sql数据库脚本、xml/yml配置以及mp4操作演示视频，目录结构清晰，便于按模块定位代码。当前页面已有178人浏览学习。通过该资源可快速掌握微信小程序与SSM整合、投票评选业务数据库设计与前后端交互全流程，理解投票活动、结果统计等典型业务，源码与视频结合，能有效支撑毕设开发与项目经验积累。
1. 微信小程序+SSM+MySQL 的投票评选系统：为什么它是少有的“稳”型毕设
「微信小程序 + SSM + MySQL 的投票评选系统」这个毕设题目看起来不起眼，但它在答辩现场的通过率，往往比那些标题很唬人的题目高得多。原因在于它的业务边界特别清楚——谁能登录、谁能投票、投给谁、票数怎么展示，四件事说清，整个系统的骨架就出来了。业务范围小，意味着你不需要处理订单、支付、库存这类复杂状态，可以把每一层都做扎实。
这类题目的价值在于三层链路完整：小程序做表现层，SSM 做接口与业务规则，MySQL 做持久化。答辩老师习惯从任意一层切入提问，你能答上来，分数就不会低。它适合两类人：一类是学校课程用了 SSM 技术栈、想顺着课程基线完成毕设的同学；另一类是想要一个完整项目把 Java Web 链路串起来的初学者。
下面按我做模拟项目X时的落地顺序讲：选型理由、数据库与接口实现、小程序端闭环、避坑清单、答辩加分技巧，五步把从零到高分的路径走完。
2. SSM+MySQL 这套组合：为什么毕设选它而不是更“新”的解决方案
先回答一个几乎所有拿这个题目的同学都会问的问题：市面上 Spring Boot 明显更流行，为什么不直接用？原因不是 Spring Boot 不好，而是毕设答辩的评分逻辑和公司项目不一样。大多数学校的 Java 课程还是把 Spring、SpringMVC、MyBatis 分开讲的，老师对这套配置链路最熟悉。你用 SSM，每一个 XML 配置、每一个注解都能成为讲清楚的设计点；换成 Spring Boot 后很多环节被自动装配吞掉了，老师追问“容器到底怎么起来的”时，反而拿不出手。
微信云开发则是另一个常见的诱惑。它确实能把开发速度提上去，但背后是文档型数据库，不是题目要求的 MySQL。更重要的是，云开发把后端很大一部分细节变成了托管服务，你写过的 SQL 和事务就少了，答辩时能展示的技术密度自然下降。我在某高校旁听答辩时见过 A同学用云开发做的类似项目，老师问“你的 MySQL 表结构在哪”，他只能说平台托管，场面有点被动。所以这道题按字面意思做——小程序 + SSM + MySQL 三层自己搭，才是正路。
提示：如果你所在学校课程已经明确改成 Spring Boot 主线，那就以课程要求为准。这里所有讨论都基于题目里写了 SSM 的情况。
2.1 三层架构在小程序场景下的真实分工
很多同学第一次接触这个题目时，以为小程序就是“前端”，SSM 是“后台管理系统”，其实不够准确。小程序代码承担的是用户端的页面渲染与交互，SSM 后端是独立部署的 HTTP 服务，只输出 JSON 接口，MySQL 负责数据的写入与查询。用户的每次投票动作，本质是一次携带身份信息的 POST 请求。
| 层 | 承载者 | 在这个投票系统里的具体职责 |
|---|---|---|
| 表现层 | 微信小程序原生框架 | 候选人列表渲染、投票按钮交互、排行榜展示、登录态缓存 |
| 接口层 | SpringMVC Controller | 接收请求、校验参数、调用 Service、统一返回结构 |
| 业务层 | Spring Service | 投票规则、防重复约束、事务边界、时间窗判断 |
| 数据层 | MyBatis + MySQL | 用户、候选人、投票记录三张表的读写与查询 |
把这个分工记牢，后面所有代码都围绕“每层只干自己那件事”展开。答辩时老师常问“为什么 Controller 里不直接写 SQL”，你可以回答：业务规则和持久化分离，既能单独测试 Service，也方便以后替换投票规则而不动表结构。由小程序直接拼 SQL 调数据库，那是这个题目绝对不能碰的雷区——微信前端代码天然暴露给用户，等于把数据库口令挂在门上。
2.2 对比完 Spring Boot 和云开发，再看 SSM 的实际成本
SSM 的第一个成本是配置。以 Maven 的 Web 工程为例，你需要维护 pom.xml 里的依赖坐标，spring-mvc.xml 里的组件扫描与拦截器注册，mybatis-config.xml 里的别名与映射，还有 web.xml 里 DispatcherServlet 的挂载。常见做法是先用 IDEA 的模板建一个最小工程，逐个文件看懂后再加业务代码，不要一次拷贝一堆配置然后祈祷它能跑。真正写业务之前，先实跑一个返回 Hello 的接口，把环境问题一次清完，后面写投票功能时就会顺很多。
第二个成本是运行环境。最常见的一套搭配是 JDK 1.8 配合 Tomcat 8/9，MySQL 5.7 或 8.0 都可以，注意 MySQL 版本要和 Maven 里引入的驱动坐标对应。数据源配置是这个阶段最容易出错的地方，我一般把它单独放在 jdbc.properties 里，不写死在 XML：
jdbc.driver=com.mysql.cj.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/vote_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai jdbc.username=root jdbc.password=你的密码参数说明：characterEncoding=utf8 解决中文乱码，不配置的话候选人姓名和用户昵称很容易在写入时变成问号；serverTimezone=Asia/Shanghai 解决数据库时区和本地时区不一致导致的 8 小时偏移，时间字段在页面上差 8 小时是这类项目最高频的诡异现象。driver 用 com.mysql.cj.jdbc.Driver 是因为 MySQL 8 里旧的 com.mysql.jdbc.Driver 已经被标记过时，用错了会直接在启动时报驱动类找不到。
2.3 动手前先自测的 5 个基本功
这个题目不难，但前置知识里有一个洞，后面就容易连续熬夜补救。我一般让准备拿这道题的同学先做 5 项自测，每项五分钟能出结果：
- Java 基础：能不能不看资料说出 Spring 管理的 Bean 默认作用域，以及为什么用户 Service 要交给容器统一管理。
- 构建工具：会不会用 Maven 的 clean、package 命令，知不知道 war 包和 jar 包在 Web 部署上的区别。
- MySQL：能不能手写一张带唯一索引的建表语句，理解 InnoDB 下唯一索引与事务各自解决什么问题。
- HTTP：知不知道 200、400、500 分别代表什么，POST 请求里的 JSON 会被 SpringMVC 用什么注解接住。
- 小程序：写没写过 Page 的生命周期，知不知道 setData 是异步渲染、wx.request 是异步回调。
每一项都对应后面代码里的一个环节。第 4 项说不清，你会在参数绑定、跨域、JSON 解析这几个问题上反复折腾；第 5 项说不清，会出现“投票成功但界面没变化”这类看着像玄学的 bug。自测不通过也不用怕，按顺序补：先补 MySQL 和 HTTP，再补 Maven，Java 和前端语法一边写代码一边巩固，比从头啃教材快得多。真实开发里大多数同学卡住，不是卡在语法，而是卡在“环境不对、配置没生效、接口返回看不懂”这老三样上。
3. 先把投票业务定死在数据库里：建表、事务与接口验证
这类项目最容易犯的错是先写页面。候选人列表页面写完了，发现后端给不了你要的格式，回头改前端改到怀疑人生。我一般是倒着做：先把 MySQL 表建好，把后端接口用调试工具全部验证一遍，再动小程序。后端变成可调用的黑匣子之后，前端就只是发请求和渲染结果。
3.1 三张核心表：用户表、候选人表、投票记录表
投票系统的核心约束只有一个：一个用户对同一个候选人只能投一次。能不能把这个约束做对，决定了整个项目的数据可信度。下面三张表是一个最小可用设计，足够支撑单场评选的完整流程。
CREATE TABLE `user` ( `id` INT NOT NULL AUTO_INCREMENT, `openid` VARCHAR(64) NOT NULL COMMENT '微信用户唯一标识', `nickname` VARCHAR(64) DEFAULT '' COMMENT '用户昵称', `avatar_url` VARCHAR(255) DEFAULT '' COMMENT '头像地址', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_openid` (`openid`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表'; CREATE TABLE `candidate` ( `id` INT NOT NULL AUTO_INCREMENT, `name` VARCHAR(64) NOT NULL COMMENT '候选人/评选项名称', `description` VARCHAR(500) DEFAULT '' COMMENT '简介', `image_url` VARCHAR(255) DEFAULT '' COMMENT '展示图片', `vote_count` INT NOT NULL DEFAULT 0 COMMENT '冗余票数，用于排行榜快速查询', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='候选人表'; CREATE TABLE `vote_record` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `user_id` INT NOT NULL COMMENT '用户表主键', `candidate_id` INT NOT NULL COMMENT '候选人表主键', `vote_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_user_candidate` (`user_id`, `candidate_id`), KEY `idx_candidate_id` (`candidate_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='投票记录表';说明：user 表的 openid 是微信生态里识别用户的唯一凭证，必须建唯一键，否则同一个微信用户重复登录会落多行脏数据。vote_record 的联合唯一索引是防重复投票的第一道闸，数据库层面的约束永远比代码判断可靠。candidate 表里的 vote_count 是刻意保留的冗余字段，用来让排行榜查询直接走索引排序，而不是每次临时统计整张记录表；代价是每次投票后必须保证两张表同步更新，这一步由后续事务承担。
字符集用 utf8mb4 而不是 utf8，是因为用户昵称里可能出现表情符号，utf8 存不下这类四字节字符，写入时会直接报错。如果一场评选下有多个活动，可以再加 activity 表，让候选人和投票记录都挂 activity_id；但单场评选用这三张表已经足够，不要一开始就过度设计。
3.2 投票接口：用事务 + 唯一索引把并发场景锁住
投票接口是系统的核心业务，实现上有一个顺序问题：先插记录还是先判断是否存在？常见的错误写法是先 SELECT 一次看有没有投过，再 INSERT。这在单用户场景下没问题，但两个请求同时进来时，两次 SELECT 都查不到记录，然后都执行 INSERT，最终数据就多了两条。正确做法是让唯一索引去拦截，只要捕获到重复键异常，就等价于“投过了”。
@Override @Transactional(rollbackFor = Exception.class) public VoteResult vote(Integer userId, Integer candidateId) { User user = userMapper.selectById(userId); Candidate candidate = candidateMapper.selectById(candidateId); if (user == null || candidate == null) { return VoteResult.fail("用户或评选项不存在"); } try { // 唯一索引 (user_id, candidate_id) 在这里兜底，插入重复直接抛异常 voteRecordMapper.insert(new VoteRecord(userId, candidateId)); } catch (DuplicateKeyException e) { return VoteResult.fail("您已经投过票，不能重复投"); } // 冗余计数用 UPDATE 自增，避免并发下读改写互相覆盖 candidateMapper.increaseVoteCount(candidateId); Integer latest = candidateMapper.selectById(candidateId).getVoteCount(); return VoteResult.success(latest); }@Update("UPDATE candidate SET vote_count = vote_count + 1 WHERE id = #{candidateId}") int increaseVoteCount(Integer candidateId);逻辑说明：先插投票记录、失败就返回，是让唯一索引成为判定依据；再更新冗余票数，两条 SQL 放在同一个事务里，要么都成功要么都失败。@Transactional 是事务边界的注解，rollbackFor 指定发生任何异常都回滚，否则可能出现“记录插上了但票数没加上”的数据不一致。增加票数用 UPDATE 自增而不是先查后改，是为了避免两个请求同时读到同一个旧值、各自加一写回导致的丢更新。
参数层面还需要注意：userId 和 candidateId 在 Controller 里要做非空校验，candidateId 为 null 时直接返回参数错误，不要让无效请求走进事务。插入失败也不止重复键一种情况，候选人被删了、外键约束失败都会抛异常，这里统一按“投票失败”返回即可，不要只 catch 重复键就以为所有边界都覆盖了。返回给前端的 VoteResult 建议设计成 code、msg、data 三个字段，前端只需要判断 code 是否为 0。
3.3 接口调试：三个请求确认后端闭环
后端代码写完，用接口调试工具做一组最小验证。先登录拿身份，再投票，再查排行榜。第一次联调时用 curl 最快，三步就能跑通：
# 1. 登录（本地联调阶段后端先按 test_code 生成一个固定用户） curl -X POST http://localhost:8080/api/user/login \ -H "Content-Type: application/json" \ -d '{"code": "test_code_001"}' # 2. 投票（带上第 1 步返回的 token，没有身份会被后端拦截） curl -X POST http://localhost:8080/api/vote \ -H "Content-Type: application/json" \ -H "token: 上一步返回的token" \ -d '{"candidateId": 1}' # 3. 查排行榜 curl -X GET http://localhost:8080/api/ranking三个请求分别验证三件事。第一个请求确认登录链路通，能看到后端返回 token 或 userId；第二个把返回值里的 token 原样带上，如果漏带，后端要能识别为未登录；第三个看排行榜是否按票数降序。把同一个投票请求原样重放一次，返回值应当是“已投过票”，这一步能立刻验证唯一索引在真实请求里起了作用。
| 请求操作 | 期望结果 | 失败时看哪里 |
|---|---|---|
| 首次登录 | 返回 token，user 表新增一行 | Controller 路径、日志输出 |
| 正常投票 | 返回最新票数，比原来 +1 | Service 异常、SQL 报错 |
| 重放同一投票 | 返回“已投过票” | 唯一索引是否建上 |
| 查排行榜 | 按票数降序排列 | XML 里 ORDER BY 是否生效 |
这套验证集跑通后，后端部分就基本稳定了，可以把注意力完全放到小程序端。
4. 小程序端三段代码：登录、投票、排行榜的闭环
后端就绪后，小程序的开发量其实不大，核心动作就三个：登录拿 token、带 token 投票、拉取排行榜。下面按原生小程序框架给三段可以直接改的代码，没有引入第三方库。
4.1 登录闭环：wx.login 拿 code，后端换 openid，前端存 token
微信小程序不能像网页那样直接读用户身份，标准流程是：小程序先调 wx.login 拿一个临时 code，把 code 发给自己的后端，后端拿 code 向微信接口换取 openid，再把这个 openid 写到自己的 user 表里。注意 code 只能用一次，5 分钟过期，所以每次冷启动都要重新走这个流程。
// pages/index/index.js Page({ data: { token: '', userId: 0 }, async onLoad() { // 1. wx.login 拿临时 code，这个 code 是单次有效的 const { code } = await wx.login(); // 2. 把 code 交给自己的后端，而不是直接拿它当身份 const res = await wx.request({ url: 'http://localhost:8080/api/user/login', method: 'POST', data: { code } }); // 3. 后端返回自定义登录态，存到本地 Storage wx.setStorageSync('token', res.data.token); wx.setStorageSync('userId', res.data.userId); this.setData({ token: res.data.token, userId: res.data.userId }); } });逻辑说明：wx.login 是微信提供的登录入口，不弹授权框，也不需要用户手动同意。后端登录接口里拿 code 换 openid 的过程，对小程序端不可见，所以前端只关心“后端给没给我 token”。本地联调阶段，如果还没申请正式的小程序账号或不想配置密钥，常见做法是后端先写死一个测试用户：看见 code 不为空就直接返回固定 token，等上线前再换成真实换取逻辑，这样不会阻塞前端开发。
参数说明：url 指向后端地址，真机预览时这里不能写 localhost，要写电脑在局域网里的 IP；上线时换成 HTTPS 域名。token 是后端自己定义的业务标识，可以是一段带过期时间的字符串，存 Storage 是为了小程序冷启动后不用每次都重新登录。如果登录接口返回 401，全局可以做一个统一处理，清掉本地 token 并跳转回登录页。
4.2 投票交互：点击 → 本地校验 → 携 token 请求 → 更新界面
投票按钮的交互有几个容易被忽略的点：点击后要先判断本地是否已投过，避免无效请求；请求要带上 token 让后端识别用户；成功后更新界面要有依据，不能盲目把票数加一。
async onTapVote(e) { const candidateId = e.currentTarget.dataset.id; // 本地先校验，避免把无效请求发到后端 if (this.data.votedMap[candidateId]) { wx.showToast({ title: '您已经投过票', icon: 'none' }); return; } const res = await wx.request({ url: 'http://localhost:8080/api/vote', method: 'POST', header: { token: wx.getStorageSync('token') }, data: { candidateId } }); if (res.data.code === 0) { // votedMap 用候选人 id 作 key，setData 支持字符串路径单独更新某一项 this.setData({ [`votedMap.${candidateId}`]: true }); // 票数以接口返回的最新值为准，不搞本地自增 const list = this.data.candidateList.map(item => { if (item.id === candidateId) { return { ...item, vote_count: res.data.voteCount }; } return item; }); this.setData({ candidateList: list }); wx.showToast({ title: '投票成功', icon: 'success' }); } else { wx.showToast({ title: res.data.msg || '投票失败', icon: 'none' }); } }逻辑说明：votedMap 是页面 data 里的普通对象，用 setData 的字符串路径语法可以只更新某一个 key，不会触发整个列表重渲染。投票成功的票数更新用后端返回的最新值，而不是本地自增，原因是后端的计数才是一致性来源；如果两个用户同时在投同一个候选人，本地自增显示的数字很快就会和真实票数脱节。后端返回 code=0 表示成功，其余都按失败处理，把 msg 直接透出给用户。
这里必须强调：前端按钮的禁用状态和本地校验只是体验优化，真正拦截重复投票的必须是后端唯一索引。如果你指望前端 disable 就能防刷票，有人用接口调试工具重放请求，你的票数就会无限上涨。这个点答辩时一定会被问到，提前想好怎么说。
4.3 排行榜：让 MySQL 排好序，小程序只负责渲染
排行榜有一个常见误区：把候选人列表拉回来，在前端用 JS 排一下序。数据量小的时候看不出问题，但票数相同的候选人顺序会因数组初始顺序而漂移，每次刷新位置可能都不一样。正确做法是把排序逻辑写在后端 SQL 里，小程序拿到什么就渲染什么。
<select id="selectRanking" resultType="map"> SELECT id, name, image_url, vote_count FROM candidate WHERE status = 1 ORDER BY vote_count DESC, id ASC </select>排序参数说明：ORDER BY 先按 vote_count 降序，票数一样时按 id 升序，保证任何时刻查询出来的顺序都是确定的，不会出现刷新一次换一个位置的情况。WHERE status = 1 是配合逻辑删除用的，候选人被下架后直接排除在排行榜外，历史投票记录却还在，方便以后做数据统计。
小程序端渲染这段不需要任何排序逻辑，直接用 WXML 的 wx:for 循环输出，前三条可以加一个序号样式做视觉区分。页面可以考虑加下拉刷新，因为 wx.request 是异步的，用户投票后排行榜要及时反映最新结果。如果后续要展示票数占比，就在后端再提供一个统计接口，返回总票数和各候选人票数，前端再画图表，不要在页面里拿数组重新把所有数字算一遍——这又是把后端该干的活搬到了前端。
5. 避坑指南：投票评选小程序最常踩的 5 个翻车点
前面是正向路径，这一章是反向排雷。下面 5 个问题是我带模拟项目X时反复看到、自己也踩过的，每一条都按“现象 → 原因 → 解决”来写。
5.1 模拟器正常、真机全挂：域名校验和局域网网段一起查
现象：小程序开发者工具里一切正常，一换成真机预览，所有请求都走进 wx.request 的 fail 回调，一个接口都通不了。
原因：开发者工具默认关闭了微信的合法域名校验，而真机预览会校验；另一个隐藏原因是手机访问 localhost 指向的是手机自己，不是开发电脑，网络层就直接失败了。
解决：本地联调阶段，在开发者工具的详情设置里勾选“不校验合法域名”，同时把请求地址从 localhost 改成电脑的局域网 IP，保证手机和电脑连同一个网络。如果改了 IP 还不行，先检查电脑防火墙是不是挡了 Tomcat 的 8080 端口。上线前则必须把后端放到配置了 HTTPS 的域名下，并在小程序后台把该域名加入 request 合法域名列表，这是微信对生产环境的硬性要求，没有任何绕过空间。
5.2 后端拿不到用户身份：小程序默认不带 Cookie，别指望 Session
现象：后端登录接口能通，但投票接口总是报“用户不存在”，明明刚登录过。
原因：小程序发起的 wx.request 不会像浏览器那样自动维持 Session，后端用 HttpSession 存用户状态时，下一次请求很可能拿不到对应会话，于是每次都成了匿名用户。
解决：放弃 Session，改用自定义 token。登录成功时后端生成一串 token 返回给前端，前端存在 Storage 里，之后每个请求在 header 里带 token，后端写一个拦截器统一解析，解析失败就返回 401 让前端重新登录。token 里可以只存 userId，也可以带上过期时间做失效控制。这是小程序后端最通用的身份方案，也方便后续给管理员单独发一种高权限 token。
5.3 前端禁了按钮，接口还能重复投票：防重必须落在后端
现象：小程序里投过一次后按钮置灰，但用接口调试工具重放同一个投票请求，每次都能成功，票数不断上涨。
原因：按钮置灰只是前端体验，接口本身没有约束“同一用户对同一候选人只能投一次”，所有请求都被当成了有效请求。
解决：把防重放到数据库和事务层，也就是 3.2 写的唯一索引加 DuplicateKeyException 捕获。这个场景建议在答辩时主动演示：先正常投票成功，再原样重放一次请求，展示后端拦截的返回结果。能主动讲清楚“前端不可信、后端才是边界”，在评委眼里是明显的加分信号，因为很多人做的投票系统恰恰就是被这个漏洞刷爆票的。
5.4 删除候选人后排行榜总数对不上：关联数据要一起处理
现象：管理员把某个候选人删掉之后，候选人列表里没他了，但统计总票数时数字还是很大，甚至比候选人票数总和还多。
原因：删除候选人时只删了 candidate 表那一行，vote_record 表里的投票记录还留在原地，这些孤儿记录在汇总统计时被算了进去。
解决：正式项目里少用物理删除，常见做法是给 candidate 表加一个 status 字段，默认 1 表示展示，删除时改成 0，查询和统计都加 WHERE status = 1。如果确实要物理删，就同时执行 delete from vote_record where candidate_id = ?，并且放在同一个事务里。逻辑删除的好处是历史数据还在，以后做“已结束评选”之类的功能也能复用同一张表。
5.5 时间字段在小程序里变成一长串数字：JSON 序列化格式要统一
现象：create_time 字段返回给小程序后显示成 1690000000000，前端拿到后一脸茫然，直接把它当字符串渲染。
原因：Jackson 默认把 java.util.Date 序列化成时间戳毫秒数，小程序端拿到的是一个数字，不是预期的日期字符串。
解决：在返回结构里统一用格式化后的字符串。常见做法是建一个统一返回对象，时间字段用 String 接收，Service 层在写值时就格式化成 yyyy-MM-dd HH:mm:ss；或者在 SpringMVC 里配置全局的日期转换，让所有 Date 都以固定格式输出。另外 MySQL 连接串里要加 serverTimezone=Asia/Shanghai，否则日期会差 8 小时，这也是时间字段常见的错位来源。
6. 从“能跑”到“高分”：答辩演示的 4 个加分技巧
代码能用只是及格线。这类题目最终的分数差距，几乎都体现在演示环节能不能讲出“为什么这么设计”。下面 4 个技巧不需要大改代码，但对答辩观感影响很大，录视频演示时也可以按这个顺序来。
6.1 给投票加一个时间窗，让“规则”看得见
在活动或候选人维度加 start_time、end_time 两个字段，Service 在投票前判断当前时间是否在窗口内，不在就直接拒绝。演示的时候把结束时间改成过去，现场点投票，小程序弹“评选已结束”——这个动作就证明了业务规则在服务端执行，而不是前端写死的页面逻辑。时间窗口也顺带解决了“评选结束后还在收票”的争议。
6.2 把“防重复投票”做成一个演示脚本
答辩当天不要只演示正常流程，准备一个重放脚本：第一次投票成功，紧接着原样重放请求，界面提示“已投过票”。这个演示只需要十秒，却能同时覆盖唯一索引、事务、异常捕获三个技术点，是这套系统里性价比最高的展示方式。提前在接口调试工具里准备好请求，别现场敲命令，答辩环境里网络和工具都可能不给面子。
6.3 结果页加一张占比图
用图表库在结果页画一个票数占比饼图，数据来源是后端提供的统计接口。饼图不复杂，重点在于你能讲清楚为什么不在前端算占比——展示层的计算和统计口径都要以后端数据为准，前端只做可视化。这张图本身也是“前后端分离”最好的可视化证明，比口头解释有力得多。
6.4 按“表结构 → 接口 → 页面”来安排演示顺序
常见的演示顺序是打开小程序一顿点，最后象征性展示代码。更好的顺序是倒过来：先打开数据库管理工具展示三张表和唯一索引，再打开接口文档展示登录和投票的返回值，最后在小程序里跑正常流程。这个顺序的真正价值是让评委跟着你的思路走，而不是自己在代码里猜你做了什么；每一层都能对上前面讲过的设计理由，答辩节奏自然就顺了。
我自己在这类项目上吃过亏。第一次做模拟项目X的时候，功能堆得不少，但评委问“唯一索引建在哪、为什么用事务”时，我在工程里翻了好几分钟才找到位置，场面一度很安静。后来我养成一个习惯：每个核心功能写完后，用三行注释回答三个问题——这段代码在防什么、如果把这段去掉会怎样、有没有更省事的替代方案。这三个问题想清楚，答辩基本不会冷场。这个习惯后来也帮我在多个项目里少走了不少弯路，希望帮到你。
本文还有配套的精品资源，点击获取
