做毕业设计这几年我经手过不少“基于微信小程序”的题目其中“本地健康宝系统”是出现频率非常高的一个。原因也很现实它业务边界清晰、功能闭环完整、技术栈又足够“标准”无论你是做小程序前端、后台接口还是数据库设计都能找到合理的落脚点。这个题目一般包含一套完整的微信小程序源码、对应的后台管理服务、毕业论文lw以及一套能从零把项目跑起来的部署文档和讲解材料。今天这篇就围绕这个项目把我在设计和实现过程中的核心思路、关键代码、部署交付经验以及踩过的坑一次性讲透希望能帮到正在做同题的读者。先说清楚“本地健康宝”到底是个什么系统。它的核心业务是用户通过微信小程序每日提交健康信息体温、健康状况、近期行程、接触史等系统根据提交内容自动生成健康状态标识一般用绿、黄、红三色区分同时为管理员提供数据查看、异常预警和统计导出的后台能力。所谓“本地”指的是这套系统面向一个具体的辖区或单位数据不依赖第三方平台自己掌握数据表结构和部署环境。听起来不复杂但麻雀虽小五脏俱全——用户登录、数据上报、状态计算、二维码展示、后台管理、通知公告、数据统计全是毕业设计的高频考察点。1. 项目概述与整体设计思路1.1 这个系统到底在做什么打开小程序用户第一眼看到的是个人健康状态卡片。这个卡片上有三样东西用户基本信息、当日健康状态颜色标识、以及一个可供扫码核验的二维码。用户需要先完成当天的健康打卡——填写体温、选择是否有咳嗽乏力等症状、确认近期是否去过重点地区、是否有接触史然后提交。后台收到提交后按照事先定义好的规则算出红、黄、绿码状态刷新并记录到数据库。管理员登录后台能看到所有用户的最新状态、历史打卡记录也可以在异常情况出现时向用户推送公告。这一连串流程里最核心的一个设计问题是状态判定规则放哪里。我见过不少初稿方案把规则写在小程序前端什么体温大于37.3就变红码、有接触史就变黄码全在JS里写判断。这样做最大的问题不是技术行不行而是规则一旦调整用户端不更新版本就没法生效。而且前端判定天然可以被绕过——抓个包自己改参数就能伪造绿码。所以正规做法是把判定规则全部放在后端前端只负责收集和展示后端根据数据库里的记录算状态前端把这个状态原样呈现出来。这个设计原则贯穿整个项目后面讲后端接口的时候还会反复提到。1.2 技术选型为什么这么定技术栈选型方面前端我选的是微信小程序原生框架后端用Spring Boot MyBatis MySQL管理后台用Vue Element UI搭一个Web页面。这套组合是目前课程设计和毕业设计里最稳妥的选型理由有三。第一微信小程序原生框架虽然写起来不如uni-app这类跨端框架“爽”但它不会引入编译层的黑盒问题调试时遇到问题百度一搜一大把作为教学和毕业设计项目非常合适。第二Spring Boot MyBatis是Java方向学生最熟悉的后端组合生态成熟、资料海量就算你对Spring Boot不熟照着官方教程也能把项目跑起来。第三MySQL作为关系型数据库对这种结构化健康数据再合适不过——用户、打卡记录、公告、管理员天然就是几张表不需要引入Redis或MongoDB增加复杂度。有人可能会问数据库为什么不用SQLite这样连安装都省了。我的回答是你确实可以用SQLite做单机演示但答辩时老师问一句“系统并发访问怎么办”“多实例部署怎么同步”你就很难圆回来。用MySQL哪怕只是本地装一个也能顺理成章地讲清楚数据持久化和并发控制的设计而不是说“因为我不会装数据库”。功能可以简单但设计理由必须经得起追问。选型的核心逻辑就一句话凡是答辩可能被追问的点都要在设计阶段给出合理答案而不是到现场硬编。1.3 功能模块如何切分整个系统按角色可以切成三个端小程序用户端、后台管理端、后端服务端。用户端是核心包含登录授权、健康打卡、状态展示、二维码核验、公告查看、个人中心这几个页面模块。管理端包含用户列表、健康记录管理、状态统计、公告发布、管理员登录。服务端则统一提供接口和数据处理能力。我建议在做架构图的时候把这几个模块画清楚别把什么功能都堆在一个模块里。比如“二维码核验”其实是一个独立场景——门卫扫码、管理人员核验身份它和用户查看自己的码是两回事。有的设计把核验功能做进用户端让用户自己扫自己的码这在逻辑上是不通的。核验应该由管理员角色扫码完成对应后台管理端的一个功能点。这个细节在论文的功能模块图里一定要体现出来避免答辩老师质疑你逻辑混乱。模块划分还有一个实际好处写代码和写论文可以同步推进。模块化拆分清晰论文的第三章“系统设计”几乎可以从代码结构直接映射出来你的类名、接口路径、页面文件组织得越规整论文就越好写答辩时讲起来也越有条理。2. 核心功能拆解与关键细节2.1 健康状态判定的规则引擎这是整个系统最有技术含量、也最体现“设计感”的一块。健康状态的判定不能做成写死的if-else堆在Controller里而应该抽象成一套可配置的规则。当时的做法是后端定义一个HealthRuleService专门负责把用户当日提交的健康数据转换成状态。规则可以定义成一张数据库表比如health_rule表里存“体温上限”“是否有症状算黄码”“接触史是否直接红码”“规则优先级”等字段系统启动时加载到内存判定的时逐条匹配。当然简化一点也可以把规则写在Java枚举或常量类里。重点在于规则与主流程分离方便调整和扩展。判定逻辑本身并不复杂。大致的规则可以设计为体温正常≤37.3℃、无任何症状、无接触史、行程无异常 → 绿码体温在37.3℃~38.5℃之间或有轻微症状或行程涉及一般关注地区 → 黄码体温超过38.5℃或与确诊/疑似病例有接触史或行程涉及高风险地区 → 红码注意一个关键点红黄绿的判定不是独立事件而是有优先级和互斥关系的。比如某用户体温正常但有接触史按体温是绿按接触史是红最终状态应该是红。所以规则的执行必须有一个优先级排序——先查红线条件再查黄线条件最后才是绿码兜底。这个执行顺序我当初在代码注释里写得很清楚因为确实容易写错。public String evaluate(HealthReportDTO report) { // 优先级1红码条件任一命中直接返回红码 if (report.getTemperature() 38.5f || report.getHasContact()) { return RED; } // 优先级2黄码条件 if (report.getTemperature() 37.3f || report.getSymptomFlag()) { return YELLOW; } // 兜底绿码 return GREEN; }这段代码刻意写得直白方便论文里贴代码片段的时候一下子能看懂。实际的项目里比这个多一些细节比如温度是浮点数时比较精度怎么处理、一天内多次提交以哪次为准这些小点后面单独说。总的来说规则引擎就一个目标让“判定状态”这件事可以在不修改客户端代码的情况下通过调整服务端逻辑来完成。2.2 二维码与状态卡片的实现细节状态卡片上那个二维码学名叫QR Code核心作用是别人扫一下就能核验当前用户的信息和健康状态。这一步不少初学者会走弯路试图自己写二维码生成算法——别闹了这种成熟领域直接用现成库就够了。Java后端用ZXing库生成Base64图片小程序端直接用image标签展示干净利落。// 用ZXing生成二维码转Base64返回给前端 BitMatrix bitMatrix new QRCodeWriter().encode(content, BarcodeFormat.QR_CODE, 300, 300); MatrixToImageWriter.writeToStream(bitMatrix, PNG, outputStream); String base64 Base64.getEncoder().encodeToString(outputStream.toByteArray());这里真正容易踩坑的是二维码的内容字段怎么设计。最常见的错误是把用户手机号、身份证号全塞进去。二维码是会被别人扫的个人隐私数据直接暴露在里面这在答辩时妥妥被老师挑刺。我当时把二维码内容设计成一段JSON包含 userId、timestamp、status 三个字段然后用HMAC做了签名。扫的人只能看到一串加密后的字符串服务端扫码接口解析后返回脱敏的用户信息和健康状态既不泄露隐私又能防伪造。小程序端展示二维码用的是canvas绘制。这里有个真机上的经典坑基础库版本不同canvas接口不一致。老版本是用wx.createCanvasContext新版本推荐同层渲染的type2d接口。我建议直接统一用新版2d接口因为老接口在部分机型上会出现二维码显示不出来的问题排查成本高。具体绘制逻辑是先调用后端的二维码接口拿到Base64图片转成临时文件路径再画到canvas上。2.3 用户登录与本地缓存策略微信小程序的登录流程和普通的账号密码登录不一样。核心是wx.login()拿到一个临时code然后把code发给后端后端拿着code去微信的code2Session接口换openid和session_key。openid就是用户在小程序里的唯一身份标识。也就是说你的系统根本不需要用户注册——第一次进入微信就替你完成了身份识别。这个流程本身不难但在校生做项目时容易忽略两个点。第一会话状态的维护。后端拿到openid后不能每次请求都调微信接口验证身份成本太高也没有必要。正确做法是后端生成一个自己的token可以是UUID以token - userId的映射关系存到服务端同时把token返回给小程序端。小程序把token放进wx.setStorageSync(token, token)做成本地缓存后续所有请求在header里带上这个token后端拦截器统一鉴权。token本身要设置过期时间比如7天过期后小程序重新走一遍wx.login流程。第二用户信息授权策略。很多项目一上来就弹窗要求用户授权头像昵称用户体验很差。新版的微信规范对头像昵称获取也做了限制不再支持直接拿完整的用户信息。我的做法是首次登录只把openid作为用户ID头像昵称做成选填——用户可以点进个人中心自己设置。这样既符合微信平台规范又避免了一进小程序就弹窗劝退用户的问题。// 小程序端登录逻辑 wx.login({ success: async (res) { const { code } res; const loginRes await request({ url: /api/auth/login, method: POST, data: { code } }); if (loginRes.code 200) { wx.setStorageSync(token, loginRes.data.token); wx.setStorageSync(userInfo, loginRes.data.userInfo); } } });本地缓存策略还有一个关键细节打卡状态也要做缓存。用户打开小程序第一件事是看今日是否已打卡。如果每次都去后端查最新的打卡记录网络慢的时候体验很差。我的方案是打卡成功后把todayReported字段写入本地缓存并记录当前日期。小程序启动时读缓存如果lastReportDate等于今天就直接显示“已打卡”否则再去请求后端。这样既减少了无效请求又保证了状态的准确性。3. 从零跑通关键流程的实操记录3.1 数据库设计与初始化数据库是整个系统最不能糊弄的部分。我见过太多课程设计把用户表和打卡记录表做成一张“万能大表”字段几十个冗余和空值满天飞答辩老师一看就皱眉。合理的表结构应该至少包含四张核心表用户表、健康打卡表、公告表、管理员表。用户表存用户基础信息字段包括user_id主键、openid唯一索引、nickname、avatar、phone、create_time。健康打卡表存每一次提交记录字段包括record_id、user_id、temperature、symptom_flag、contact_flag、travel_places、health_status、report_date、create_time。这里有个细节为什么symptom_flag和contact_flag用tinyint而不是varchar因为布尔型数据用整数表示在代码里判断更简练数据量大的时候查询性能也更好。公告表结构更简单notice_id、title、content、create_time。管理员表就admin_id、username、password_hash、create_time。建表语句不是随便写写就行索引设计很关键。健康打卡表查询最频繁的场景是“查某个人某一天的记录”所以user_id和report_date必须建联合索引。这个索引如果不建数据量几千条的时候感觉不明显到了几万条页面响应慢到怀疑人生。CREATE TABLE health_report ( record_id int NOT NULL AUTO_INCREMENT, user_id int NOT NULL COMMENT 用户ID, temperature decimal(4,1) DEFAULT NULL COMMENT 体温, symptom_flag tinyint DEFAULT 0 COMMENT 是否有症状, contact_flag tinyint DEFAULT 0 COMMENT 是否有接触史, travel_places varchar(255) DEFAULT NULL COMMENT 近期行程, health_status varchar(10) DEFAULT GREEN COMMENT 健康状态, report_date date DEFAULT NULL COMMENT 打卡日期, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (record_id), KEY idx_user_date (user_id,report_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;数据库字符集用utf8mb4而不是utf8这一点值得特别留意。utf8在MySQL里最多支持3字节字符存不了emoji表情用户昵称一旦带个emoji直接报错。utf8mb4是完整的4字节编码兼容性更好。这个小坑当初折腾了我一晚上印象极深。3.2 健康打卡接口怎么写才不踩坑打卡接口是整个后端最重要的接口没有之一。但在动手写代码之前先想清楚一个业务规则同一天重复提交怎么办。当时设计的规则是当天已打卡则禁止重复提交返回错误码提示“今日已打卡”。但如果用户确实填错了体温硬不让人家改也不人性化所以增加了“当天记录允许覆盖修改一次”的逻辑。实现上就是在插入前先查一下是否已有当天记录有则改为更新操作。这里有个并发的坑——如果两个请求同时进来都查到“没有记录”然后同时插入就会出现同一天两条记录。理论上要加数据库唯一索引做兜底比如uk_user_date(user_id, report_date)但这又和“允许覆盖”冲突了。我当时采取的折中方案是在Service层加synchronized锁先查后写业务体量下已经够用了论文里也能讲清楚。后端接口的参数校验也千万别偷懒。体温字段要求范围在35.0到42.0之间不在这个范围直接拒绝。有些人不做校验前端随便传一个999.0后台就能算出个红码逻辑就乱了。参数校验用注解或者代码手写都行重点是校验必须在后端做——就算前端已经限制了输入也不能保证别人不直接调接口传脏数据。PostMapping(/report) public Result report(RequestBody Valid HealthReportDTO dto, RequestHeader(token) String token) { // 参数校验体温范围 if (dto.getTemperature() 35.0f || dto.getTemperature() 42.0f) { return Result.error(体温数据异常); } // 业务处理 ... }还有一个很小的细节体温字段用decimal(4,1)也就是整数部分3位、小数部分1位。为什么不用float因为float在MySQL里是近似存储比较大小容易出精度问题。体温这种小数点后一位的数据用decimal最稳。3.3 小程序端页面与接口联调前端和小程序联调阶段最影响开发效率的是request请求的封装。微信小程序没有axios官方提供的wx.request又比较底层不封装的话每个页面都要写一遍success/fail回调代码冗余且乱。我第一天就封装了一个request.js工具统一处理baseUrl、请求头token、状态码判断、错误提示和loading态。const request (url, method, data) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL url, method, data, header: { Content-Type: application/json, token: wx.getStorageSync(token) || }, success: (res) { if (res.data.code 200) { resolve(res.data); } else { wx.showToast({ title: res.data.msg, icon: none }); reject(res.data); } }, fail: (err) { wx.showToast({ title: 网络异常请稍后再试, icon: none }); reject(err); } }); }); };这个封装至少有四个好处。第一所有请求自动带token不用每个页面重复写第二统一的状态码处理避免页面里到处是if (res.data.code 200)的嵌套第三失败提示统一风格不会有的页面弹toast、有的页面弹模态框第四用Promise包装后可以用async/await写异步逻辑代码可读性提升非常明显。页面联调阶段最大的杀手是“接口地址写死”。不少同学在自己电脑上把baseUrl写成http://localhost:8080在开发者工具里能跑一上真机就请求失败。原因很简单手机上的localhost是手机自己不是你的电脑。真机调试时必须把baseUrl改成电脑的局域网IP比如http://192.168.1.100:8080。我建议把baseUrl单独放一个config.js文件里根据环境变量动态切换而不是散落在各个页面里。不然改一次地址等于做一次全项目搜索替换。4. 部署交付从源码到可演示的完整流程4.1 后端打包与本地运行拿到源码后第一件事是让后端项目在本机跑起来。Spring Boot项目的标准操作是确认JDK版本一般要求1.8或11、配置好Maven仓库然后在项目根目录执行mvn spring-boot:run或者在IDE里直接运行主类。如果要用打包后的jar包部署执行mvn clean package在target目录下拿到health-system.jar然后java -jar health-system.jar就能启动。这里最关键的是配置文件。application.yml里要改三个东西MySQL连接地址、数据库账号密码、以及端口号。server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/health_db?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver一个高频报错是时区问题。MySQL连接串不写serverTimezoneAsia/Shanghai日志里会报The server time zone value Öйú±ê׼ʱ¼ä is unrecognized一眼看过去全是乱码其实只是时区配置缺失。还有characterEncoding一定要写成utf8mb4和建表时保持一致否则存取中文和emoji都可能出问题。第一次启动大概率会遇到数据库没建的问题。项目里一般会附带sql/init.sql初始化脚本先打开MySQL执行一遍建库建表再启动后端。顺序不能反——先启动后端再建库后端初始化数据源的时候直接报连接不上。4.2 小程序端配置、上传与体验版小程序端的部署比后端多了几个环节。第一步需要有一个微信小程序的AppID。如果你没有注册小程序账号用测试号也行但测试号有功能限制比如部分接口无法调用。建议直接去微信公众平台注册一个个人小程序流程不复杂。第二步在project.config.json里把appid改成你自己的然后打开微信开发者工具导入项目目录应该就能看到页面预览了。第三步才是关键后端接口要能从小程序访问。开发模式下可以在开发者工具里勾选“不校验合法域名”这样localhost也能请求。但真机预览时这个选项是不生效的真机要求所有请求的域名必须是HTTPS并且在小程序后台配置到白名单里。这一条卡住了非常多的人。处理办法看你的演示场景如果只是本地局域网演示让后端服务跑在电脑上小程序端把requestUrl改成电脑的局域网IP真机预览时把“不校验合法域名”关掉填上调试IP可以实现临时访问。如果要正式部署上线那就要买域名、配HTTPS证书并把域名加到小程序后台的“request合法域名”里。对毕业设计而言前者已经完全够用后者属于加分项。做完配置在开发者工具里点“上传”填版本号和备注然后去微信公众平台的后台把版本设为“体验版”生成一个体验版二维码。把这个二维码发给别人扫就能直接体验系统答辩演示的时候这招挺好用。4.3 交付物整理源码、论文与部署文档的组织方式标题里写了“源码lw部署文档讲解”也就是说交付的不是一堆散落文件而是一套完整可查阅的材料。我自己整理交付物时目录结构大概是这样的health-system/ ├── backend/ # 后端Spring Boot工程 │ ├── src/ │ ├── pom.xml │ └── sql/init.sql ├── miniapp/ # 微信小程序前端工程 │ ├── pages/ │ ├── utils/ │ └── app.json ├── docs/ │ ├── 部署文档.md │ ├── 操作手册.md │ └── 接口文档.md ├── 论文/ │ ├── 基于微信小程序的本地健康宝系统的设计与实现.docx │ └── 开题报告.docx └── README.mdREADME.md 值得认真写。我见过太多项目源码拿到手连启动步骤都要猜。README至少包含五块内容项目简介、技术栈、环境要求、快速启动步骤数据库初始化→后端启动→小程序导入→修改配置、目录结构说明。这份文档既是给别人看的也是给一周后的自己看的——答辩完隔段时间再回来调试没有这份文档全靠回忆效率会低很多。部署文档和接口文档的意义也在这个地方体现。接口文档列清楚每个接口的路径、方法、入参、出参比如/api/health/report接收tokenheader 和{temperature, symptomFlag, ...}JSON体返回{code, msg, data}。写文档的过程本身也是重新审视接口设计是否合理的过程。如果发现某个接口的路径命名含糊、字段命名不一致趁早改等到答辩时被老师问“这个接口是干什么的”再想改就晚了。5. 常见问题与排查技巧实录5.1 真机调试的三个经典翻车现场真机调试和开发者工具完全是两个世界。第一个经典问题是“canvas画不出二维码”。代码在开发者工具里一切正常手机上一片空白。排查下来原因通常是新版的canvas同层渲染接口要求节点的宽高必须先确定而旧代码里没有跳转渲染层就急于调用绘制接口。解决办法是在wx.nextTick里等canvas节点渲染完成再画。第二个经典问题是“请求失败url not in domain list”。之前说过的HTTPS域名白名单问题。真机预览时如果没关掉“校验合法域名”选项非白名单域名的请求一律拦截。这个问题定位很快报错信息写得很直白但架不住很多人不看报错信息反复重启小程序浪费时间。第三个问题是本地缓存导致的“假数据”现象。小程序端缓存了token和用户信息后端数据库重置之后token还在本地请求接口返回401或500页面表现为白屏、数据加载不出来。排查思路是先清理小程序缓存再重新登录。这背后就是缓存策略的双面性——缓存提速但数据一致性需要自己保证。所以每次修改数据库或重置后端都要顺手清除本地的Storage缓存形成肌肉记忆。5.2 一套实用的排查清单综合项目过程中的各种问题我总结了一个排查顺序遇到报错先按这个顺序过一遍现象可能原因排查/解决步骤后端启动失败数据库连接配置错误/数据库未创建检查application.yml的url、username、password确认MySQL服务已启动先执行init.sql接口404Controller路径和前端请求路径不一致对比RequestMapping和小程序里request()的url尤其注意大小写和斜杠请求401token缺失或过期检查wx.getStorageSync(token)是否有值重新走登录流程真机请求失败域名未配置/未关闭域名校验开发者工具勾选不校验域名确认baseUrl用的是局域网IPcanvas空白canvas节点未渲染完成使用wx.nextTick延迟绘制确认canvas宽高已设置中文乱码数据库字符集不对确认连接串characterEncodingutf8mb4确认表字符集是utf8mb4重复打卡记录缺少唯一约束/并发校验检查Service层是否有先查后写逻辑考虑加唯一索引或应用层锁这份清单看着普通但实际排查时能省下大量时间。我的习惯是任何问题先往“配置”上想再往“代码”上想。配置错误的概率远比逻辑错误高尤其是在第一次部署的时候。5.3 做完这个项目我学到的几个实在经验最后聊几条真正有价值的经验不算代码范畴但对完成这个项目至关重要。第一开发时就要想好答辩时怎么演示。不要到答辩前才匆匆准备验收时最怕的是现场网络不好、后端起不来、小程序加载不出来。我自己的做法是提前准备一台备用手机和一条手机热点后端跑在笔记本电脑上演示全程用热点不给演示设备留任何依赖办公网络的环节。这些小准备看似琐碎关键时刻能保命。第二微信开发者工具的“缓存清空”按钮没事多用用。很多前端的问题其实是缓存导致的旧代码在跑清一下缓存重新编译问题直接消失。凡是用户端改完代码没生效、页面更新不对的先清缓存再谈其他排查。第三写论文时架构图和数据流图画得越细后期压力越小。做系统设计时画的图论文里能直接用反而是代码写完了再补图细节早忘了画出来的图错误百出。在我看来这个项目的论文写作应该和开发同步进行而不是写完代码再回头编文档。架构、表结构、接口设计这些内容开发前和开发中写最流畅后面补全是硬凑字数。第四源码和部署文档的版本一定要一致。有一次为了调试功能临时改了数据库字段部署文档里没同步更新结果同学按部署文档跑初始化脚本启动后端直接报字段不存在。交付前的最后一天把README、部署文档、源码三样东西完整过一遍流程保证照着文档能走通这个环节比赶工写一个新功能重要得多。这个项目本身并不复杂但把它做成“能演示、能答辩、能扩展”的完整交付物确实需要投入不少精力。现在回头看整套流程走完一遍对Spring Boot的接口开发、微信小程序的页面逻辑、数据库设计的实践理解都上了一个台阶。这大概也是它成为毕业设计经典选题的原因——麻雀不大五脏俱全每一步都能踩到真正的开发流程上。准备动工的同学先把环境搭起来跑通一遍最简流程后面的事就顺了。 基于微信小程序的本地健康宝系统设计与实现全解析
做毕业设计这几年我经手过不少“基于微信小程序”的题目其中“本地健康宝系统”是出现频率非常高的一个。原因也很现实它业务边界清晰、功能闭环完整、技术栈又足够“标准”无论你是做小程序前端、后台接口还是数据库设计都能找到合理的落脚点。这个题目一般包含一套完整的微信小程序源码、对应的后台管理服务、毕业论文lw以及一套能从零把项目跑起来的部署文档和讲解材料。今天这篇就围绕这个项目把我在设计和实现过程中的核心思路、关键代码、部署交付经验以及踩过的坑一次性讲透希望能帮到正在做同题的读者。先说清楚“本地健康宝”到底是个什么系统。它的核心业务是用户通过微信小程序每日提交健康信息体温、健康状况、近期行程、接触史等系统根据提交内容自动生成健康状态标识一般用绿、黄、红三色区分同时为管理员提供数据查看、异常预警和统计导出的后台能力。所谓“本地”指的是这套系统面向一个具体的辖区或单位数据不依赖第三方平台自己掌握数据表结构和部署环境。听起来不复杂但麻雀虽小五脏俱全——用户登录、数据上报、状态计算、二维码展示、后台管理、通知公告、数据统计全是毕业设计的高频考察点。1. 项目概述与整体设计思路1.1 这个系统到底在做什么打开小程序用户第一眼看到的是个人健康状态卡片。这个卡片上有三样东西用户基本信息、当日健康状态颜色标识、以及一个可供扫码核验的二维码。用户需要先完成当天的健康打卡——填写体温、选择是否有咳嗽乏力等症状、确认近期是否去过重点地区、是否有接触史然后提交。后台收到提交后按照事先定义好的规则算出红、黄、绿码状态刷新并记录到数据库。管理员登录后台能看到所有用户的最新状态、历史打卡记录也可以在异常情况出现时向用户推送公告。这一连串流程里最核心的一个设计问题是状态判定规则放哪里。我见过不少初稿方案把规则写在小程序前端什么体温大于37.3就变红码、有接触史就变黄码全在JS里写判断。这样做最大的问题不是技术行不行而是规则一旦调整用户端不更新版本就没法生效。而且前端判定天然可以被绕过——抓个包自己改参数就能伪造绿码。所以正规做法是把判定规则全部放在后端前端只负责收集和展示后端根据数据库里的记录算状态前端把这个状态原样呈现出来。这个设计原则贯穿整个项目后面讲后端接口的时候还会反复提到。1.2 技术选型为什么这么定技术栈选型方面前端我选的是微信小程序原生框架后端用Spring Boot MyBatis MySQL管理后台用Vue Element UI搭一个Web页面。这套组合是目前课程设计和毕业设计里最稳妥的选型理由有三。第一微信小程序原生框架虽然写起来不如uni-app这类跨端框架“爽”但它不会引入编译层的黑盒问题调试时遇到问题百度一搜一大把作为教学和毕业设计项目非常合适。第二Spring Boot MyBatis是Java方向学生最熟悉的后端组合生态成熟、资料海量就算你对Spring Boot不熟照着官方教程也能把项目跑起来。第三MySQL作为关系型数据库对这种结构化健康数据再合适不过——用户、打卡记录、公告、管理员天然就是几张表不需要引入Redis或MongoDB增加复杂度。有人可能会问数据库为什么不用SQLite这样连安装都省了。我的回答是你确实可以用SQLite做单机演示但答辩时老师问一句“系统并发访问怎么办”“多实例部署怎么同步”你就很难圆回来。用MySQL哪怕只是本地装一个也能顺理成章地讲清楚数据持久化和并发控制的设计而不是说“因为我不会装数据库”。功能可以简单但设计理由必须经得起追问。选型的核心逻辑就一句话凡是答辩可能被追问的点都要在设计阶段给出合理答案而不是到现场硬编。1.3 功能模块如何切分整个系统按角色可以切成三个端小程序用户端、后台管理端、后端服务端。用户端是核心包含登录授权、健康打卡、状态展示、二维码核验、公告查看、个人中心这几个页面模块。管理端包含用户列表、健康记录管理、状态统计、公告发布、管理员登录。服务端则统一提供接口和数据处理能力。我建议在做架构图的时候把这几个模块画清楚别把什么功能都堆在一个模块里。比如“二维码核验”其实是一个独立场景——门卫扫码、管理人员核验身份它和用户查看自己的码是两回事。有的设计把核验功能做进用户端让用户自己扫自己的码这在逻辑上是不通的。核验应该由管理员角色扫码完成对应后台管理端的一个功能点。这个细节在论文的功能模块图里一定要体现出来避免答辩老师质疑你逻辑混乱。模块划分还有一个实际好处写代码和写论文可以同步推进。模块化拆分清晰论文的第三章“系统设计”几乎可以从代码结构直接映射出来你的类名、接口路径、页面文件组织得越规整论文就越好写答辩时讲起来也越有条理。2. 核心功能拆解与关键细节2.1 健康状态判定的规则引擎这是整个系统最有技术含量、也最体现“设计感”的一块。健康状态的判定不能做成写死的if-else堆在Controller里而应该抽象成一套可配置的规则。当时的做法是后端定义一个HealthRuleService专门负责把用户当日提交的健康数据转换成状态。规则可以定义成一张数据库表比如health_rule表里存“体温上限”“是否有症状算黄码”“接触史是否直接红码”“规则优先级”等字段系统启动时加载到内存判定的时逐条匹配。当然简化一点也可以把规则写在Java枚举或常量类里。重点在于规则与主流程分离方便调整和扩展。判定逻辑本身并不复杂。大致的规则可以设计为体温正常≤37.3℃、无任何症状、无接触史、行程无异常 → 绿码体温在37.3℃~38.5℃之间或有轻微症状或行程涉及一般关注地区 → 黄码体温超过38.5℃或与确诊/疑似病例有接触史或行程涉及高风险地区 → 红码注意一个关键点红黄绿的判定不是独立事件而是有优先级和互斥关系的。比如某用户体温正常但有接触史按体温是绿按接触史是红最终状态应该是红。所以规则的执行必须有一个优先级排序——先查红线条件再查黄线条件最后才是绿码兜底。这个执行顺序我当初在代码注释里写得很清楚因为确实容易写错。public String evaluate(HealthReportDTO report) { // 优先级1红码条件任一命中直接返回红码 if (report.getTemperature() 38.5f || report.getHasContact()) { return RED; } // 优先级2黄码条件 if (report.getTemperature() 37.3f || report.getSymptomFlag()) { return YELLOW; } // 兜底绿码 return GREEN; }这段代码刻意写得直白方便论文里贴代码片段的时候一下子能看懂。实际的项目里比这个多一些细节比如温度是浮点数时比较精度怎么处理、一天内多次提交以哪次为准这些小点后面单独说。总的来说规则引擎就一个目标让“判定状态”这件事可以在不修改客户端代码的情况下通过调整服务端逻辑来完成。2.2 二维码与状态卡片的实现细节状态卡片上那个二维码学名叫QR Code核心作用是别人扫一下就能核验当前用户的信息和健康状态。这一步不少初学者会走弯路试图自己写二维码生成算法——别闹了这种成熟领域直接用现成库就够了。Java后端用ZXing库生成Base64图片小程序端直接用image标签展示干净利落。// 用ZXing生成二维码转Base64返回给前端 BitMatrix bitMatrix new QRCodeWriter().encode(content, BarcodeFormat.QR_CODE, 300, 300); MatrixToImageWriter.writeToStream(bitMatrix, PNG, outputStream); String base64 Base64.getEncoder().encodeToString(outputStream.toByteArray());这里真正容易踩坑的是二维码的内容字段怎么设计。最常见的错误是把用户手机号、身份证号全塞进去。二维码是会被别人扫的个人隐私数据直接暴露在里面这在答辩时妥妥被老师挑刺。我当时把二维码内容设计成一段JSON包含 userId、timestamp、status 三个字段然后用HMAC做了签名。扫的人只能看到一串加密后的字符串服务端扫码接口解析后返回脱敏的用户信息和健康状态既不泄露隐私又能防伪造。小程序端展示二维码用的是canvas绘制。这里有个真机上的经典坑基础库版本不同canvas接口不一致。老版本是用wx.createCanvasContext新版本推荐同层渲染的type2d接口。我建议直接统一用新版2d接口因为老接口在部分机型上会出现二维码显示不出来的问题排查成本高。具体绘制逻辑是先调用后端的二维码接口拿到Base64图片转成临时文件路径再画到canvas上。2.3 用户登录与本地缓存策略微信小程序的登录流程和普通的账号密码登录不一样。核心是wx.login()拿到一个临时code然后把code发给后端后端拿着code去微信的code2Session接口换openid和session_key。openid就是用户在小程序里的唯一身份标识。也就是说你的系统根本不需要用户注册——第一次进入微信就替你完成了身份识别。这个流程本身不难但在校生做项目时容易忽略两个点。第一会话状态的维护。后端拿到openid后不能每次请求都调微信接口验证身份成本太高也没有必要。正确做法是后端生成一个自己的token可以是UUID以token - userId的映射关系存到服务端同时把token返回给小程序端。小程序把token放进wx.setStorageSync(token, token)做成本地缓存后续所有请求在header里带上这个token后端拦截器统一鉴权。token本身要设置过期时间比如7天过期后小程序重新走一遍wx.login流程。第二用户信息授权策略。很多项目一上来就弹窗要求用户授权头像昵称用户体验很差。新版的微信规范对头像昵称获取也做了限制不再支持直接拿完整的用户信息。我的做法是首次登录只把openid作为用户ID头像昵称做成选填——用户可以点进个人中心自己设置。这样既符合微信平台规范又避免了一进小程序就弹窗劝退用户的问题。// 小程序端登录逻辑 wx.login({ success: async (res) { const { code } res; const loginRes await request({ url: /api/auth/login, method: POST, data: { code } }); if (loginRes.code 200) { wx.setStorageSync(token, loginRes.data.token); wx.setStorageSync(userInfo, loginRes.data.userInfo); } } });本地缓存策略还有一个关键细节打卡状态也要做缓存。用户打开小程序第一件事是看今日是否已打卡。如果每次都去后端查最新的打卡记录网络慢的时候体验很差。我的方案是打卡成功后把todayReported字段写入本地缓存并记录当前日期。小程序启动时读缓存如果lastReportDate等于今天就直接显示“已打卡”否则再去请求后端。这样既减少了无效请求又保证了状态的准确性。3. 从零跑通关键流程的实操记录3.1 数据库设计与初始化数据库是整个系统最不能糊弄的部分。我见过太多课程设计把用户表和打卡记录表做成一张“万能大表”字段几十个冗余和空值满天飞答辩老师一看就皱眉。合理的表结构应该至少包含四张核心表用户表、健康打卡表、公告表、管理员表。用户表存用户基础信息字段包括user_id主键、openid唯一索引、nickname、avatar、phone、create_time。健康打卡表存每一次提交记录字段包括record_id、user_id、temperature、symptom_flag、contact_flag、travel_places、health_status、report_date、create_time。这里有个细节为什么symptom_flag和contact_flag用tinyint而不是varchar因为布尔型数据用整数表示在代码里判断更简练数据量大的时候查询性能也更好。公告表结构更简单notice_id、title、content、create_time。管理员表就admin_id、username、password_hash、create_time。建表语句不是随便写写就行索引设计很关键。健康打卡表查询最频繁的场景是“查某个人某一天的记录”所以user_id和report_date必须建联合索引。这个索引如果不建数据量几千条的时候感觉不明显到了几万条页面响应慢到怀疑人生。CREATE TABLE health_report ( record_id int NOT NULL AUTO_INCREMENT, user_id int NOT NULL COMMENT 用户ID, temperature decimal(4,1) DEFAULT NULL COMMENT 体温, symptom_flag tinyint DEFAULT 0 COMMENT 是否有症状, contact_flag tinyint DEFAULT 0 COMMENT 是否有接触史, travel_places varchar(255) DEFAULT NULL COMMENT 近期行程, health_status varchar(10) DEFAULT GREEN COMMENT 健康状态, report_date date DEFAULT NULL COMMENT 打卡日期, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (record_id), KEY idx_user_date (user_id,report_date) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;数据库字符集用utf8mb4而不是utf8这一点值得特别留意。utf8在MySQL里最多支持3字节字符存不了emoji表情用户昵称一旦带个emoji直接报错。utf8mb4是完整的4字节编码兼容性更好。这个小坑当初折腾了我一晚上印象极深。3.2 健康打卡接口怎么写才不踩坑打卡接口是整个后端最重要的接口没有之一。但在动手写代码之前先想清楚一个业务规则同一天重复提交怎么办。当时设计的规则是当天已打卡则禁止重复提交返回错误码提示“今日已打卡”。但如果用户确实填错了体温硬不让人家改也不人性化所以增加了“当天记录允许覆盖修改一次”的逻辑。实现上就是在插入前先查一下是否已有当天记录有则改为更新操作。这里有个并发的坑——如果两个请求同时进来都查到“没有记录”然后同时插入就会出现同一天两条记录。理论上要加数据库唯一索引做兜底比如uk_user_date(user_id, report_date)但这又和“允许覆盖”冲突了。我当时采取的折中方案是在Service层加synchronized锁先查后写业务体量下已经够用了论文里也能讲清楚。后端接口的参数校验也千万别偷懒。体温字段要求范围在35.0到42.0之间不在这个范围直接拒绝。有些人不做校验前端随便传一个999.0后台就能算出个红码逻辑就乱了。参数校验用注解或者代码手写都行重点是校验必须在后端做——就算前端已经限制了输入也不能保证别人不直接调接口传脏数据。PostMapping(/report) public Result report(RequestBody Valid HealthReportDTO dto, RequestHeader(token) String token) { // 参数校验体温范围 if (dto.getTemperature() 35.0f || dto.getTemperature() 42.0f) { return Result.error(体温数据异常); } // 业务处理 ... }还有一个很小的细节体温字段用decimal(4,1)也就是整数部分3位、小数部分1位。为什么不用float因为float在MySQL里是近似存储比较大小容易出精度问题。体温这种小数点后一位的数据用decimal最稳。3.3 小程序端页面与接口联调前端和小程序联调阶段最影响开发效率的是request请求的封装。微信小程序没有axios官方提供的wx.request又比较底层不封装的话每个页面都要写一遍success/fail回调代码冗余且乱。我第一天就封装了一个request.js工具统一处理baseUrl、请求头token、状态码判断、错误提示和loading态。const request (url, method, data) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL url, method, data, header: { Content-Type: application/json, token: wx.getStorageSync(token) || }, success: (res) { if (res.data.code 200) { resolve(res.data); } else { wx.showToast({ title: res.data.msg, icon: none }); reject(res.data); } }, fail: (err) { wx.showToast({ title: 网络异常请稍后再试, icon: none }); reject(err); } }); }); };这个封装至少有四个好处。第一所有请求自动带token不用每个页面重复写第二统一的状态码处理避免页面里到处是if (res.data.code 200)的嵌套第三失败提示统一风格不会有的页面弹toast、有的页面弹模态框第四用Promise包装后可以用async/await写异步逻辑代码可读性提升非常明显。页面联调阶段最大的杀手是“接口地址写死”。不少同学在自己电脑上把baseUrl写成http://localhost:8080在开发者工具里能跑一上真机就请求失败。原因很简单手机上的localhost是手机自己不是你的电脑。真机调试时必须把baseUrl改成电脑的局域网IP比如http://192.168.1.100:8080。我建议把baseUrl单独放一个config.js文件里根据环境变量动态切换而不是散落在各个页面里。不然改一次地址等于做一次全项目搜索替换。4. 部署交付从源码到可演示的完整流程4.1 后端打包与本地运行拿到源码后第一件事是让后端项目在本机跑起来。Spring Boot项目的标准操作是确认JDK版本一般要求1.8或11、配置好Maven仓库然后在项目根目录执行mvn spring-boot:run或者在IDE里直接运行主类。如果要用打包后的jar包部署执行mvn clean package在target目录下拿到health-system.jar然后java -jar health-system.jar就能启动。这里最关键的是配置文件。application.yml里要改三个东西MySQL连接地址、数据库账号密码、以及端口号。server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/health_db?useUnicodetruecharacterEncodingutf8mb4serverTimezoneAsia/Shanghai username: root password: your_password driver-class-name: com.mysql.cj.jdbc.Driver一个高频报错是时区问题。MySQL连接串不写serverTimezoneAsia/Shanghai日志里会报The server time zone value Öйú±ê׼ʱ¼ä is unrecognized一眼看过去全是乱码其实只是时区配置缺失。还有characterEncoding一定要写成utf8mb4和建表时保持一致否则存取中文和emoji都可能出问题。第一次启动大概率会遇到数据库没建的问题。项目里一般会附带sql/init.sql初始化脚本先打开MySQL执行一遍建库建表再启动后端。顺序不能反——先启动后端再建库后端初始化数据源的时候直接报连接不上。4.2 小程序端配置、上传与体验版小程序端的部署比后端多了几个环节。第一步需要有一个微信小程序的AppID。如果你没有注册小程序账号用测试号也行但测试号有功能限制比如部分接口无法调用。建议直接去微信公众平台注册一个个人小程序流程不复杂。第二步在project.config.json里把appid改成你自己的然后打开微信开发者工具导入项目目录应该就能看到页面预览了。第三步才是关键后端接口要能从小程序访问。开发模式下可以在开发者工具里勾选“不校验合法域名”这样localhost也能请求。但真机预览时这个选项是不生效的真机要求所有请求的域名必须是HTTPS并且在小程序后台配置到白名单里。这一条卡住了非常多的人。处理办法看你的演示场景如果只是本地局域网演示让后端服务跑在电脑上小程序端把requestUrl改成电脑的局域网IP真机预览时把“不校验合法域名”关掉填上调试IP可以实现临时访问。如果要正式部署上线那就要买域名、配HTTPS证书并把域名加到小程序后台的“request合法域名”里。对毕业设计而言前者已经完全够用后者属于加分项。做完配置在开发者工具里点“上传”填版本号和备注然后去微信公众平台的后台把版本设为“体验版”生成一个体验版二维码。把这个二维码发给别人扫就能直接体验系统答辩演示的时候这招挺好用。4.3 交付物整理源码、论文与部署文档的组织方式标题里写了“源码lw部署文档讲解”也就是说交付的不是一堆散落文件而是一套完整可查阅的材料。我自己整理交付物时目录结构大概是这样的health-system/ ├── backend/ # 后端Spring Boot工程 │ ├── src/ │ ├── pom.xml │ └── sql/init.sql ├── miniapp/ # 微信小程序前端工程 │ ├── pages/ │ ├── utils/ │ └── app.json ├── docs/ │ ├── 部署文档.md │ ├── 操作手册.md │ └── 接口文档.md ├── 论文/ │ ├── 基于微信小程序的本地健康宝系统的设计与实现.docx │ └── 开题报告.docx └── README.mdREADME.md 值得认真写。我见过太多项目源码拿到手连启动步骤都要猜。README至少包含五块内容项目简介、技术栈、环境要求、快速启动步骤数据库初始化→后端启动→小程序导入→修改配置、目录结构说明。这份文档既是给别人看的也是给一周后的自己看的——答辩完隔段时间再回来调试没有这份文档全靠回忆效率会低很多。部署文档和接口文档的意义也在这个地方体现。接口文档列清楚每个接口的路径、方法、入参、出参比如/api/health/report接收tokenheader 和{temperature, symptomFlag, ...}JSON体返回{code, msg, data}。写文档的过程本身也是重新审视接口设计是否合理的过程。如果发现某个接口的路径命名含糊、字段命名不一致趁早改等到答辩时被老师问“这个接口是干什么的”再想改就晚了。5. 常见问题与排查技巧实录5.1 真机调试的三个经典翻车现场真机调试和开发者工具完全是两个世界。第一个经典问题是“canvas画不出二维码”。代码在开发者工具里一切正常手机上一片空白。排查下来原因通常是新版的canvas同层渲染接口要求节点的宽高必须先确定而旧代码里没有跳转渲染层就急于调用绘制接口。解决办法是在wx.nextTick里等canvas节点渲染完成再画。第二个经典问题是“请求失败url not in domain list”。之前说过的HTTPS域名白名单问题。真机预览时如果没关掉“校验合法域名”选项非白名单域名的请求一律拦截。这个问题定位很快报错信息写得很直白但架不住很多人不看报错信息反复重启小程序浪费时间。第三个问题是本地缓存导致的“假数据”现象。小程序端缓存了token和用户信息后端数据库重置之后token还在本地请求接口返回401或500页面表现为白屏、数据加载不出来。排查思路是先清理小程序缓存再重新登录。这背后就是缓存策略的双面性——缓存提速但数据一致性需要自己保证。所以每次修改数据库或重置后端都要顺手清除本地的Storage缓存形成肌肉记忆。5.2 一套实用的排查清单综合项目过程中的各种问题我总结了一个排查顺序遇到报错先按这个顺序过一遍现象可能原因排查/解决步骤后端启动失败数据库连接配置错误/数据库未创建检查application.yml的url、username、password确认MySQL服务已启动先执行init.sql接口404Controller路径和前端请求路径不一致对比RequestMapping和小程序里request()的url尤其注意大小写和斜杠请求401token缺失或过期检查wx.getStorageSync(token)是否有值重新走登录流程真机请求失败域名未配置/未关闭域名校验开发者工具勾选不校验域名确认baseUrl用的是局域网IPcanvas空白canvas节点未渲染完成使用wx.nextTick延迟绘制确认canvas宽高已设置中文乱码数据库字符集不对确认连接串characterEncodingutf8mb4确认表字符集是utf8mb4重复打卡记录缺少唯一约束/并发校验检查Service层是否有先查后写逻辑考虑加唯一索引或应用层锁这份清单看着普通但实际排查时能省下大量时间。我的习惯是任何问题先往“配置”上想再往“代码”上想。配置错误的概率远比逻辑错误高尤其是在第一次部署的时候。5.3 做完这个项目我学到的几个实在经验最后聊几条真正有价值的经验不算代码范畴但对完成这个项目至关重要。第一开发时就要想好答辩时怎么演示。不要到答辩前才匆匆准备验收时最怕的是现场网络不好、后端起不来、小程序加载不出来。我自己的做法是提前准备一台备用手机和一条手机热点后端跑在笔记本电脑上演示全程用热点不给演示设备留任何依赖办公网络的环节。这些小准备看似琐碎关键时刻能保命。第二微信开发者工具的“缓存清空”按钮没事多用用。很多前端的问题其实是缓存导致的旧代码在跑清一下缓存重新编译问题直接消失。凡是用户端改完代码没生效、页面更新不对的先清缓存再谈其他排查。第三写论文时架构图和数据流图画得越细后期压力越小。做系统设计时画的图论文里能直接用反而是代码写完了再补图细节早忘了画出来的图错误百出。在我看来这个项目的论文写作应该和开发同步进行而不是写完代码再回头编文档。架构、表结构、接口设计这些内容开发前和开发中写最流畅后面补全是硬凑字数。第四源码和部署文档的版本一定要一致。有一次为了调试功能临时改了数据库字段部署文档里没同步更新结果同学按部署文档跑初始化脚本启动后端直接报字段不存在。交付前的最后一天把README、部署文档、源码三样东西完整过一遍流程保证照着文档能走通这个环节比赶工写一个新功能重要得多。这个项目本身并不复杂但把它做成“能演示、能答辩、能扩展”的完整交付物确实需要投入不少精力。现在回头看整套流程走完一遍对Spring Boot的接口开发、微信小程序的页面逻辑、数据库设计的实践理解都上了一个台阶。这大概也是它成为毕业设计经典选题的原因——麻雀不大五脏俱全每一步都能踩到真正的开发流程上。准备动工的同学先把环境搭起来跑通一遍最简流程后面的事就顺了。