我想先聊聊这个项目的缘起。每年毕业季大量高校毕业生会把公务员考试当作主要就业方向之一但真正开始准备之后会发现一个很现实的问题招考公告散落在不同官网岗位表是一张动辄几千行的Excel历年分数线要靠学长学姐口口相传刷题软件又很难和具体报考岗位匹配。很多同学不是输在复习强度上而是输在信息整理和备考节奏上。这个项目就是针对这个痛点做的全称是“基于Spring Boot的微信小程序高校毕业生公考助手管理系统”一句话概括就是用Spring Boot提供接口、微信小程序承载业务把“查岗—选岗—备考—刷题—复盘”这条链路打通。后台覆盖岗位查询、报考条件筛选、历年分数线对比、在线刷题、错题本、备考计划和资讯公告等功能。如果你是准备做毕业设计的本科生或者想从零上手Spring Boot加小程序全栈开发的初学者再或者是在实验室做就业服务项目的团队这篇文章都可以当一份项目复盘参考后面还会把关键细节和踩过的坑摊开讲。1. 项目整体设计与技术选型1.1 为什么选择Spring Boot和微信小程序先说后端选型。我最终选了Spring Boot 2.7.18而不是最新的3.x原因很务实很多毕业生电脑上还是JDK 8Spring Boot 3.x最低要求JDK 17组队协作或者部署到学校服务器时环境兼容性会差很多。2.7这个版本在社区维护生态里足够成熟资料多遇到问题也好搜索。如果项目是个人练习用最新版没问题但作为需要稳定运行的毕设或校内项目选2.7是更稳妥的选择。前端没有用uniapp直接用微信小程序原生开发。原因很简单这个系统的主阵地就是微信生态不需要跨App原生框架对微信接口的支持最直接包体积小调试工具方便社区里关于原生小程序的坑也基本都被踩平了。如果后续要扩展到App和鸿蒙端再考虑用uniapp重构但单一场景下没必要增加一层抽象。1.2 功能模块与优先级排序在动手写代码前我做了一张功能优先级表。这个表直接影响开发排期因为公考助手的模块可以做得很大但不能在一开始铺太开。模块用户端功能管理端功能优先级岗位查询按地区、学历、专业、政治面貌筛选收藏岗位岗位Excel导入、手动编辑P0报考助手根据用户简历匹配可报岗位生成报考清单维护分数线、招录人数、报录比P1在线刷题行测、申论、公基分类刷题交卷判分试题批量导入、题库维护P0错题本自动收集错题支持重做答题数据统计P1备考计划自定义计划按天提醒模板计划维护P2资讯公告展示招考公告、政策解读资讯发布P2实际开发中我把“岗位查询”和“在线刷题”定为第一优先级。原因很简单对一个考试工具类产品用户最常打开的两个入口就是看岗位和做题。这两个功能稳定之后用户才会愿意登录、收藏、记录错题后面才有留存和转化。资讯公告和备考计划这类偏运营的功能可以放到第二梯队代码量不大但对初期验证价值没有多大贡献。社区互动这种重运营模块在时间紧张时可以直接砍掉不要因为觉得功能丰富就硬加。1.3 用户角色与权限边界系统里设计了三种角色游客、普通用户、管理员。游客可以浏览岗位列表、查看资讯和刷题但在触发收藏、保存错题、创建备考计划这些写操作时强制跳转到登录授权。管理员走独立后台入口登录之后才能维护岗位、试题和资讯。前后端分离之后接口权限必须落在后端不能只靠小程序端隐藏入口。我在后端用一个拦截器统一处理对以/api/user/开头的接口校验JWT对/api/admin/开头的接口校验管理员身份对/api/public/开头的接口直接放行。这样权限比较清晰也不容易漏。JWT在这里比Session更顺手。小程序端本身没有Cookie机制虽然wx.request可以手动设置header里的Cookie但维护起来很麻烦。JWT无状态后端不存session做水平扩展也方便。后面会专门讲实现细节。2. 数据库设计一张表一个故事2.1 概念模型走向物理表数据库设计阶段要耐得住性子。我先画概念模型再把实体拆成物理表。最终核心表有九张用户表user、岗位表position、岗位分数线表position_score、试题表question、答题记录表answer_record、错题本表wrong_book、岗位收藏表favorite_position、资讯表article、备考计划表study_plan。每张表承担明确的职责不把业务塞进一张大宽表。以岗位表为例字段大致包括title、department、region、recruit_count、education_required、major_required、political_required、registration_start、registration_end、exam_date等。这里有三个字段特别值得说明。2.2 关键字段的设计细节第一个是openid。用户表里的openid是微信生态里的唯一身份标识必须建唯一索引。你可以把unionid也存上但大多数场景用不到因为unionid需要开放平台绑定普通的小程序项目用openid就够了。第二个是region我强烈建议用行政区划编码而不是纯文本。比如用110000、110100这样的编码保存地区可以支持精确到省市区的筛选未来做地图下钻或区域统计也方便。我第一版直接存“北京市海淀区”筛选时只能like效率低且容易出错后来改成了编码。第三个是答案字段试题表里的answer直接存字符串。单选题存“A”判断题存“T”多选题存“ACD”。第一版我试图把每个选项拆成一张选项表结果发现刷题判分逻辑变得非常复杂完全得不偿失。中小型项目里字符串答案最直接配合选项JSON字段完全够用。2.3 索引与查询优化岗位筛选在几万条数据量下如果查询慢多半是索引没建对。我给position表建了一个联合索引字段顺序是region、education_required、major_required。为什么这样排因为筛选时这三个字段的频率最高而且联合索引遵循最左前缀原则把区划编码放最前面可以支持单独按地区筛选。实测在两万多条岗位数据下单次筛选响应时间从110ms左右降到30ms左右效果明显。答题记录表answer_record的写入频率很高只在user_id和question_id上各建普通索引即可不要乱加组合索引否则每次插入都要维护索引节点反而拖慢写入。如果需要做“某一天的用户答题量统计”可以再加一个create_time索引但要谨慎评估数据量。3. 后端核心实现从登录到刷题判分3.1 工程结构与统一返回体后端工程我按功能包划分早期不要搞微服务别一上来就拆模块。一个合理的单体结构足够应对几万用户的场景。com.example.gongkao ├── config ├── controller ├── service ├── mapper ├── entity ├── dto ├── vo ├── utils └── commoncontroller只负责接收参数和返回结果业务逻辑放在service层mapper层只做数据访问。所有接口统一返回Result对象包含code、message、data三个字段。code为200表示成功其他码表示业务异常。为什么不用HTTP状态码直接表示业务逻辑因为小程序端拿到200未必是业务成功比如“登录过期”和“参数错误”都可能是HTTP 200但业务code不同。统一结构更利于前端封装和排错。3.2 JWT登录鉴权全程拆解现在讲登录流程这是前后端联调最容易出问题的地方。小程序端先调用wx.login拿到临时code然后传给后端后端拿着code连同小程序的appid和secret向微信服务端请求jscode2session接口换回openid和session_key。拿到openid后如果用户没注册过就自动注册然后生成JWT返回给小程序端。后续请求在请求头里带上Authorization: Bearer token后端拦截器解析token从claim里取出userId放入ThreadLocal供业务层使用。代码大概长这样PostMapping(/login) public ResultString login(RequestBody LoginRequest req) { String code req.getCode(); WxSession session wxService.code2Session(code); User user userService.findOrCreate(session.getOpenid()); String token jwtUtils.generateToken(user.getId()); return Result.success(token); }这里比较坑的是code时效。微信的code有效期只有5分钟而且只能用一次如果前端重复调用两次login第二次就会报“invalid code”。所以我在小程序端做了登录状态管理只在token过期或者本地没有token时才主动调用login不在每次进入首页时都无脑登录。JWT的有效期我设置为7天。考虑到小程序用户不常登录7天能减少不必要的重新授权。如果你更重视安全可以做2小时短token加refresh_token机制但公考助手这类低频工具用不了那么复杂。JWT的secret一定不要写死在代码里通过application.yml的配置项注入部署时用环境变量覆盖防止代码泄露后token被伪造。3.3 刷题判分与错题收集刷题模块的后端核心就是判分逻辑和错题沉淀。单选和判断题直接比对答案字符串即可。多选题稍微麻烦因为选项顺序无关用户可能选“ADB”正确答案是“ABD”字符串直接equals肯定判错。我第一版就是用equals结果被测试怼了一遍多选应该按集合比较不关顺序的事。所以比较逻辑改成先把用户答案字符串拆成字符数组再和正确答案数组比较。要求长度一致并且每个字符都能在正确答案集合中找到这样满足“多选、少选、错选都不给分”的规则。如果你想支持漏选给半分那就再加一个“用户答案集合是正确答案子集”的判断但第一版不建议做因为前端要展示半分的视觉细节复杂度会成倍提升。答题完成后正确和错误记录都写入answer_record表。如果判错再往wrong_book表插入一条记录同一个用户同一道题重复答错时累加错误的次数而不是插多条。为了避免用户边做边等这块同步写入也可以数据量不大不需要上MQ。3.4 岗位筛选与Excel导入管理端导入岗位我用的EasyExcel。模板里预留了日期格式字段导入时如果不指定格式Excel解析出来会是数字序列比如“2025-10-01”变成“45365”。解决办法是在模板类字段上加DateTimeFormat注解或者导入前做单元格格式转换。导入过程中如果某一行数据有误不要直接整体回滚把错误行号收集起来一次性返回给管理员让他知道是第几行有问题远比只提示“导入失败”友好。岗位查询接口用MyBatis-Plus的LambdaQueryWrapper做动态条件拼接。支持同时传入多个筛选条件比如地区、学历、专业都选上时各个条件之间用and拼接。如果某个条件为空就跳过。在用wrapper时注意不要在每个条件后面都加eq比如“专业”字段用户没选就不应该传给SQL否则查出来永远为空。4. 微信小程序端从登录到刷题交互4.1 目录与请求封装小程序端的目录结构直接决定可维护性。我的划分是pages、components、utils、api、store。api目录下按业务模块拆分请求函数统一走一个request方法。request里封装了wx.request、baseURL、token注入和响应拦截。baseURL要特别小心开发时用电脑的局域网IP加端口真机不能写localhost上线必须用已经备案的HTTPS域名。小程序对网络请求的校验很严格非HTTPS域名真机跑不通只能在开发者工具里临时勾选“不校验合法域名”。一个典型的请求封装长这样const request (url, method, data, needAuth true) { return new Promise((resolve, reject) { wx.request({ url: BASE_URL url, method, data, header: { Content-Type: application/json, Authorization: needAuth ? Bearer wx.getStorageSync(token) : }, success(res) { if (res.data.code 200) { resolve(res.data.data); } else if (res.data.code 401) { wx.navigateTo({ url: /pages/login/index }); reject(res.data); } else { wx.showToast({ title: res.data.message, icon: none }); reject(res.data); } }, fail(err) { wx.showToast({ title: 网络异常, icon: none }); reject(err); } }); }); };4.2 登录与头像昵称授权2021年后微信小程序获取头像和昵称的方式变了不能再靠getUserProfile一键弹窗必须让用户手动点击用button的open-typechooseAvatar选择头像用inputtypenickname输入昵称。所以我的登录页不是一进来就弹窗而是先静默wx.login换token用户浏览完岗位、刷题都可以。直到他收藏岗位或保存错题时才半路拦截引导去完善头像昵称。这样做体验顺很多也符合微信的审核规范。登录页逻辑大致是页面onLoad时先调用wx.login把code传给后端后端返回token直接存本地。然后按钮点击时收集头像昵称字段调用用户信息更新接口。头像上传用wx.uploadFile指定filePath后端接收后转存到对象存储不要直接存到数据库的blob字段否则数据库会越来越大。4.3 刷题页面交互细节刷题页是整个小程序交互最复杂的页面。我用了swiper组件实现上下题滑动每个滑页是一道完整题目。题目内容包括题干、选项、答案解析和“上一题/下一题”按钮。用户点击选项后立即锁定当前题目的选择状态选中项显示高亮同时显示该题对错再在底部漏出答案解析。要改答案的话在交卷之前可以滑回去重新点但选过的旧选项会先清除。判断题和多选题的前端展示也不一样。判断题只有“正确/错误”两个按钮多选题允许用户点多个选项点击完成后自动进入下一题还是需要手动确认我选择手动确认防止手滑漏选。同时顶部放一个答题卡按钮点击后弹出本次套题的所有题号已经作答的题号变成绿色未作答的灰色交卷前可快速跳转。计时器放在导航栏下方从第一题开始计时退出页面自动保存当前答题状态到本地。如果用户误触退出回来后还能继续计时而不是重新开始。这个体验细节对刷题工具非常重要。4.4 本地缓存与数据一致性小程序端缓存我用了wx.setStorageSync缓存内容主要是token、用户信息、岗位筛选条件、当前刷题进度。缓存要加一个version字段当接口返回的数据结构和旧缓存不一致时强制清空。这个坑我踩过一次后端给岗位列表增加了新字段但旧缓存还在用户打开小程序看到的仍是旧结构页面渲染时报错。后来我在启动时拉一个配置接口把缓存版本号一并返回本地version不一致就执行wx.clearStorageSync。5. 测试、部署与小程序审核5.1 本地联调与接口文档联调阶段我推荐用Apifox或Postman。接口定义好后自动生成文档前端可以按文档mock数据不用等后端做完。后端单元测试至少要覆盖登录、判分、岗位筛选这几个核心接口。判分逻辑用JUnit做参数化测试把正确的和错误的答案样例都列出来特别是多选题至少覆盖“完全正确”“漏选”“多选”“顺序不同”四类情况。小程序端调试还有一个容易忽略的问题开发者工具里的“不校验合法域名”选项只对工具生效真机预览必须把域名配置到小程序后台的request合法域名里。如果你的后端还没上HTTPS真机联调很麻烦建议尽早准备好测试用的https域名。5.2 服务器部署与Nginx配置我用的云服务器是2核4G内存对公考助手这个量级的项目完全够。后端打成一个JAR包用systemd管理进程。JVM参数我设置为-Xms512m -Xmx1024m避免内存波动太大。如果服务器内存只剩2GXmx最好压到768m留出余量给MySQL和Nginx。HTTPS证书用Lets Encrypt免费申请三个月续期一次。配置Nginx将443端口代理到后端8080关键片段如下server { listen 443 ssl; server_name api.example.com; ssl_certificate /etc/nginx/ssl/example.pem; ssl_certificate_key /etc/nginx/ssl/example.key; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }改完配置记得nginx -t检查语法再reload。很多404和502问题最后都出在Nginx配置上不是后端代码问题。5.3 小程序提审与注意事项提交微信审核前要把request合法域名、downloadFile合法域名都配置好。如果页面有用户上传图片还要配置uploadFile合法域名。小程序的类目选择我建议选“教育 教育信息服务”或“工具 信息查询”不要选医疗、金融这类需要资质的类目否则直接被拒。如果有用户生成内容比如社区留言必须在提交审核前接入内容安全检测接口。微信对UGC类小程序的审核非常严格没有内容过滤机制基本过不了。6. 常见问题排查我踩过的坑都在这6.1 code2session请求失败这个接口报错最常见三个原因AppID和AppSecret不匹配、code被重复使用、后端服务器访问不了微信接口。排查时先看后端日志如果返回errcode为40029就是code无效40163就是code已被使用。前端登录一次后不要反复login同一code只传一次。还要给调用微信接口的HttpClient设置超时时间建议3秒避免线程被慢请求占满。6.2 真机上图片加载不出来真机加载图片失败十有八九是图片域名没有加入小程序后台的downloadFile合法域名。另一种可能是图片链接是http不是https真机直接拒绝。如果你的系统允许用户上传头像或图片最好统一转存到对象存储并使用自定义HTTPS域名不要在数据库里存base64。6.3 岗位查询在数据量大后变慢岗位数据量超过十万条以后组合索引也不是万能的。这时候可以引入Elasticsearch做全文检索但毕设阶段没必要。更稳妥的做法是给岗位表做分区表或者把region、education_required、major_required做成冗余的筛选字段配合覆盖索引减少回表。另外检查一下MyBatis-Plus的count语句如果用了多表join自动生成的count可能有误需要手写。6.4 LocalDateTime序列化格式不对后端返回LocalDateTime字段时默认格式是“2025-03-21T10:30:00”小程序端new Date解析时会出问题。我在实体类的日期字段上统一加了JsonFormat(pattern yyyy-MM-dd HH:mm:ss, timezone GMT8)返回给前端的字符串就是标准格式。如果不想在实体上加注解也可以在Jackson的ObjectMapper里全局配置。6.5 后台管理系统跨域报错小程序端没有跨域问题但如果你单独做了一个Web管理端前端访问后端接口时会遇到跨域。解决办法在后端写一个CORS配置类允许指定来源和请求头。不要用“*”允许所有来源管理端最好只放行管理后台域名。接口设计上不要在controller里一个个加CrossOrigin统一在WebMvcConfigurer里配置更省心。7. 项目经验复盘与可以往前走的几个方向7.1 砍功能不砍核心优先级决定成败写到这里整个系统的骨架你应该已经清楚了。这段不是标准的总结更像是我做完之后的复盘。最初版本里我也考虑过社区互动、每日打卡、好友PK后来全砍了。原因是开发资源有限与其做一个粗糙的社区不如把岗位筛选和刷题判分打磨得足够顺滑。实际验证下来用户停留时间最长的就是刷题和岗位比较这让我意识到工具型产品的核心永远是价值密度最高的一条主路径。7.2 从“信息工具”到“备考伙伴”的两个方向如果你打算继续往下做我建议先做两件事。第一件把“报考助手”做深根据用户专业、学历、政治面貌、应届身份自动匹配可报岗位再结合历年分数线和竞争比给出推荐排序。第二件把答题行为数据用起来比如根据错题知识点生成薄弱项雷达图每周推送一次专项练习题。这两个方向都能让公考助手从信息工具变成备考伙伴也更容易在答辩或展示时讲出亮点。