微信小程序投票系统毕业设计：SpringBoot+MySQL全栈解析

简介：一份基于微信小程序的投票系统毕业设计论文，面向计算机相关专业即将完成毕设的学生，尤其适合以小程序开发或投票类系统为课题的读者参考。论文以Uni-weixin与Springboot框架为技术主线，完整覆盖了研究背景、技术选型、数据库设计、功能模块划分、开发环境搭建以及系统测试等环节，所涉及的投票信息存储、用户管理、结果统计与查询等设计细节，能为类似系统的开发提供直接参考。压缩包内共1个docx文档，约5.31MB，包含论文摘要、关键词、目录及完整正文，目录结构清晰，便于按章节阅读与引用。目前已有119人学习，这份资料的价值在于既呈现了从需求分析到安全性能测试的完整流程，也指出了系统的不足与改进方向，可帮助读者快速理清毕业设计论文的写作框架与实现路径。

1. 微信小程序投票系统毕业设计资源：这份论文文档到底能帮你省多少事

如果你正在做微信小程序方向的毕业设计，又在为“投票系统”这种选题发愁，这份名为“毕业设计论文基于微信小程序的投票系统.docx”的完整论文文档，值得先花十分钟通读一遍。它不只是一篇范文，而是一整套可复用的技术方案：从微信开发者工具的使用、小程序目录结构，到 SpringBoot 服务端、MySQL 数据库表设计，再到功能测试、性能测试和安全测试，全流程都覆盖了。你拿到的是一份“论文正文 + 数据库设计 + 系统实现思路”三位一体的资源，尤其适合需要快速把毕设系统做出原型、又要写清楚技术细节的同学。我拆完这份文档后的感受是：选题思路清晰，模块划分标准，表结构可以直接拿来改，省掉的不只是写论文的时间，还有前期试错成本。

2. 技术选型与架构分析：为什么是 SpringBoot + 微信小程序 + MySQL 这套组合

2.1 微信开发者工具与小程序目录结构：先搞懂四件套再动手

论文里第一次提到的关键点是微信开发者工具。它和传统网页开发的一个本质区别是：小程序代码不能在浏览器里直接跑，不能使用 Document、Window 这类浏览器对象。你写的页面逻辑跑在微信提供的运行环境里，渲染方式也不同于普通 HTML5 页面的加载流程。这就意味着，如果你之前是写 Web 前端的，第一步要适应的是“项目文件该怎么组织”。

小程序主体由三个文件组成，而且必须放在项目根目录：app.js 负责小程序逻辑，app.json 负责公共配置，app.wxss 负责公共样式表。每个页面又由四个文件组成：js 控制页面逻辑，wxml 描述页面结构，json 做页面级配置，wxss 写页面样式。

project-root/ ├── app.js # 小程序逻辑入口 ├── app.json # 全局配置，包含页面路径、窗口样式 ├── app.wxss # 全局公共样式 ├── pages/ │ ├── index/ │ │ ├── index.js # 首页页面逻辑 │ │ ├── index.wxml # 首页页面结构 │ │ ├── index.json # 首页配置 │ │ └── index.wxss # 首页样式 │ └── vote/ │ ├── vote.js │ ├── vote.wxml │ └── vote.json

这套目录结构是论文里表格内容的直接落地。app.json 里注册页面路径时，第一个路径就是小程序的启动页。我一般会把首页放在第一位，比如 pages/index/index，这样用户打开小程序看到的第一个界面就是作品列表或系统首页。每个页面的 json 文件里可以独立配置标题栏文字，比如投票页的标题就叫“投票中心”，这比在 app.json 里统一设置更灵活。

论文提到的框架是“Uni-weixin”，这是论文里的术语。从实际开发角度看，你既可以用微信原生语法，也可以用跨端框架。原生语法的好处是调试直观、编译产物小，适合毕设这种规模不大的系统。用跨端框架的好处是以后如果有 App 端或 H5 端需求，一套代码多处运行。毕设语境下，我建议优先用原生，因为论文答辩时老师问到底层原理，你回答起来更有底气。

2.2 逻辑层与视图层分离：小程序运行机制的核心认知

论文里给出了一个重要结论：小程序架构由逻辑层和视图层两部分组成，之间靠数据绑定和事件系统通信。逻辑层用 JavaScript 编写，负责数据处理、业务逻辑、网络请求；视图层用 WXML 和 WXSS 编写，负责展示和交互事件采集。

理解这个机制，对调试代码非常关键。比如你在 wxml 里写了{{voteList}}，如果页面没显示数据，问题十有八九出在 js 文件的 data 初始化或 setData 调用上。很多新手会直接操作 DOM 去改页面内容，这在小程序里是无效操作。正确的做法是：

Page({ data: { voteList: [], loading: false, pageNum: 1, pageSize: 10 }, onLoad() { this.fetchVoteList() }, fetchVoteList() { const that = this that.setData({ loading: true }) wx.request({ url: 'http://localhost:8080/api/vote/list', method: 'GET', data: { pageNum: that.data.pageNum, pageSize: that.data.pageSize }, success(res) { if (res.statusCode === 200) { const list = res.data.data.records that.setData({ voteList: list }) } }, fail(err) { console.error('请求失败', err) wx.showToast({ title: '网络异常，请稍后重试', icon: 'none' }) }, complete() { that.setData({ loading: false }) } }) } })

这段代码的逻辑说明：页面加载时调用 onLoad 生命周期函数，触发 fetchVoteList 请求后台接口。拿到数据后通过 setData 更新 voteList，视图层自动重新渲染。参数说明：pageNum 是当前页码，pageSize 是每页条数，这两个参数要和服务端的分页逻辑保持一致。如果后端接口要求从 0 开始分页，这里要对应调整。wx.request 是小程序发网络请求的 API，url 在开发阶段可以用 http://localhost，但上线时必须换成 HTTPS 域名并且在微信公众平台配置合法域名，否则真机预览会直接报错。

这里有一个很实际的坑：小程序的 setData 是异步操作，如果你紧接着读取 this.data.voteList，可能还是旧数据。所以我注释里特意写了每一行在做什么，避免搞混。调试的时候用 console.log 打印 this.data，比打印局部变量更接近真实状态。

2.3 SpringBoot 框架与 B/S 三层架构：服务端为什么选它

论文的技术介绍章节对 SpringBoot 的判断是：自带配置方式、开箱即用、不需要重复样板式配置、不用写 XML。这是 SpringBoot 相比传统 Spring 项目的核心优势。毕设级别的系统，业务复杂度不高，SpringBoot 的自动配置和起步依赖能极大缩短搭建时间。

系统采用 B/S 架构标准的三层架构：表现层、业务层、持久层。表现在小程序端就是页面，业务层是服务端的 Controller、Service，持久层是 Mapper 和数据库交互。这种分层方式的价值在于降低耦合，每一层只干自己该干的事。后面如果要把系统扩展成 PC 管理后台，表现层换掉就行，业务逻辑和数据库代码不用动。

2.4 数据库选型：MySQL 在毕设场景下的优势

论文对 MySQL 的定位是：能处理千万级记录、支持标准 SQL、可移植性高、安装简单、运行效率好、调试管理优化相对简单。这些特点放在毕设场景里，最直接的意义是你不需要花大量时间在环境维护上，更多精力可以放在业务实现。

MySQL 的 root 账号和密码配置，建议在项目配置文件里集中管理。数据表名建议统一小写加下划线，字段名也是，比如questionname、addtime，避免大小写敏感导致的环境差异。

spring: datasource: url: jdbc:mysql://localhost:3306/vote_db?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver

这段配置的说明：jdbc 连接串里的 characterEncoding=utf8 保证中文正常读写，serverTimezone=Asia/Shanghai 避免时区导致的日期字段偏移。密码不要写在代码里硬编码，毕设答辩时老师如果问安全配置，你可以说生产环境会用加密配置中心，这里为了演示方便写在 yml 里。

2.5 Tomcat 运行环境与开发工具链：本地跑起来的最小配置

论文提到服务器用 tomcat7.0，开发环境用 Eclipse，联系之前所学的 web 相关知识设计管理员登录和管理界面。实际动手时要注意，SpringBoot 项目有一个内置 Tomcat，如果你用java -jar方式启动，不需要单独装 Tomcat。论文里写 tomcat7.0 可能是指把 war 包部署到独立 Tomcat 的场景。

如果你用 SpringBoot 打出的是 jar 包，内置 Tomcat 版本是随着 SpringBoot 版本走的。以 SpringBoot 2.x 为例，内置 Tomcat 是 9.x，直接运行即可。需要一个独立 Tomcat 的时候才去配置外部容器，毕设答辩一般不会深究这一个点。Eclipse 和 IDEA 都能开发，IDEA 对 SpringBoot 的支持更友好，社区版免费够用，我推荐 IDEA。

3. 需求分析与数据库设计：从用例图到表结构的关键决策

3.1 用户与管理员双角色用例设计

论文的需求分析章节给出了两个用例图：用户端功能包括首页、作品信息、投票、论坛交流、我的；管理端功能包括系统首页、用户管理、作品分类、作品信息、投票信息管理、论坛交流、投票项目管理、系统管理、投票记录、我的信息。这个功能矩阵透露出一个信息：这不是一个纯投票工具，而是一个带投票业务的作品展示平台。

为什么要这么设计？如果只看“投票”这个动词，用现成的问卷工具就完事了。但毕设系统的价值在于体现业务完整性。增加作品信息展示、论坛交流、用户中心这些模块后，系统就有了内容生态的雏形。管理员可以上架作品，用户浏览作品再投票，论坛里讨论作品，这一套流程下来，系统的数据流、权限控制、前后端交互都丰富了，论文可写的内容也足够。

3.2 E-R 图到表结构的映射方法

论文给出了多个实体图：投票信息、论坛交流、用户信息、作品信息，还有总体的 E-R 关系图，重点展示管理员管理用户、用户查看作品、用户投票信息、查看论坛这几个关系。做数据库设计时，我的习惯是先画 E-R 图，再把实体转成数据表，把关系转成外键或关联表。

从 E-R 图到表的映射，关键有以下几条：

• 一个用户对应多条投票记录，用户表和投票记录表通过 user_id 关联
• 一个作品被多个用户投票，作品表和投票记录表通过 work_id 关联
• 一个管理员管理多个用户，管理员表和用户表是权限级别的差别
• 论坛帖子属于某个用户，通过 user_id 关联用户表

3.3 核心表结构解读：投票项目表、作品信息、记录表

论文的数据库表设计里有几个值得细看的表：投票项目表、作品信息表。投票项目表的字段包括 id、addtime、questionname、options、score、answer、analysis、type、sequence。type 字段的注释特别清楚：0 单选、1 多选、2 判断、3 填空、4 主观题。

下面这个表结构是论文表 4-1 的呈现方式，建议直接用在你的建表脚本里：

这个表结构的设计亮点在于 options 用 longtext 存储 JSON 字符串。你在小程序端解析这个字段时，JSON.parse 就能得到选项数组，不用为每个选项单独建一张表。这个设计对投票系统特别实用，因为单选、多选的选项数量不固定，用 JSON 存储灵活性很高。

作品信息表也同样重要，字段包括作品名称、作品封面、作品分类、作品风格、点击次数、评论数、收藏数、发布日期等。作品封面类型是 longtext，实际是存图片路径，不是二进制图片。这种设计的用意是避免把图片存进数据库，只存 URL，图片文件放服务器本地或对象存储。

3.4 数据库设计的实际落地：建表脚本与初始数据

把论文表结构转成可执行的建表 SQL，是资源落地最重要的一步。下面这个脚本可以直接在 MySQL 里执行：

CREATE TABLE `vote_paper` ( `id` bigint NOT NULL AUTO_INCREMENT COMMENT '主键', `addtime` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `papername` varchar(200) DEFAULT NULL COMMENT '投票信息名称', `questionname` varchar(200) DEFAULT NULL COMMENT '投票项目名称', `options` longtext COMMENT '选项，json字符串', `score` bigint DEFAULT '0' COMMENT '分值', `answer` varchar(200) DEFAULT NULL COMMENT '正确答案', `analysis` longtext COMMENT '答案解析', `type` bigint DEFAULT '0' COMMENT '投票项目类型：0单选 1多选 2判断 3填空 4主观', `sequence` bigint DEFAULT '100' COMMENT '排序值', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='投票项目表'; INSERT INTO `vote_paper` (`papername`, `questionname`, `options`, `score`, `answer`, `analysis`, `type`, `sequence`) VALUES ('最佳作品评选', '你最喜欢哪个作品？', '[{"key":"A","value":"作品一"},{"key":"B","value":"作品二"},{"key":"C","value":"作品三"}]', 5, 'A', '该作品设计理念新颖，色彩搭配协调', 0, 100);

执行这段 SQL 的说明：建表时用 utf8mb4 字符集，因为要考虑用户输入生僻字或表情符号。options 字段里的数据是合法的 JSON，格式是 key-value 数组。插入一条测试数据，方便后面联调小程序端。如果你要支持多选投票，把 type 改成 1，选项一样的存储方式，解析时逻辑略有不同。

建好表后用 Navicat 或命令行工具验证表结构，看字段类型和论文里是否一致。有一点要注意：longtext 的最大长度是 4GB，写 4294967295 是在 MySQL 里的容量上限，实际单字段能存的内容远超过毕设需求，不用担心。

4. 系统实现：投票业务从前端到后端的关键代码落地

4.1 小程序端投票页面：选型、提交与状态管理

投票是小程序端最核心的交互。页面加载时请求题目列表，用户选择选项后点击提交，提交前校验是否已选，提交后展示结果或提示成功。这一套流程在代码层面由三个部分构成：数据渲染、事件处理、状态控制。

下面是投票页的 wxml 结构和 js 逻辑：

<view class="vote-container"> <view class="question-title">{{currentQuestion.questionname}}</view> <view class="option-list"> <view wx:for="{{optionList}}" wx:key="key" class="option-item {{selectedKey === item.key ? 'active' : ''}}" bindtap="onOptionTap" >Page({ data: { paperId: null, currentQuestion: null, optionList: [], selectedKey: '', voting: false }, onLoad(options) { const paperId = options.paperId this.setData({ paperId }) this.fetchQuestion(paperId) }, fetchQuestion(paperId) { wx.request({ url: `http://localhost:8080/api/vote/question?paperId=${paperId}`, method: 'GET', success: (res) => { if (res.statusCode === 200) { const question = res.data.data const options = JSON.parse(question.options) this.setData({ currentQuestion: question, optionList: options }) } } }) }, onOptionTap(e) { const key = e.currentTarget.dataset.key this.setData({ selectedKey: key }) }, submitVote() { const that = this if (!that.data.selectedKey) { wx.showToast({ title: '请先选择一个选项', icon: 'none' }) return } that.setData({ voting: true }) wx.request({ url: 'http://localhost:8080/api/vote/submit', method: 'POST', data: { paperId: that.data.paperId, questionId: that.data.currentQuestion.id, answer: that.data.selectedKey, userId: wx.getStorageSync('userId') }, success(res) { if (res.statusCode === 200) { wx.showToast({ title: '投票成功', icon: 'success' }) setTimeout(() => { wx.navigateBack() }, 1500) } else { wx.showToast({ title: '投票失败', icon: 'none' }) } }, complete() { that.setData({ voting: false }) } }) } })

这段逻辑的说明：点击选项时记录当前选中的 key，并且在样式上让选中项高亮。提交按钮设置了 disabled 绑定，没有选中选项时按钮是灰的，这个细节能避免无效请求。submitVote 里先做本地校验，再发网络请求。data 里携带的 userId 从本地缓存 wx.getStorageSync 获取，前提是登录时已经把 userId 存进去了。

参数说明：paperId 是投票信息的标识，从上一个页面路由带过来；questionId 是当前题目的主键，后端靠这个字段确定用户投的是哪一题。setTimeout 延迟返回是为了让用户看清“投票成功”的提示再跳转，时间设 1500 毫秒比较合适，太短提示一闪而过，太长用户会觉得卡顿。

4.2 服务端投票接口：Controller、Service、Mapper 分层实现

后端接口按 Controller、Service、Mapper 三层结构来组织。Controller 接收小程序端请求，Service 写业务规则，Mapper 操作数据库。投票这个业务，核心逻辑点有两个：检查用户是否已投过，写入投票记录。

@RestController @RequestMapping("/api/vote") public class VoteController { @Autowired private VoteService voteService; @GetMapping("/question") public Result getQuestion(@RequestParam Long paperId) { VotePaper paper = voteService.getQuestionByPaperId(paperId); return Result.success(paper); } @PostMapping("/submit") public Result submit(@RequestBody VoteSubmitDTO dto) { boolean success = voteService.submitVote(dto); if (success) { return Result.success(null, "投票成功"); } return Result.error("您已经投过票了，不能重复提交"); } }

@Service public class VoteServiceImpl implements VoteService { @Autowired private VoteRecordMapper voteRecordMapper; @Autowired private VotePaperMapper votePaperMapper; @Override @Transactional public boolean submitVote(VoteSubmitDTO dto) { // 查重：同一用户同一投票项目只能投一次 int count = voteRecordMapper.countByUserIdAndPaperId(dto.getUserId(), dto.getPaperId()); if (count > 0) { return false; } VoteRecord record = new VoteRecord(); record.setUserId(dto.getUserId()); record.setPaperId(dto.getPaperId()); record.setQuestionId(dto.getQuestionId()); record.setAnswer(dto.getAnswer()); record.setVoteTime(new Date()); voteRecordMapper.insert(record); return true; } }

这段代码的关键点有两个。countByUserIdAndPaperId 是防重复的查询，但请注意，在并发场景下单纯靠 SELECT 再 INSERT 有竞态条件风险，两个请求同时查 count 都返回 0，就会插入两条记录。更稳妥的做法是给用户-投票项目组合添加唯一索引，或者用数据库锁。毕设场景下，先加唯一索引是最简单的保障方式。

@Transactional 注解的作用是让“查重 + 插入”具备事务性，如果插入异常会自动回滚。参数说明：VoteSubmitDTO 是前端提交的数据封装，字段包括 userId、paperId、questionId、answer，用 DTO 而不是直接用 Map 接收的好处是后端可以做参数校验，比如 @NotNull 注解标注必填字段。

4.3 管理员端功能实现：作品管理与投票信息维护

管理员端在论文里是服务端模块，功能包括作品分类、作品信息、投票项目管理、投票记录、论坛交流管理。这些功能本质上是标准的 CRUD 操作，但有一个点值得展开：作品管理中的图片上传与封面存储。

作品封面字段在数据库中用的是 longtext 存储图片路径，所以服务端需要提供一个文件上传接口，把图片保存到服务器本地目录，然后返回可访问的 URL。下面是文件上传的常见实现方式：

@PostMapping("/api/admin/upload") public Result uploadFile(@RequestParam("file") MultipartFile file) { if (file.isEmpty()) { return Result.error("文件不能为空"); } String originalFilename = file.getOriginalFilename(); String ext = originalFilename.substring(originalFilename.lastIndexOf(".")); String serverPath = "/data/upload/"; String fileName = System.currentTimeMillis() + ext; File dest = new File(serverPath + fileName); try { file.transferTo(dest); String fileUrl = "http://localhost:8080/upload/" + fileName; return Result.success(fileUrl); } catch (IOException e) { e.printStackTrace(); return Result.error("上传失败"); } }

参数说明：MultipartFile 是 Spring 接收文件的标准类型，@RequestParam("file") 对应表单里的文件字段名。文件名用时间戳重命名，避免中文名或重复名导致的问题。返回的 fileUrl 是图片可访问的完整路径，存储到数据库后，小程序端用 img 标签的 src 属性直接就能加载。文件保存路径用系统绝对路径，不要把文件写到项目根目录，因为后端打包成 jar 后，项目内部路径不稳定。

管理员登录的密码加密，论文提到“用户密码在数据库中加密”，这个点值得做扎实。常见做法是 MD5 加盐而不是直接 MD5，比如MD5(password + salt)，salt 是每个用户独有的随机字符串。有的开发者直接用 MD5 就觉得很安全，实际上彩虹表能轻松碰撞常见密码。这个细节如果写在论文里，能体现安全意识的差异。

4.4 用户登录与权限控制：session_key 与 token 的选择

微信小程序登录依赖微信的授权能力。标准流程是 wx.login 获取临时 code，发给后端，后端用 code 向微信接口换 openid 和 session_key，然后在后端生成自定义登录态返回给小程序。这里的选择题是：后续请求用什么凭证。

常见做法是生成一个 token 字符串存到 Redis 或数据库，小程序端每次请求放在 header 里，后端用拦截器校验 token 有效性。另一种简化做法是把 openid 直接当用户标识，但这样安全性差，而且无法做 token 过期控制。毕设项目用 token 机制更能体现工程能力。

@Component public class LoginInterceptor implements HandlerInterceptor { @Autowired private UserTokenService userTokenService; @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token = request.getHeader("token"); if (token == null || token.isEmpty()) { response.setStatus(401); return false; } Long userId = userTokenService.getUserIdByToken(token); if (userId == null) { response.setStatus(401); return false; } request.setAttribute("userId", userId); return true; } }

这段代码的应用方式：在 WebMvcConfig 里注册拦截器，并指定拦截路径，比如/api/user/**、/api/vote/**。getUserIdByToken 方法的实现是查缓存，如果 token 不存在或已过期就返回 null。每次请求都带着 token，拦截器验证通过后把 userId 设置到 request 属性里，Controller 里用 @RequestAttribute("userId") 就能拿到当前用户。

要避免的一个坑是：小程序端 wx.login 获取的 code 只能使用一次，使用过后作废。如果你调试时反复用同一个 code 请求后端，后续会得到报错。每次进入小程序时都重新调 wx.login，才是正确操作。

5. 避坑：微信登录、重复投票、数据库与部署的常见问题

这一章把拆解和实测过程中踩过的坑写出来，每条都是“现象→原因→解决”的结构，给正在复现这个系统的你提供一份排错手册。

5.1 真机预览请求失败：域名白名单与 HTTPS 强制

• 现象：在微信开发者工具里请求接口一切正常，一用手机真机预览就报“request:fail”；或者提示“url not in domain list”。
• 原因：微信对小程序网络请求有严格限制，真机环境下只能请求已配置的合法域名，且要求 HTTPS。开发者工具默认勾选了“不校验合法域名”，所以本地调试能过，真机就翻车了。
• 解决：开发阶段在微信公众平台里把本地调试域名临时加到白名单，或者用开发者工具的“详情→本地设置”勾选“不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书”。上线前把后端接口部署到配置了 HTTPS 证书的域名，并在公众平台配置 request 合法域名。后端服务器需要配置 SSL 证书，常见做法是用 Nginx 做 HTTPS 反向代理，把 443 端口转到 SpringBoot 的 8080 端口。

5.2 投票重复提交：SELECT 和 INSERT 之间的并发缝隙

• 现象：用户快速连点两次提交按钮，后端生成了两条投票记录。
• 原因：submitVote 接口先查重再插入，但两次请求几乎同时到达，都通过了 count 检查，然后各自插入成功。这是典型的并发竞态条件。
• 解决：两层保障。第一层是前端，提交按钮在发出请求后置灰，disable 掉防止连点。第二层是后端，给投票记录表加上唯一索引，比如UNIQUE KEY uk_user_paper (user_id, paper_id)，数据库层面直接拒绝重复插入，捕获 DuplicateKeyException 返回“不能重复投票”。唯一索引是最后的防线，能兜住一切绕过前端限制的请求。

5.3 数据库中文乱码或表情符号变问号

• 现象：往数据库插入中文正常，但插入包含 emoji 的内容时变成问号；或者本地正常、部署到服务器出现乱码。
• 原因：字符集不一致。表建成了 utf8，但 utf8 在 MySQL 里不是真正的 UTF-8，它存不了四字节的 emoji。连接串里的 characterEncoding 没设置，或者表字符集和连接字符集不一致。
• 解决：建表统一用 utf8mb4，连接串加上 characterEncoding=utf8，mysql-connector-java 版本用 8.x。检查现有表的字符集用SHOW TABLE STATUS LIKE 'vote_%'，如果不是 utf8mb4，用ALTER TABLE vote_record CONVERT TO CHARACTER SET utf8mb4转换。代码里不要在 SQL 语句中手动拼接字符串，用 PreparedStatement 参数化查询，也能避免字符转义问题。

5.4 小程序 setData 之后页面没刷新

• 现象：执行 setData 后，wxml 里的数据没有变化，控制台打印 this.data 又是新值。
• 原因：setData 是异步的，视图层更新需要时间。另一个常见原因是你直接修改了 this.data 里的对象属性，没有用 setData，改变不会被驱动到视图层。比如写了this.data.voteList.push(item)，视图层不会感知。
• 解决：所有数据变更一律走 setData。如果是数组，先构造新数组再整体赋值；如果是对象属性，用this.setData({ 'item.name': 'newName' })这种路径写法。如果你需要在 setData 之后立即做某件事，把代码写在回调里，setData 的第二个参数是回调函数。这一点属于代码习惯问题，踩过一次记住了就好。

5.5 本地调试能连数据库，部署到服务器连不上

• 现象：本地开发时后端能正常读数据库，把 jar 包部署到云服务器后，启动报错或访问接口超时。
• 原因：MySQL 只绑定了 127.0.0.1，没有开启远程访问；或者云服务商的安全组没有放行 3306 端口；或者服务器防火墙没开放端口。
• 解决：先说结论，如果后端和数据库在同一台服务器，数据库不要开远程访问，本地用 TCP 连接就够了。这是安全性最高的方案。如果你非要远程连接，修改 MySQL 配置文件将 bind-address 改为 0.0.0.0，然后在安全组和防火墙放行 3306，最后把 root 账号的 host 改成 % 并设置强密码。但为了省心，部署时保持后端和数据库同机部署，代码里的连接地址写 127.0.0.1 即可。这样网络链路最短，性能也更好。

5.6 上传图片返回的 URL 访问 404

• 现象：后端日志显示文件保存成功，返回了 URL，但浏览器打开 URL 时报 404。
• 原因：SpringBoot 的静态资源默认只处理 classpath 下的 /static、/public 等目录，上传到本地磁盘的文件路径不在静态资源映射范围内。
• 解决：写一个资源映射配置类，把本地磁盘目录映射到 /upload/**。在 SpringBoot 里用 addResourceHandlers 方法实现：

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceLocations("file:/data/upload/"); } }

这段代码的含义是：访问http://localhost:8080/upload/xxx.jpg时，Spring 会把请求转到/data/upload/xxx.jpg这个磁盘文件。注意 addResourceLocations 的路径要以file:开头，Linux 环境下路径末尾要加斜杠。Windows 环境用file:D:/upload/。这个坑的排查思路是：先确认文件确实写在磁盘上，确认映射路径和实际目录一致，再看日志确认访问的 URL 拼接有没有问题。

5.7 时间字段差了 8 小时

• 现象：数据库里的 addtime 是当前时间，查询出来却少了 8 小时，或者反过来。
• 原因：MySQL 驱动和 JVM 的时区不一致。连接串里没设置 serverTimezone，或者服务器时区是 UTC，本地时区是东八区。
• 解决：连接串加serverTimezone=Asia/Shanghai。代码里实体类的 Date 字段用@JsonFormat(pattern = "yyyy-MM-dd HH:mm:ss", timezone = "GMT+8")注解，确保返回给小程序端的 JSON 也是东八区时间。如果服务端部署在云上，建议把操作系统时区也统一设置为 Asia/Shanghai，终端执行timedatectl set-timezone Asia/Shanghai。

5.8 数据库 longtext 字段存储大 JSON 时性能变差

• 现象：options 字段存了很大的 JSON 字符串，投票列表页查询变慢。
• 原因：longtext 是文本类型，查询时不能走常规索引，而且大字段在 InnoDB 里是外部存储，读取时需要额外一次 IO。
• 解决：首先明确一点，毕设数据量不会大到 longtext 成为瓶颈，但优化习惯还是要有的。方案一是把选项拆到独立表，这是规范化的思路；方案二是保留 JSON 存储，但查询列表时用 SELECT 只查需要的字段，不要用SELECT *，避免把大文本字段一次性加载出来。另外，不要在 longtext 字段上建索引，没意义还有额外开销。如果你的投票项目类型经常过滤，把 type 字段单独建索引，查询效果更明显。

6. 从测试到上线部署：功能、性能、安全三层验证怎么做

6.1 功能测试用例设计：覆盖用户端和管理员端主流程

论文在系统测试章节提到了功能测试、查询性能测试、安全性能测试，这个三层结构可以用来指导你的自测安排。功能测试的核心思路是：把用例图里的每一个角色动作都变成一条可执行的测试步骤。

以“用户投票”为例，一组完整的测试用例应该覆盖以下场景：

• 打开投票页，确认题目和选项渲染正确
• 点击选项，确认高亮显示且提交按钮变成可点击状态
• 不选选项直接点提交，确认出现“请先选择一个选项”提示
• 正常提交投票，确认返回“投票成功”且自动跳转
• 再次对同一投票项目提交，确认后端拒绝并返回“不能重复投票”
• 断网环境下提交，确认出现网络异常提示且不产生脏数据

每条用例都要记录三列：操作步骤、预期结果、实际结果。实际结果与预期不一致的地方，就是需要修 Bug 的点。管理员端的功能测试类似，核心覆盖作品信息的上传、编辑、删除、审核，投票项目的创建和发布，以及论坛帖子的置顶和删除。

6.2 查询性能测试：在大数据量下验证接口响应

查询性能测试的目的不是压出服务器的极限值，而是验证在常规负载下系统响应是否达标。毕设场景下不用引入 LoadRunner 这类重型工具，用 Postman 或 JMeter 就行。测试重点放在几个高频查询接口：作品列表页、投票题目查询、投票结果统计。

一个可执行的性能测试方案是用 JMeter 模拟 50 个并发用户同时请求作品列表接口，观察平均响应时间、错误率和吞吐量。如果响应时间超过 2 秒，优先检查 SQL 是否走了全表扫描。用 EXPLAIN 命令查看执行计划，确认 where 条件中的字段有索引。另一个常见性能瓶颈是 N+1 查询，比如查出 10 个作品，再循环查每个作品的评论数，这就是 11 条 SQL。优化方式是用一条带 JOIN 的查询一次性取出聚合数据。

6.3 安全测试要点：登录态、SQL 注入、越权访问

安全测试不是用工具扫一遍就结束，而是要有针对性地验证论文里提到的安全性需求：密码加密、权限控制、数据库不暴露在公网。

• 登录态测试：手动修改请求头里的 token 为一个随机字符串，确认后端返回 401。使用正常账号登录后，用另一个账号的 token 去请求个人信息接口，确认系统能识别越权访问并拒绝。这个测试的本质是验证拦截器逻辑是否真的起效。
• SQL 注入测试：在接口参数里传入' OR 1=1 --这样的字符串，观察后端是否返回异常数据。如果用了 MyBatis 的#{}写法，SQL 注入漏洞基本不会存在，因为底层是 PreparedStatement 参数化查询。但如果是${}拼 SQL，比如排序字段动态传入，就可能有问题。测试后把隐患参数全部改成#{}。
• 敏感信息测试：检查后端接口返回的 JSON 数据里有没有包含用户手机号、身份证等敏感信息。比如作品列表接口如果返回了管理员账号密码，就是严重的安全问题。

6.4 小程序体验版发布与部署完整流程

测试通过后的最后一步是发布体验版。在微信开发者工具里点击“上传”按钮，把代码传到微信公众平台，然后在公众平台的“版本管理→开发版本”里把代码选为体验版，生成体验版二维码。扫码前要先把体验者加入成员管理，否则其他人扫不了。

后端部署则建议使用 Docker 或直接java -jar方式运行。最简单的做法是：服务器安装 JDK 和 MySQL，把项目打成 jar 包，运行nohup java -jar vote-system.jar > log.out 2>&1 &。第一次部署时长心眼里有个数：服务器网络速度一般时，下载 JDK、装 MySQL、初始化数据、上传 jar 包，预留半天时间比较稳妥。数据库导入用mysql -u root -p < init.sql命令。

6.5 验证清单：上线前的最后一道工序

线上部署完成后，走一遍下面的触发式验证清单：

我在做类似系统的部署验证时，习惯先把后端日志级别调到 DEBUG 跑一遍主流程，确认没有隐藏异常后再改回 INFO 级别。这个习惯帮我发现过不少只在真机环境才会触发的问题，比如 HTTPS 证书链不完整导致的请求失败。

每次做完这类微信小程序毕设项目，我都会复盘一遍：最花时间的地方往往不是写业务代码，而是环境配置和联调。从那以后，我每次动手前都强制要求自己先把技术选型和表结构单独拿出来梳理，再写代码。这个顺序看着慢，实际是给后面的测试和论文省出大把时间。希望这份拆解能让你少走一些弯路，把踩坑时间花在真正有产出的地方。

本文还有配套的精品资源，点击获取