章晓红1. 为什么这套技术组合最适合当作毕设主线
每年到毕业季，我都能看到相当一批计算机专业的学生在选题阶段反复横跳。今天看人工智能热门想搞图像识别，明天觉得区块链高大上想碰一碰，最后兜兜转转发现时间不够、环境装不上、数据集找不到，只能回头求稳。如果你现在手里攥着“springboot校园场景应用小程序”这个题目，我可以直接告诉你：这个选题放在毕设评价体系里，属于那种“下限不低、上限很高”的类型。
先说下限。Spring Boot加微信小程序这套组合，市场上资料多到溢出来，从环境搭建到部署上线的完整教程一搜一大把，哪怕你基础薄弱，照着走也能把项目跑起来。高校答辩老师的关注点通常集中在三块：第一，系统能不能完整跑通核心业务；第二，数据库设计是否合理、表之间关系是否清晰；第三，技术上有没有值得问两句的亮点。这套技术栈恰好能把这三块都覆盖到位。
再说上限。校园场景听起来简单，但实际上它是一个典型的“多角色、多业务、多权限”的小型中台场景。学生端要查课表、看成绩、找活动、失物招领，管理员端要维护用户、发布通知、审核内容，不同角色有不同的操作权限和视图。把这样一个系统做扎实，你需要考虑的远不止“增删改查”，还涉及登录鉴权、状态管理、缓存策略、接口规范、异常处理这些真刀真枪的问题。这些恰恰是答辩时最能体现你专业水平的地方。
我见过不少做类似题目的学生，最后交上来的东西变成了一个功能堆砌的“大杂烩”，课表模块抄一个开源项目，二手市场抄另一个开源项目，拼在一起风格不统一，代码质量参差不齐，一问三不知。这个题目的核心价值不在于“功能多”，而在于“场景真”。你服务的是校园里真实的用户，有真实的使用路径和交互习惯，把这些梳理清楚，比多写两个无人问津的功能模块有价值得多。
另外还有一层现实考量：Spring Boot对应的是 Java 后端体系，这是国内企业级开发的主流方向，就业市场的需求量一直很稳定。微信小程序则是目前 C 端产品触达用户成本最低的形态之一。做完这个项目，你简历上可以写的技能点十分清晰：Spring Boot、MyBatis-Plus、Redis、微信小程序原生开发、RESTful API 设计、JWT 鉴权。这些关键词每一个都有对应的岗位需求，不存在“做完就扔”的问题。
所以我的建议是：如果你已经拿到这个题目，别纠结，别推翻，顺着这条路往下走，把它做成一个“业务逻辑完整、代码结构清晰、有几个能打的亮点”的作品。接下来这篇文章，我就按我自己做这类项目的经验，从需求边界、后端搭建、小程序端实现、踩坑排查、答辩加分这五个维度完整拆一遍。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 校园场景的业务边界：先砍需求再定方案
很多毕设翻车，不是死在技术上，而是死在需求没定清楚。校园场景这个说法太宽泛了，课程表是校园场景，图书馆占座是校园场景，校园跑腿也是校园场景。你不可能全部做，也不应该全部做。第一步要做的事情是划定边界。
2.1 两角色三模块的起步配置
我建议最稳的方案是：基于学生和管理员两种角色，做三个核心模块加一个基础模块。
三个核心模块分别是课程表与学习安排、校园活动管理、失物招领与二手交易。基础模块是个人信息与消息中心。为什么选这三个？因为它们分别对应了学生在校园里最刚需的三类诉求：时间管理、信息获取、物品流转。难度上有梯度，既有简单的 CRUD，也有相对复杂的业务逻辑，方便你循序渐近地开发。
课程表模块看起来只是展示，但这块恰好是最容易出彩的地方。你可以把课程表做成按周次展示的模式，支持学期起始日期设置、单双周课程区分、考试安排提醒。后端关联课程表、选课关系表、学期配置表三张表，前端用表格或网格形式渲染，数据量大一点也完全扛得住。
校园活动模块可以设计得再丰富些。活动发布、报名、名额限制、签到、活动评价，这几个动作连起来构成一个完整的业务流程。这个模块最能体现你对“状态机”的理解——一个活动从草稿、报名中、进行中到已结束，每个状态能做什么操作，前端按钮怎么切换，后端接口怎么限制，都是答辩时可以展开讲的东西。
失物招领和二手交易可以合并到一个模块里，都是“信息发布-浏览-联系-状态变更”的模式，但要注意区分：失物招领侧重时效性和认领流程，需要发布者标记“已找回”；二手交易侧重商品描述和价格，需要支持图片上传和“已售出”状态。这两个业务放到同一套代码里，表结构有所不同，正好展示你对表设计的思考。
2.2 管理员端的功能配比
管理员端不要做得太重，但也不能没有。最理想的状态是：学生端能自助完成的事情，管理员端只做审核和监管。比如学生发布失物招领信息后需要管理员审核通过才能展示，活动报名人数异常时管理员可以手动关闭报名通道，用户发布违规内容时管理员有下架权限。
这部分业务后端要做两套权限体系。学生端走普通用户接口，管理员端走管理接口，通过拦截器对请求路径做权限校验。不必引入 Spring Security 这种重框架，用拦截器加自定义注解的方式，既容易理解也能说清楚原理，答辩老师问起来你能讲得明明白白。
2.3 砍需求的原则
砍需求不是随便砍，要遵循一个核心原则：每一个功能模块都要能讲清楚“谁在用、解决什么问题、数据怎么流转”。凡是这三个问题答不上来的功能，都是伪需求。
举个例子，“校园地图导航”这个功能听着很炫，但你仔细想就会发现，微信小程序里直接跳转腾讯地图就解决了，根本不需要自己做。再比如“校内论坛”这种大而全的东西，涉及内容审核、敏感词过滤、帖子管理，工作量巨大且风险高，对于毕设来说性价比极低。
我见过最好的做法是：把需求定在一个“学生一天的生活动线”上。早上打开小程序看一下今天有什么课，课间刷一下失物招领有没有人捡到自己丢的东西，中午看看今天的校园活动，晚上顺手把用不上的教材挂到二手集市。这个场景一旦立住了，你的每一个功能都能对上真实需求，答辩的时候讲故事也会顺畅很多。
3. 后端骨架搭建：从建表到登录态那几条关键线
后端是整套系统的地基，地基打不牢，后面所有功能都会摇摇晃晃。我按自己一贯的做法，把后端搭建过程拆成几条线：建表、搭工程、做登录态、写统一返回和异常处理。每条线都直接关系到后续开发的效率。
3.1 建表原则与核心表结构
数据库设计这块，我强烈建议用 MySQL，版本选 5.7 或 8.0 都行，区别不大。表结构上，除了业务表之外，一定不要省掉这几张基础表：用户表、角色表、用户角色关联表。角色表哪怕只有两条数据（学生、管理员）也要建，因为权限体系的设计需要这张表作为支撑。
核心业务表的命名要清晰、字段要克制。以课程表模块为例，我常用的方案是三张表：课程表（course）、选课记录表（course_selection）、学期配置表（semester_config）。课程表存课程基本信息，包括课程名、授课教师、上课地点、周次规则（单周或双周）、开始节次、结束节次。选课记录表关联学生和课程，一个学生可以选多门课，一门课可以被多个学生选。学期配置表存当前学期起始日期和总周数，前端课表展示时要拿它来计算当前是第几周。
活动模块的表结构稍微复杂一点，除了活动主表（activity），还要有报名表（activity_signup）。活动主表的核心字段包括活动标题、封面图、活动地点、开始时间、结束时间、报名截止时间、名额上限、当前报名人数、状态。注意“当前报名人数”这个字段，初学者容易忽略，但它的价值在于：前端需要实时展示“余量”，你总不能每次看余量都去 count 一遍报名表。报名表要加一个唯一索引（activity_id + user_id），防止同一个用户重复报名同一活动。
失物招领和二手交易合并成一张“物品信息表”（item_info），用类型字段区分是失物还是二手商品。字段包括标题、描述、图片 URL、物品类型、状态、发布人 ID、发布时间。状态要区分：失物有“寻找中/已找到”两种，二手有“在售/已售出”两种，用字典值管理，前端按类型映射展示。
3.2 Spring Boot 版本选择：别在版本上给自己挖坑
关于 Spring Boot 的版本，我必须单独说一段，因为热搜词里有“springboot版本太高”，这个坑我见过太多人踩了。
现在的 Spring Boot 已经出到 3.x，但 3.x 有一个让很多教程失效的变化：javax 包名改成了 jakarta。如果你的参考教程、网课视频、开源项目是基于 2.x 写的，而你新建项目选了 3.x，那么很多代码直接复制过来会报错，因为 import javax.servlet 找不到了。与此同时，很多第三方组件对 3.x 的适配还不太完善，特别是部分旧版 MyBatis-Plus 插件、代码生成器、Swagger 相关依赖。
我的建议很直接：如果你是照着教程做毕设，首选 Spring Boot 2.7.x，这是 2.x 系列的最后一个稳定版本，资料最全，踩坑经验最丰富，第三方组件兼容性最好。JDK 对应选 8 或 11。不要觉得用旧版本就不上档次，答辩老师关心的是你的系统能不能稳定跑起来、逻辑是否清晰，而不是你用不用最新的版本号。
等到你做完主体功能，还有余力的话，可以再研究一下 3.x 的迁移差异，把这个当做一个加分点写进论文的“技术选型”部分，讲清楚两代版本的核心变化，反而更能体现你的学习能力。
3.3 登录态设计与 Redis 的参与方式
小程序端的登录态设计和 Web 端不一样，核心原因是小程序没有传统的 Cookie 机制，也没有 Session 容器可以直接用。标准做法是：小程序调用 wx.login 拿到一个临时 code，后端拿这个 code 调用微信接口换 openid，然后由后端签发一个 token 返回给前端，前端后续请求都带上这个 token。
这个链路里有两个关键细节要注意：
第一，code 换 openid 的接口调用是异步的，而且有网络超时风险，所以后端的登录接口要做好异常处理，微信接口调用失败时不能直接报 500，要返回一个友好的错误提示，让前端能引导用户重新尝试。
第二，token 的产生方式，我推荐用 JWT（JSON Web Token）。JWT 本身携带用户 ID 和角色信息，后端通过拦截器解析 token 就能知道当前是谁在请求，不需要每次都查数据库。这里有个细节，如果你的项目里引入了 Redis，可以把 token 同时存一份到 Redis 里，设置过期时间，这样管理员封禁用户时可以直接删 Redis 里的 token，而不是等它自然过期。
Redis 在这个项目里的参与方式主要有三种：缓存 token、缓存配置信息、缓存热点数据。比如学期配置这种不经常变的数据，第一次查数据库后放进 Redis，后面直接取缓存，可以显著减轻数据库压力。这些内容写在论文里就是实打实的亮点，比单纯写“使用了 Redis”有说服力得多。
3.4 统一返回结构与全局异常处理
统一返回结构这件事，工作量不大，但对代码整洁度和答辩观感的影响极大。很多初学者的接口返回五花八门：有的返回 Map，有的直接返回实体类，有的返回字符串带状态码，前后端联调时痛苦不堪。
我的做法是定义一个 Result
全局异常处理用 @RestControllerAdvice 注解实现。写一个全局异常处理器，把参数校验异常、业务异常、未知异常分别映射到不同的返回结果。这样带来的直接好处是：后端代码里不需要到处写 try-catch，业务逻辑写起来干净利落，出现问题时错误信息又足够明确。答辩时老师问你“你的系统异常是怎么处理的”，你回答“我们有全局异常处理机制，业务异常和系统异常分开处理”，这个回答的含金量立刻就上来了。
4. 小程序端三件头疼事：登录、动态标题与请求封装
小程序端是最容易让初学者心态爆炸的部分。真机调试、开发者工具、基础库版本、组件样式，每一层都有说不完的坑。这里我挑三个最常见、最影响开发效率的点展开讲。
4.1 登录链路：为什么不能简单用 wx.login
先说一个最常见的错误认知：以为 wx.login 的返回值里就带着用户身份信息，直接拿去后端的数据库里比对就能登录。实际不是这样。wx.login 拿到的 code 是一次性的临时凭证，它的唯一用途是交给后端去微信的接口换 openid，这个流程在微信官方的文档里叫 code2Session。
这个流程的正确时序应该是：小程序端先调用 wx.login 拿到 code，再调用后端自己定义的登录接口（比如 /api/auth/login），把 code 传过去。后端收到 code 后请求微信接口，拿到 openid 和 session_key。openid 是用户在小程序里的唯一标识，用它去数据库里查用户，查到就更新登录时间，查不到就自动注册一个新用户。最后后端签发 token 返回给小程序端。
这里有一个体验层面的设计决策：用户在登录时要不要填写昵称和头像？我的建议是首版不要强制。先体验后完善，用户进入小程序后直接以“游客”身份浏览，到需要发布内容时才引导完善资料。这么做的好处是降低了首次使用的门槛，活动浏览、失物查询这些只读操作不需要登录就能看，真正发帖子时才要求登录，转化率会高很多。
4.2 动态设置标题的完整方案
“小程序动态设置标题”这个热搜词背后，是很多人在 tabBar 页面和非 tabBar 页面的标题切换上踩了坑。微信小程序的页面标题有两个控制层级：第一层是全局配置 app.json 里的 window.navigationBarTitleText，第二层是页面级配置 index.json 里的 navigationBarTitleText，第三层是运行时通过 wx.setNavigationBarTitle 动态修改。
tabBar 页面的标题比较特殊，它会默认展示 app.json 里 tabBar.list 中配置的 text 字段，直接在页面的 onLoad 里调用 wx.setNavigationBarTitle 是无效的，偶尔生效但极不稳定。正确做法是在 onShow 里调用，每次页面重新展示时重新设置。另外，动态设置标题时要注意一个问题：wx.setNavigationBarTitle 的 title 参数最长 10 个汉字，超过会被截断，实际开发中要注意做字数控制。
还有一个细节容易被忽略：如果你用了自定义导航栏（在页面配置里设置 navigationStyle: "custom"），那么 wx.setNavigationBarTitle 就完全失效了，因为导航栏已经不归系统管了，你得自己在自绘的导航栏组件里通过数据绑定来修改标题文字。两种方案各有优劣，毕设项目建议用系统导航栏，省事稳定，自定义导航栏是加分项，但增加了工作量。
4.3 request 封装和登录态过期处理
小程序端最核心的基础模块之一就是 request 请求封装。这东西做得好，后面每个页面写起来都像在写伪代码一样轻松；做得不好，每个页面都堆一堆重复代码，改个接口地址要全项目搜索。
核心思路是：封装一个 request 函数，统一处理 baseURL、header、token 注入、响应拦截、错误提示这五件事。
javascript复制const request = (url, method = 'GET', data = {}) => {
return new Promise((resolve, reject) => {
const token = wx.getStorageSync('token')
const header = {
'Content-Type': 'application/json'
}
if (token) {
header['Authorization'] = 'Bearer ' + token
}
wx.request({
url: getApp().globalData.baseUrl + url,
method: method,
data: data,
header: header,
success(res) {
if (res.data.code === 200) {
resolve(res.data.data)
} else if (res.data.code === 401) {
// token 过期或无效，清理登录态，跳转登录页
wx.removeStorageSync('token')
wx.removeStorageSync('userInfo')
wx.navigateTo({ url: '/pages/login/login' })
reject(res.data)
} else {
wx.showToast({ title: res.data.message, icon: 'none' })
reject(res.data)
}
},
fail(err) {
wx.showToast({ title: '网络异常，请稍后重试', icon: 'none' })
reject(err)
}
})
})
}
注意上面对 401 的处理。小程序里很多页面不需要登录就能访问，但当用户执行需要登录的操作时，token 可能已经过期了。如果每个页面都自己判断，代码会非常啰嗦。统一的 401 拦截能保证：登录态失效时，用户被自动引导到登录页，重新登录后可以继续操作。这个体验细节看起来不起眼，但属于“老师一用就能感受到”的工程素养。
登录页的处理也要跟上：登录成功后不能只是存 token，还要拿到用户基本信息存到本地。用户信息可能包括昵称、头像、学号、角色。角色字段很重要，前端要根据角色来显示不同的入口，比如管理员能看到“审核管理”“数据统计”这类菜单，普通学生看不到。角色信息建议存在本地 storage 里，同时 APP 启动时调一个 /api/auth/info 接口拉取最新信息，防止本地数据和数据库不一致。
5. 最容易翻车的地方：几个典型报错的完整排查过程
这部分我专门辟出一章来写，因为毕设项目最后能不能安心提交，很大程度上取决于你能不能快速解决那些“看起来莫名其妙”的报错。下面这几个问题都是高频事故点，我按真实排查链路来还原，而不是直接扔结论。
5.1 “登录用户不是该小程序的开发者”
这个报错我在很多群里见过，搜索词里也有。典型场景是：你在微信开发者工具里点“预览”或“真机调试”，手机上打开小程序后，一进入就提示“登录用户不是该小程序的开发者”。
先解释这个报错的本质：微信小程序有成员管理机制，只有被添加到小程序项目成员列表里的微信账号，才可以使用开发版和体验版。你自己作为小程序的管理员当然没问题，但如果你在机器上调试时用的是另一个微信账号，或者你让同学帮忙一起测试，而对方没有被添加为项目成员，就会出现这个报错。
完整的排查链路是这样的：
第一步，去微信公众平台登录小程序账号，进入“管理-成员管理”，确认当前测试用的微信号是否在成员列表中。不在就添加，有两种角色：管理员和项目成员。项目成员又分运营者、开发者、数据分析者。做真机调试需要至少“开发者”角色。
第二步，检查微信开发者工具右上角的“详情-基本信息”里，AppID 是否选对了。很多人本地建了多个小程序项目，AppID 填混了，导致测试时登录的微信号和当前项目绑定的成员关系对不上。
第三步，确认在开发者工具里用的是“测试号”还是正式的 AppID。测试号是另一套体系，不需要成员管理就能真机预览，但它不能使用大部分正式 API，比如支付、订阅消息等。如果你想完整体验，建议直接用正式 AppID，然后把测试微信号加进成员列表。
还有一类情况比较隐蔽：你用的是企业主体的小程序账号，但测试微信号没有绑定手机号，或者微信号本身存在异常，也会导致校验失败。遇到这种情况，换个微信号测试，先定位是账号问题还是代码问题。
5.2 小程序备案的备注信息到底怎么填
“小程序备案备注信息怎么填”在搜索词里出现，说明现在做小程序确实绕不开备案这道手续。2023 年起，新上线的微信小程序必须完成 ICP 备案才能发布，个人开发者和企业开发者都一样。
备案流程里最容易卡壳的就是“备注信息”这一栏。官方提示写的是“备注需要填写小程序简介、服务内容等”，但很多人不知道具体写到什么程度才合格。以我的经验，标准的填写方式是：两句话结构。第一句话说明小程序的服务性质，第二句话说明目标用户和核心功能。
以本项目举例，可以这样写：
“本小程序为校园服务类应用，面向在校学生提供课程表查询、校园活动报名、失物招领与二手交易等综合信息服务。小程序不涉及新闻、金融、医疗等前置审批项目，所有功能均面向校园内部用户开放，不涉及隐私数据收集与跨平台信息传输。”
这个写法要注意三点：一是明确不含前置审批项目，这能减少被退回的概率；二是不提“用户注册”以外的任何数据存储行为，避免审核员对隐私合规产生疑问；三是字数控制在 200 字以内，简洁有力。备案被驳回最常见的原因是“服务内容描述过于模糊”，所以千万不要只写“校园服务”四个字就提交。
5.3 Spring Boot 版本太高导致的依赖地狱
回到后端这边的坑。“springboot版本太高”这个搜索词背后，十有八九是这种情况：在 start.spring.io 上生成了最新版的 Spring Boot 3.x 项目，然后又从网上找了一套基于 2.x 的教程代码，复制过来后 pom.xml 里一片报红。
初看这个问题会觉得是依赖版本冲突，但其实最核心的问题是命名空间迁移。Spring Boot 3.x 强制要求 javax.* 替换为 jakarta.*，这意味着你复制的代码里所有 import javax.annotation 的注解都要手动改成 jakarta.annotation。如果你的项目同时引用了 MyBatis-Plus 的旧版本，它内部还在用 javax，就会导致运行时找不到类。
我给的解决方案分两步走：
第一步，如果不是必须用 3.x，在项目初始化时直接选 Spring Boot 2.7.18，这是稳定到不能再稳定的版本。JDK 选 1.8 或 11，Maven 仓库所有依赖基本都能找到兼容版本。
第二步，如果你已经用 3.x 建了项目，那就乖乖把所有 import 从 javax 改成 jakarta，同时升级 MyBatis-Plus 到支持 Spring Boot 3 的版本，对应的还有 knife4j 也要换适配版本。这个过程大概需要花半天到一天，而且意义不大，所以我更推荐直接换 2.7.x。
另外，在 pom.xml 里配置 Maven 依赖时，注意用 parent 方式锁定版本，避免多个依赖的传递性版本互相冲突：
xml复制<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>2.7.18</version>
<relativePath/>
</parent>
5.4 微信小程序单选框和头部标题的样式坑
小程序原生组件里，radio 的默认样式非常朴素，而且在一些基础库版本中，直接通过 CSS 修改 radio 的样式会不生效。很多人卡在这里，以为是自己写的样式优先级不够，实际上是因为 radio 内部是原生组件渲染，不是完全可被 style 覆盖的普通标签。
推荐的方案是：用自定义样式替代原生 radio。做法很简单，用 view 加图标代替 radio 组件，选中的图标显示实心，未选中的显示空心，配合点击事件管理选中状态。这个方案不仅样式可控，而且代码逻辑更直观。
头部标题的问题则是另一个维度。很多人发现设置页面标题在开发者工具里有效，但真机预览时标题没有变，或者过一段时间又变回默认值。原因可能是：页面在 onLoad 里设置标题，但这个页面被小程序以某种缓存机制加载了，导致 onLoad 不再触发。解决方式是改成在 onShow 里设置标题，同时每次页面展示时调用。
javascript复制onShow() {
wx.setNavigationBarTitle({
title: '失物招领详情'
})
}
这两个问题都属于“不做就没事，一改样式就各种别扭”的典型。提前知道坑在哪，能省下不少调试时间。
6. 让毕设超出预期的高性价比埋点与答辩准备
如果上面的主体功能都做完了，你已经可以保证拿到一个不错的分数。但如果你想冲击“优秀毕设”或者“最佳实践”的评价，还需要在细节上埋几个亮点。这些亮点的工作量不大，但答辩时效果极好。
6.1 接口文档自动生成
很多毕设项目的接口是没有文档的，前后端联调全靠口头沟通。但你要是引入了 Knife4j（Swagger 的增强版），在 Spring Boot 项目里加一个依赖，写几个注解，就能自动生成一套可交互的 API 文档。答辩时打开 Swagger 页面，老师可以直接看到你所有接口的参数说明和返回结构，专业感瞬间拉满。
关键是这个操作的成本极低：引入依赖、写一个配置类、在 Controller 上补几个注解。有些同学觉得这是“花架子”，但实际项目中 API 文档就是开发规范的一部分，你在毕设项目里体现这个意识，老师会认为你有工程化思维。
6.2 校园活动模块的 ECharts 图表
想让系统有“数据可视化”的亮点，不需要做复杂的后台报表系统，在你的校园活动详情页里，用 ECharts 画一个报名人数趋势图就足够了。活动从开始报名到截止，每一天的报名人数累计下来，画成折线图，用户可以直观看到活动热度变化。
技术实现上，微信小程序用 ec-canvas 组件或使用第三方封装好的 ECharts 小程序版都可以。这个功能的价值在于：它是真实业务数据的可视化，不是单独为了展示而硬画的图表。答辩老师问你为什么做这个图表，你可以回答“让用户判断活动热度”，这个逻辑是通的。
6.3 答辩前的技术点自测清单
临近答辩前，建议按下面这个清单把核心问题过一遍，确保每个问题都能讲出两层以上的深度：
第一，项目架构是什么？你要能说清楚前端小程序、后端 Spring Boot、数据库 MySQL、缓存 Redis 之间的调用关系和数据流向。
第二，权限控制怎么做的？拦截器 + 注解的方式要能完整描述，还要能说清楚 token 里存了什么、Redis 里存了什么。
第三，数据库设计有哪些考量？选几张核心表，解释为什么这么设计字段，是否做了索引，是否考虑了数据一致性。
第四，遇到过最棘手的问题是什么？把第五章的几个坑挑一两个讲，重点放在排查思路和解决方案上，这比任何华丽的项目介绍都有说服力。
第五，系统有哪些不足？千万不要说“没有不足”，要说几个实际存在但短时间内不打算解决的问题，比如“目前课表模块不支持调课通知的实时推送，后续可以引入 WebSocket 或微信订阅消息来优化”。这种回答展示了你的思考深度。
6.4 论文写作的关键段落
论文这块我多说两句。因为毕设分数里，论文往往占了一半权重。特别要注意的是“技术选型”和“系统设计”这两章，一定不要写得像说明书一样罗列功能。
技术选型要写“为什么选它”，而不是“它是什么”。比如 Redis 这一节，你不仅要写“本项目使用 Redis 做缓存”，还要写清楚缓存的数据是什么、缓存策略是什么、缓存和数据库的一致性怎么保证。这些细节才是体现真实水平的地方。
系统设计部分要有图，但不要光贴图不解释。数据库 ER 图旁边要配字段设计说明，业务流程图旁边要配判定逻辑说明。图和文字配合起来，论文的可读性和说服力都会明显提升。
我个人做过一届毕设指导的辅助工作，看到太多学生最后一周通宵赶论文、赶项目，把自己搞得筋疲力尽。其实这类项目只要按节奏走，每周定一个小目标，比如第一周建库建表，第二周完成后端登录鉴权，第三周搞定课程表模块，第四周做活动模块，第五周做失物招领和二手，第六周小程序端整体联调，第七周处理边角问题、写论文，时间完全够用。怕的不是题难，而是没有节奏地东一榔头西一棒槌。
这个项目真正做完之后，你会对“一个完整的全栈系统是怎么从零到一跑起来的”有非常清晰的认知。这个认知比分数本身更值钱，因为它能直接迁移到以后的工作和真实项目中去。