Spring Boot + 微信小程序：文物科普系统毕业设计全流程解析

每年到开题季，计算机专业群里问得最多的就是：“有没有那种题目听起来有点文化含量、技术栈又常规、工作量不容易被老师挑刺的毕设？”我一般会建议看看“博物馆文物科普知识普及系统微信小程序”这类方向。别被名字吓到，它本质上就是一个基于 Spring Boot 提供接口、用微信小程序做用户端的典型前后端分离项目，只是把业务场景换成了文物科普。“江西文物时讯”就是这类项目中很常见的命名方式，前端小程序，后端 Spring Boot，数据上有江西本地文物内容做支撑，很容易讲出完整的业务故事。这篇文章我按做毕设的完整流程，把定题、后端设计、小程序开发、内容准备、归档答辩这些环节里真正值得注意的东西拆开聊一遍，尤其是那些会让项目卡壳的细节，都会单独拿出来讲。

1. 选题结构拆解：这样的题为什么“有得写”又不会做崩

1.1 先从题目里看出它需要哪些功能

“博物馆文物科普知识普及系统微信小程序”看着像一句话，实际上已经限定了三个层面：一是领域是博物馆文物科普，二是说“普及知识”，意味着不只是简单列文物，还要有点科普性质的内容，三是载体是微信小程序，用户点开就能用。把这三个层面翻译成功能，就是：用户可以浏览文物列表，点进详情看介绍和图片；可以按年代、材质、类别筛选；可以搜索文物或文章；对感兴趣的文物可以收藏；另外还得有一块“科普内容”的展示区，比如专题文章、文物故事，甚至可以在线答题检验知识。管理员则要能维护文物信息、发布科普文章、管理分类。

这其实就是一套标准的“内容型小程序”，但好处在于它的业务数据天然有层次，不会像“学生管理系统”那样做完一个 CRUD 就没事干了。文物信息本身属性丰富，有名称、年代、出土地点、材质、尺寸、馆藏单位、图片、详细介绍，还有关联的科普文章和答题选项，光是字段设计就比普通单表 CRUD 有内容可讲。

1.2 用户角色和功能边界：一定要把“不做哪些”写清楚

很多做这种题的同学容易犯一个毛病，就是想着反正也不难，顺手给小程序里塞一堆功能，做答题、做收藏还不够，又想做评论、做分享、做积分。我给这类项目的建议是收敛边界，角色只做三类：游客可以浏览、收藏、答题；管理员维护内容；系统本身自动处理推荐和统计。至于支付、多级评论、自建会员体系，尽量不要碰，博物馆科普场景用不上，反而会把毕业设计的重点搅浑。

答辩时老师问“你这个系统有什么特色”，你只要能说清楚“面向公众的文物科普，重点是把知识内容组织好，让用户能有效获取信息”，比堆功能更能说明你做过需求分析。

1.3 为什么“Spring Boot + 微信小程序”是稳定组合

从技术实现上看，Spring Boot 负责提供 ResticAPI，是小程序的数据来源。之所以推荐这种组合而不是搞个纯前端静态页面，是因为 Spring Boot 后端的接口、数据库、登录态、分页、文件上传这些技能点，是当前计算机专业培养方案里最常见的考核点，老师看见你用了 Spring Boot，至少不会觉得框架没学过。小程序端则承担页面渲染和交互，免安装，演示的时候在微信里直接打开，比做 App 要省事，也比做纯 Web 网站更有“移动应用”的感觉。

从工作量核算角度，这个题后端大约写 12 到 15 个接口就够完整演示了，小程序端 8 到 10 个页面，数据库 7 到 8 张表。对大多数学生来说，这正好是“自己写两个星期能完成，但每天都有推进感”的体量，不会拖到最后赶工。

2. 后端设计“先把表定明白”，再谈接口和科普内容的展示逻辑

2.1 数据库建模：不是只有一张“文物表”

我见过不少同学做这类东西，上来就建一张 artifact 表，字段写满，然后说系统做完了。实际上如果数据库里只有一张表，后面想做收藏、答题、管理员内容发布，都只能硬编码，文档也写不出花来。按“江西文物时讯”这个需求，稳妥的做法至少要考虑这么几张表：

• 用户表：字段不需要太复杂，关键是 openid 唯一标识，再存昵称、头像、注册时间。
• 文物分类表：比如一级分类按材质分（陶瓷、青铜、玉器、书画、杂项），二级分类按时间或主题（新石器时代、商周、秦汉、海昏侯文化、陶瓷文化）。
• 文物信息主表：这是最核心的一张表，存放文物的名称、年代、材质、尺寸、出土地点、收藏单位、封面图、详情富文本、是否热门、浏览量、所属分类。
• 文物图片表：如果每件文物要展示多张图，建议单独建一张表。很多同学把多图塞进一个 varchar 字段用逗号分隔，短期能跑通，但答辩时容易被问“如果图片有几十张怎么办”，所以拆表更合理。
• 科普文章表：用于发布类似“海昏侯墓里为什么有这么多马蹄金”的专题文章，字段包括标题、封面、正文、发布时间、关联文物 ID。
• 收藏表：用户 ID + 文物 ID 联合唯一，加分的是存一下收藏时间，方便按时间倒序展示。
• 答题记录表：字段相对简单，用户 ID、题目 ID、用户选项、是否正确、作答时间。
• 题目表：可以单独设计，包含题干、选项 A/B/C/D、正确答案、题目解析、关联文物 ID。

字段设计时还有一个很普遍的问题：不要用用户的手机号或昵称做唯一键，必须用 openid 或者后端生成的用户 ID。微信小程序登录后，后端拿到的唯一稳定标识就是 openid，用它作为用户表的主键逻辑能省非常多的事。

给一张文物主表字段示意，你写文档的时候可以照这个思路去列：

2.2 接口设计要覆盖一个完整的用户操作闭环

后端的接口数量不在多，而在能不能跑通“用户从进入到使用完离开”的完整链路。对于一个科普小程序，用户进来第一眼是首页，所以要提供首页数据聚合接口，返回轮播图和热门文物；想继续看，需要分页文物列表接口和搜索接口；点击一个文物需要详情接口，详情里会展示基本信息、科普全文、相关图片；想收藏，得有收藏/取消收藏接口和我的收藏列表接口；想学习科普知识，需要文章列表接口和文章详情接口；个性化一点，可以做每日一文物和随机答题接口。

这中间比较容易忽视的是：小程序用户很多操作在“未登录”状态下也需要可用。比如游客浏览详情不需要登录，等点击收藏时才要求登录。所以接口设计上，建议把大部分查询接口都设计成无需 token 就能访问，只有收藏、答题提交、获取个人收藏列表这些需要身份识别的接口才校验 token。这样演示时逻辑也顺，用户逛了一圈觉得内容不错，产生了收藏动作，才自然触发登录。

2.3 “每日推荐/随机答题”这类逻辑别写复杂

有的同学会把“每日推荐”做成定时任务，每天凌晨跑一个 Job，把当天要展示的文物 ID 更新到一张配置表里。从架构角度讲没错，但毕设里这么做收益并不高，反而把代码搞复杂。更实用的方案是接口里直接用 SQL 查库，取浏览量最高的前几条作为热门推荐；如果想带点随机性，就查出一批后再随机挑一条返回。这样既达到了“科普内容每天不重样”的产品效果，代码量也不大，文档里也好解释。

答题逻辑也同理，随机从题库抽 10 道单选题，一次性返回给小程序端，由用户在本地作答完后把结果提交给后端保存。不要在前期就纠结“要不要防止作弊”“要不要限时交卷”，这些内容对毕业设计来说属于过度设计。

2.4 Spring Boot 工程落地时容易被问到的几个技术点

后端能跑起来只是第一步。真正反映基础水平的通常是统一返回结构、全局异常处理和数据库配置这几块。接口返回值建议统一格式，比如 code + message + data，前端拿数据时直接解析 data，不用每个接口都判断一次。分页也一样，搞一个统一 PageResult，把 total、records、current、size 封好，后面无论做文物列表、文章列表还是收藏列表，都复用同一套结构。

还有文件上传的问题。毕设里如果涉及后台录入文物图片，图片一般先传到服务器本地目录，再把访问路径存进数据库。常见错误是直接存“D:\project\upload\xxx.jpg”这种绝对路径，HTTP 接口根本访问不到，而且换台电脑就跑不了。正确做法是后端配置一个虚拟路径映射，把 /upload/** 映射到本地磁盘目录，数据库存的只是相对路径，返回给前端时再拼上服务地址和端口。这样项目换个环境，只要端口不变，图片就能正常访问。

3. 小程序前端层次：从 tabBar 到登录态再到页面数据流

3.1 页面结构建议：首页、分类、我的三大块

小程序端页面不建议铺太多。常见的“江西文物时讯”结构可以是三个 tab：首页、分类、我的。首页这里放 swiper 轮播图、热门文物横向滑动、专题科普文章列表公告；分类页用来按陶瓷、青铜、玉器等材质查看文物，也可以切成瀑布流；我的页面负责展示登录状态、我的收藏、我的答题记录和意见反馈。

如果还想做得更像一个科普平台，可以在首页上面加一个搜索入口，点击跳转到独立搜索页。这样一来，首页承担“推荐+展示”，分类页承担“找内容”，搜索页承担“精确找”，我的页面承担“沉淀的用户行为”，四条访问路径都非常清晰，答辩时可以用这句来概括整个信息架构。

3.2 请求层封装：提前留好接口地址入口

小程序里最忌讳每个页面直接 wx.request 写死地址，后面后端端口或 IP 变了，全局到处改。编码前先建一个 config 文件，把 baseUrl 单独放一个变量，再封装一层 request 方法。以原生小程序为例：

javascript复制// utils/request.js
const config = require('../config/index')

function request(url, method = 'GET', data = {}) {
  return new Promise((resolve, reject) => {
    wx.request({
      url: config.baseUrl + url,
      method,
      data,
      header: {
        'content-type': 'application/json',
        'token': wx.getStorageSync('token') || ''
      },
      success(res) {
        if (res.data.code === 0) {
          resolve(res.data.data)
        } else {
          wx.showToast({ title: res.data.message, icon: 'none' })
          reject(res.data)
        }
      },
      fail(err) {
        reject(err)
      }
    })
  })
}

module.exports = { request }

这样做的好处是：第一，token 自动携带，不用每个接口手动传；第二，后端返回结构统一解析，页面里拿到的是已经剥掉 code 和 message 的业务数据；第三，后续如果换上线域名，只改 config 里的一个变量。

3.3 登录流程：小程序端最容易翻车的地方

先说结论：微信小程序登录，最稳妥的姿势是把登录动作绑定到用户点击上，比如用户点“微信一键登录”按钮。点击后先调 wx.login 拿到临时 code，再把 code 通过后端接口发出去，由后端拿 code 去向微信接口换 openid 和 session_key，后端生成你自己的 token 返回小程序，小程序存到 storage 里。后续所有需要身份的请求带上这个 token。

这个流程里我最想提醒的是两个反直觉点。第一，wx.login 并不是在 app.onLaunch 里调用一次就万事大吉，如果 code 换 openid 失败，或有多个页面都需要登录，就会出现“小程序获取登录后的微信用户失败”的报错。第二，后面为了拿用户头像昵称调的 wx.getUserProfile，只是在收集展示信息，不能替代真实登录认证。你可以在“我的”页面放两段逻辑：先调 login 接口完成账号体系登录，再引导用户通过 getUserProfile 完善头像昵称，两步分开做，链路最稳。

小程序端还有一个老坑：开发者工具里模拟器能正常登录，到了真机上点登录没反应。这个时候优先看 request 合法域名，开发阶段可以在“详情-本地设置”里勾选“不校验合法域名”，但演示或发布前必定要换成备案过的 HTTPS 域名。

3.4 首页与详情页的数据流：从拉取到绑定的完整链路

页面数据流建议统一遵循：onLoad 里拉取初始化数据，data 里定义列表变量，渲染用 wx:for。以首页为例，onLoad 时并行发出“获取轮播接口”和“获取热门文物接口”两个请求，可以用 Promise.all 同时处理，拿到结果后分别 setData，然后渲染 swiper-item 和横向 scroll-view 列表。

详情页则需要处理一个容易被忽视的问题：富文本中的图片宽度不会自动适配小程序。后端存的 detail_content 如果是从百科复制来的 HTML，里面的 img 大概率是原始尺寸，手机上显示会超出屏幕。通常解决办法是在后端返回详情之前做一次字符串替换，把 img 标签统一追加 style="max-width:100%;height:auto;"。如果后端不方便处理，也可以在小程序端拿到 html 后用正则替换，但要留意 WXML 里不能直接执行，得用 rich-text 节点绑定处理过后的字符串。

3.5 收藏、搜索、答题三个交互点怎么实现才算完整

收藏功能属于典型的状态切换：进入详情页时先请求“当前用户是否收藏了该文物”，然后根据布尔值渲染心形图标；点击后调后端切换接口，成功后本地取反，再给用户一个轻提示。这里注意防止用户连续快速点击，导致请求并发发出多条。简单做法是请求期间用一个 isRequesting 变量锁住，拿到响应后再解开。

搜索功能最容易被扣分的是“连点请求”问题。用户每输入一个字就请求一次后端，会被问“如果一万人次同时搜索怎么办”。规避方式很简单，在监听输入事件时加入防抖函数，延迟 400 毫秒左右再发出请求，这个技术点写进文档还能体现你考虑过性能优化。

答题模块建议做成独立的答题页：从题库接口拉取 10 道题，本地维护 currentIndex、selectedOption、score 三个状态，用户选择后把答案暂存数组，点击下一题时更新索引，最后点提交时一次性把答案集合传给后端，由后端比对计算得分并返回解析。这种设计在小程序端交互流畅，后端压力也小。

4. 联调踩坑实录：登录失败、富文本图片不显示、Spring Boot 版本过高

4.1 “小程序获取登录后的微信用户失败”是怎么排查的

这个报错热点被搜索得非常多，实际上背后至少有三种完全不同的原因，而报错提示都差不多。

头一种，把 wx.getUserProfile 放在了页面 onLoad 的生命周期里直接调用。微信基础库更新后，用户信息相关接口必须由用户点击行为触发，否则直接 fail。解决办法是所有涉及用户信息的弹窗或者按钮，都必须绑定在 button 的 bindtap 事件回调里，不能在 setData 回调或定时器里间接触发。

第二种，后端用 wx.login 的 code 去换 openid 时，code 已经过期。code 的有效期只有五分钟，如果小程序先拿了 code 存起来，隔了很久才发给后端，就会报无效。正确顺序是点击登录的那一刻再 wx.login，然后立即把 code 发给后端，链路不要中断。

第三种更隐蔽，后端 java 代码请求微信接口时，该用 GET 却用了 POST，或者参数 appid 和 secret 拼错了，导致微信服务器一直返回 errcode 40013。排查这种问题时，先不要在小程序端反复调试，建议直接用 Postman 模拟后端调微信接口，把微信返回的原始报文打出来看，问题基本一眼就定位了。

4.2 Spring Boot 版本选太高：毕业设计里非常典型的翻车点

很多同学图新鲜，从官网脚手架直接默认下载 Spring Boot 3.x 甚至更高版本，结果项目怎么都启动不起来。3.x 之后包名从 javax 改成了 jakarta，JDK 版本要求也提到了 17，如果你的毕设开发环境还是 JDK 8，一定会遇到一堆无法 import 的类。

这种情况下面临两难：改 JDK 版本意味着整个环境要重装；改代码等于把教程里所有示例代码的 import 都换一遍。对一个求稳的毕业设计来说，除非你是想专门研究新特性，否则不建议折腾。我做过很多毕设辅导，最稳的组合就是经典搭配：

xml复制<parent>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-parent</artifactId>
  <version>2.7.18</version>
</parent>

JDK 用 1.8，MyBatis-Plus 用 3.5.x 系列，MySQL 连接驱动选 mysql-connector-java 8.0.33。这套组合经过大量项目验证，社区资料也丰富，遇到问题基本能搜到现成答案。千万别小看版本带来的连锁反应，有时候你花两天查一个 bug，最后发现只是 spring-boot-starter 版本和你本机 JDK 不匹配。

4.3 富文本里的图片在模拟器正常、真机上却不显示

排查这个问题要分两个方向。

第一个方向是看图片域名。模拟器因为开了“不校验合法域名”所以能显示，真机一旦没有在微信公众平台配置 downloadFile 合法域名，请求就会被拦截。如果后端地址是 http://localhost 或 http://192.168.x.x，真机必挂。这里没有捷径，要么后端上线到备案过的 HTTPS 域名，要么开发调试阶段在真机上开启调试模式（右上角菜单里的“开发调试”开关），但这只是临时手段。

第二个方向是图片源本身。有些百科文章里的图片做了防盗链，你在电脑浏览器访问不受影响，但在小程序里请求会返回 403 或者空内容。这种情况在代码层面解决不了，必须把图片重新下载后传到自己的服务器或对象存储里。

我当时做类似项目时的处理方式是在后台管理端加了一个“富文本图片下载并替换”的辅助接口，发布科普文章时自动扫描正文，把所有外链图片下载到本地资源目录，再把正文里的 src 替换成我们的地址。这个功能答辩时非常加分，因为你能讲出“为什么要做它”的完整故事。

4.4 本地后端在小程序真机上连不上的排查链路

本地开发最常见的问题就是模拟器能打开首页，手机扫码后页面空白或者加载失败。排查顺序建议这样走：

先在电脑上确认后端启动在 0.0.0.0:8080，不要只监听 127.0.0.1，不然局域网设备访问不到。然后手机和电脑连同一个 Wi-Fi，用手机浏览器访问 http://电脑局域网IP:8080/某个接口路径，如果能出 JSON 说明网络通，出不来就查防火墙或者路由器是否开了 AP 隔离。最后再把小程序的 config 文件里的 baseUrl 改成局域网 IP，重新编译。如果项目要长期演示，最省事的做法还是买一台轻量云服务器，把后端放上去，小程序直接请求公网 HTTPS 接口，省去一堆本地联调问题。

5. 把系统“喂饱”：江西文物内容怎么组织才像那么回事

5.1 选题自带地域文化优势，内容上要有真实素材感

“江西文物时讯”这个名字比“文物科普系统”好的地方在于，它明确指向江西，所以内容准备可以围绕江西观众熟悉的文物展开，演示的时候亲切感会更强。做这类毕设最怕的是后台空空如也，点进去任何列表都是空白。内容准备不仅是填充数据，也是展示你需求调研能力的机会。

可以围绕几个文化标签去准备第一批评文物数据。江西新干大洋洲出土过商代青铜器，比如伏鸟双尾青铜虎，造型很独特，适合做热门文物；南昌海昏侯墓出土的刘贺玉印、马蹄金、漆器，自带话题度，适合做成科普专题；万年仙人洞遗址出土的早期陶片，对理解人类文明史有帮助；景德镇的青白瓷、吉州窑木叶盏则能串起一条陶瓷文化线。每一件准备 15 到 20 条，整个系统就很有看头。

5.2 详情内容要按“科普视角”来写，不是照抄百科

很多同学会把文案直接复制粘贴一段百科介绍，然后存进数据库。这样做不是不行，但详细页看起来就是一个大段文字，缺乏阅读节奏。建议把详情拆成结构化的几块：先用一句话介绍这件文物“是什么、为什么珍贵”，然后列一个基础信息表，再讲它的发现故事或工艺特点，最后加一个“延伸知识点”小栏目。

以海昏侯马蹄金为例，前端详情可以这样组织：

这样每件文物的详情页既不像干巴巴的字段堆砌，又比整段复制百科更有阅读性，用户也确实能学到东西。这一点在论文准备阶段，可以作为“系统内容设计”章节的亮点去写。

5.3 图片来源与版权问题要提前规避

做文物科普系统，图片来源绕不开版权问题。尽量从博物馆官网、公开的文物数字资源平台找高清图，或者自己用建模软件画简单的示意图，保存时在数据库里加一个来源备注字段，内部标注清楚。这既体现你的严谨性，也能避免论文查重或演示时卷入侵权麻烦。

6. 毕业设计的交付与答辩：程序、文档、讲解、定制四件事怎么收口

6.1 程序之外，“文档”是决定能不能过审的半条命

毕设最终交付通常在标题里会写“程序+文档+讲解+定制”，说明这套项目不只有代码，还有配套的材料体系。程序指的是工程源码，文档则主要包括开题报告、任务书、毕业论文、答辩 PPT。很多技术做得不错的同学最后栽在论文上，原因不外乎两类：一类是论文结构和实际代码对不上，另一类是数据库设计章节画了错误的表结构。

论文里针对这种系统，至少要有需求分析、总体设计、数据库设计、系统实现、系统测试几个核心章节。数据库设计这里，把 ER 图和表结构文档写整齐，每个表列出字段名、类型、说明，再用文字解释表之间的关系。这部分内容不需要多高深，但必须和实际数据库完全一致，否则老师一运行你的代码就会发现文档是编的，影响非常差。

6.2 演示与讲解：怎么讲才能让老师觉得工作量饱满

答辩演示时不要一上来就切后台管理系统一顿操作。我给学生的建议是按“业务故事”去演示：先打开小程序首页，说说游客能看到什么内容；再搜索一件文物，点进详情，展示富文本介绍；然后点收藏，此刻触发登录，讲一下 openid 和 token 整套流程；进入“我的”页面能看到刚收藏的文物；再进入答题模块，做几道题；最后切到后台管理端或直接连数据库，演示新增一件文物后小程序端立刻能看到该文物。整个流程约八到十分钟，覆盖功能全面，也把前后端联调的关键点都讲到了。

如果条件允许，录一份演示视频放在文档里。讲解时可以重点给老师展示两处设计：一处是后端的数据校验和统一异常处理，一处是前端请求封装和防抖。这两块都属于“普通功能之外的工程化考虑”，最容易给答辩加分。

6.3 面对“如果用户量大了怎么办”这类问题怎么回答

答辩老师几乎必问“你这个系统有什么不足”。不建议你回答说“没有不足”，可以对这个问题做合理包装：当前系统是为满足课程设计和文物科普展示场景开发的，采用简单高效的单体架构；如果未来用户量增加，可以优先把静态资源迁移到对象存储，将后端按接口模块拆分，并把高频访问的文物列表接口加上缓存。这样可以体现你了解演进方向。实事求是地讲，毕设无法也不需要在用户量支撑上做文章，单体架构在数据量几千条的情况下性能完全够用。

6.4 “定制”意味着核心还是你自己消化过这套代码

有的同学是直接拿了现成项目交差，代码都没完整看一遍，答辩时被老师问到一个变量名就卡住了。这种题再简单也帮不了你。哪怕你的角色是做二次开发或者只改界面，也要把每个模块的调用链自己走一遍。比如从“小程序点击收藏”开始，到请求封装，到 Controller、Service、Mapper，最后落到数据库表，每一步都清楚中间经过了谁，写了哪条 SQL、更新了哪个字段。你能把这个链路讲明白，答辩自然稳。

关于这套文物科普小程序，我最后想补几句

带这类项目这些年，我最大的体会是，它看起来很温和，难点全藏在细节里。表结构一上来就要想清楚，登录链路必须在真机上反复测，富文本图片问题要提前做兼容，Spring Boot 版本别盲目求新，内容要提前准备而不是最后补。只要你把上面这些点都过一遍，它就是一个兼具展示效果和工程完整度的毕业设计。如果老师临时让你加模块，从“科普文章评论”或者“答题排行榜”入手会比较顺手，数据模型稍微扩展一下就能接上，不会推翻已有代码。希望这篇复盘能让你少走几个弯路，把力气花在真正能体现工作量的事情上。