简介面向计算机相关专业毕业生的投票评选系统小程序毕业设计项目包含微信小程序前端、SSM后端与MySQL数据库完整源码并附演示视频可直观了解项目运行效果。项目由个人大四完成经导师评审认可得分99分代码完整可运行适合正在准备毕业设计、课程设计或期末大作业的学生同样适合需要JavaWeb实战练手的学习者。压缩包共881个文件、36.45MB主要类型包括png/svg/jpg前端页面与图标、vue/js前端逻辑、java后端实现、sql数据库脚本、xml/yml配置以及mp4操作演示视频目录结构清晰便于按模块定位代码。当前页面已有178人浏览学习。通过该资源可快速掌握微信小程序与SSM整合、投票评选业务数据库设计与前后端交互全流程理解投票活动、结果统计等典型业务源码与视频结合能有效支撑毕设开发与项目经验积累。1. 微信小程序SSMMySQL 的投票评选系统为什么它是少有的“稳”型毕设「微信小程序 SSM MySQL 的投票评选系统」这个毕设题目看起来不起眼但它在答辩现场的通过率往往比那些标题很唬人的题目高得多。原因在于它的业务边界特别清楚——谁能登录、谁能投票、投给谁、票数怎么展示四件事说清整个系统的骨架就出来了。业务范围小意味着你不需要处理订单、支付、库存这类复杂状态可以把每一层都做扎实。这类题目的价值在于三层链路完整小程序做表现层SSM 做接口与业务规则MySQL 做持久化。答辩老师习惯从任意一层切入提问你能答上来分数就不会低。它适合两类人一类是学校课程用了 SSM 技术栈、想顺着课程基线完成毕设的同学另一类是想要一个完整项目把 Java Web 链路串起来的初学者。下面按我做模拟项目X时的落地顺序讲选型理由、数据库与接口实现、小程序端闭环、避坑清单、答辩加分技巧五步把从零到高分的路径走完。2. SSMMySQL 这套组合为什么毕设选它而不是更“新”的解决方案先回答一个几乎所有拿这个题目的同学都会问的问题市面上 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/9MySQL 5.7 或 8.0 都可以注意 MySQL 版本要和 Maven 里引入的驱动坐标对应。数据源配置是这个阶段最容易出错的地方我一般把它单独放在 jdbc.properties 里不写死在 XMLjdbc.drivercom.mysql.cj.jdbc.Driver jdbc.urljdbc:mysql://localhost:3306/vote_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai jdbc.usernameroot jdbc.password你的密码参数说明characterEncodingutf8 解决中文乱码不配置的话候选人姓名和用户昵称很容易在写入时变成问号serverTimezoneAsia/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再补 MavenJava 和前端语法一边写代码一边巩固比从头啃教材快得多。真实开发里大多数同学卡住不是卡在语法而是卡在“环境不对、配置没生效、接口返回看不懂”这老三样上。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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 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 原样带上如果漏带后端要能识别为未登录第三个看排行榜是否按票数降序。把同一个投票请求原样重放一次返回值应当是“已投过票”这一步能立刻验证唯一索引在真实请求里起了作用。请求操作期望结果失败时看哪里首次登录返回 tokenuser 表新增一行Controller 路径、日志输出正常投票返回最新票数比原来 1Service 异常、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 作 keysetData 支持字符串路径单独更新某一项 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不会触发整个列表重渲染。投票成功的票数更新用后端返回的最新值而不是本地自增原因是后端的计数才是一致性来源如果两个用户同时在投同一个候选人本地自增显示的数字很快就会和真实票数脱节。后端返回 code0 表示成功其余都按失败处理把 msg 直接透出给用户。这里必须强调前端按钮的禁用状态和本地校验只是体验优化真正拦截重复投票的必须是后端唯一索引。如果你指望前端 disable 就能防刷票有人用接口调试工具重放请求你的票数就会无限上涨。这个点答辩时一定会被问到提前想好怎么说。4.3 排行榜让 MySQL 排好序小程序只负责渲染排行榜有一个常见误区把候选人列表拉回来在前端用 JS 排一下序。数据量小的时候看不出问题但票数相同的候选人顺序会因数组初始顺序而漂移每次刷新位置可能都不一样。正确做法是把排序逻辑写在后端 SQL 里小程序拿到什么就渲染什么。select idselectRanking resultTypemap 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 连接串里要加 serverTimezoneAsia/Shanghai否则日期会差 8 小时这也是时间字段常见的错位来源。6. 从“能跑”到“高分”答辩演示的 4 个加分技巧代码能用只是及格线。这类题目最终的分数差距几乎都体现在演示环节能不能讲出“为什么这么设计”。下面 4 个技巧不需要大改代码但对答辩观感影响很大录视频演示时也可以按这个顺序来。6.1 给投票加一个时间窗让“规则”看得见在活动或候选人维度加 start_time、end_time 两个字段Service 在投票前判断当前时间是否在窗口内不在就直接拒绝。演示的时候把结束时间改成过去现场点投票小程序弹“评选已结束”——这个动作就证明了业务规则在服务端执行而不是前端写死的页面逻辑。时间窗口也顺带解决了“评选结束后还在收票”的争议。6.2 把“防重复投票”做成一个演示脚本答辩当天不要只演示正常流程准备一个重放脚本第一次投票成功紧接着原样重放请求界面提示“已投过票”。这个演示只需要十秒却能同时覆盖唯一索引、事务、异常捕获三个技术点是这套系统里性价比最高的展示方式。提前在接口调试工具里准备好请求别现场敲命令答辩环境里网络和工具都可能不给面子。6.3 结果页加一张占比图用图表库在结果页画一个票数占比饼图数据来源是后端提供的统计接口。饼图不复杂重点在于你能讲清楚为什么不在前端算占比——展示层的计算和统计口径都要以后端数据为准前端只做可视化。这张图本身也是“前后端分离”最好的可视化证明比口头解释有力得多。6.4 按“表结构 → 接口 → 页面”来安排演示顺序常见的演示顺序是打开小程序一顿点最后象征性展示代码。更好的顺序是倒过来先打开数据库管理工具展示三张表和唯一索引再打开接口文档展示登录和投票的返回值最后在小程序里跑正常流程。这个顺序的真正价值是让评委跟着你的思路走而不是自己在代码里猜你做了什么每一层都能对上前面讲过的设计理由答辩节奏自然就顺了。我自己在这类项目上吃过亏。第一次做模拟项目X的时候功能堆得不少但评委问“唯一索引建在哪、为什么用事务”时我在工程里翻了好几分钟才找到位置场面一度很安静。后来我养成一个习惯每个核心功能写完后用三行注释回答三个问题——这段代码在防什么、如果把这段去掉会怎样、有没有更省事的替代方案。这三个问题想清楚答辩基本不会冷场。这个习惯后来也帮我在多个项目里少走了不少弯路希望帮到你。本文还有配套的精品资源点击获取
