聊一个毕业季绕不开的话题计算机毕业设计到底选什么题目才能不翻车。今天分享的是一个我自己梳理过完整路线的方案——Spring Cloud 架构下的社区图书馆小程序。后端用 Java 微服务支撑业务前端用 JavaScript 完成小程序端逻辑用户在手机上就能完成查书、借书、还书、预约、续借一整条操作链路。这篇内容适合正在准备毕设、想往微服务方向靠但怕驾驭不了复杂度的同学也适合想快速搭一套可演示小程序作品的开发者参考。我会把整个项目从选题、技术选型、服务拆分、前端实现到联调排错和答辩准备完整拆开来讲重点不是给你一份复制粘贴的代码而是把每一步为什么这么设计说透。这样就算你动手改了很多细节答辩时也能接得住老师的追问。1. 为什么把社区图书馆做成毕设题目而不是继续做管理员系统很多同学一开始想到的毕设题目就是某某管理系统——图书管理系统、仓库管理系统、学生管理系统。这类题目不是不行但评委看过的版本太多了很容易问出两个致命问题你的系统解决了什么真实问题和这些功能用 Excel 是不是也能完成社区图书馆小程序的好处在于它有一个真实的业务场景背后的痛点一听就懂。1.1 什么样的毕设选题够得着又有分量先说结论社区图书馆这个题目处在难度适中、业务闭环完整、技术点好挂靠的甜蜜点上。社区图书馆通常不是一个大型公共图书馆更像是小区、单位或街区里的小型图书室。这类场景的实际问题很典型借书还书靠手写登记书被谁借走、什么时候该还没人说得清。想借的书不知道有没有副本只能跑一趟现场看。到了还书时间经常忘记逾期了也没人提醒。热门图书想预约缺少一个排队机制。这些痛点不需要复杂建模靠小程序端的信息展示加后端服务就能解决但数据关系又能覆盖用户、图书、馆藏副本、借阅记录、预约信息、公告这么多维度足够把 SQL 设计和接口设计做出层次感。同时它的业务逻辑不是纯增删改查。借书、还书、续借、预约之间有状态流转有超时判断有并发冲突——这些天然适合做成状态机 接口校验的设计展示你的逻辑能力。对比一下其他常见选题选题方向工作量答辩风险通用后台管理系统偏低容易被人说是换皮 CRUD网上商城偏高支付、库存、订单太复杂容易做不完内容资讯类 App中功能容易做成浏览器套壳社区图书馆小程序中业务完整痛点明确技术栈可深可浅1.2 把业务边界画清楚是后面所有设计的前提我帮人规划这个项目时第一步不是画架构图而是先砍需求。核心功能只保留五个模块读者注册、登录、个人信息维护。图书检索、分类浏览、图书详情与副本状态查看。借书、还书、续借、预约。超期提醒与借阅记录查看。管理员端图书上架、下架、录入副本、查看借阅数据。砍掉的功能包括在线支付、积分商城、押金管理、自动扣费、社交分享。不是说这些功能没用而是它们会迅速把项目拖入不归路。边界清楚之后你会发现整个系统的数据流非常干净用户在小程序里看到一本书查副本状态能借就提交借阅管理员在管理端维护图书系统在后台算逾期。所有功能都能在一个演示流程里串起来这对毕设来说比堆功能重要得多。2. 技术栈复盘Spring Cloud 撑后端JavaScript 撑小程序前端技术选型是答辩时被问得最多的地方也是很多同学最心虚的地方。这个项目标题直接给出了一个组合后端 Spring Cloud前端 JavaScript。这个组合不是随便定的它恰好能在一个项目里同时展示微服务架构能力和移动端应用开发能力。2.1 微服务方向的毕设选 Spring Cloud 的理由与风险先讲为什么选 Spring Cloud 而不是单体 Spring Boot。单体 Boot 当然能把图书馆管理系统做完代码量还可能更少。但毕设考察的不只是能不能跑还包括你有没有架构抽象能力。Spring Cloud 允许你在一套代码里把这些问题都展示出来服务如何注册、如何被发现。API 网关怎么统一入口、怎么做鉴权。服务之间通过 Feign 调用负载均衡如何生效。配置中心管理多个服务的公共配置。熔断降级、超时控制怎么保护整个链路。一句话总结Spring Cloud 给了你足够的架构故事去讲。但风险也很明显微服务不是免费的注册中心要跑、网关要跑、网关到业务服务要多一跳、联调时问题排查链路变长。所以我建议在项目里做轻量化微服务而不是把每个服务拆得碎成几十个点。具体来说服务数量控制在 3 个业务服务加 1 个网关、1 个注册中心。只引入必要的 Spring Cloud 组件服务注册发现、OpenFeign、Gateway。配置中心可以引入但不用搞动态刷新那些花活。熔断组件至少要配置一个默认规则并在答辩时能说清楚触发的场景。如果连这五个都驾驭不了那选微服务方向就是给自己挖坑。2.2 前端为什么只靠 JavaScript 的小程序工程就够现在说一下标题里的基于 JavaScript。很多第一次接触小程序的同学会疑惑不写 Java、也不写其他语言前端到底用什么小程序前端本质上就是一套 JavaScript 运行时环境页面结构、样式、逻辑分别对应模板、样式表、脚本文件。你在小程序里写的所有交互逻辑——点击按钮、请求接口、处理返回数据、控制页面跳转——都是 JavaScript含 ES6 语法。所以基于 JavaScript不是额外加的一个技术点而是小程序开发的默认形态。这个项目里前端的定位非常明确只承担展示和交互不碰业务规则。例如借书按钮在小程序端可以判断当前是否有 token但这本书还能不能借必须由后端来判断。续借按钮在小程序端判断续借次数是否小于上限但是否逾期、是否已经被预约在后端判断。所有状态的最终裁定权都在后端服务里小程序端只是把用户意图翻译成 HTTP 请求。这个分工可以在答辩时明确说出来前端保证交互体验后端保证数据正确性。 一句话就能体现出你对前后端职责边界的理解。2.3 版本与中间件组合尽量让别人复现时不卡壳毕设项目最怕什么最怕演示前一天环境起不来。这里给出一套我实测比较稳的组合。后端基础版本JDK 8 或 11推荐 JDK 8兼容性最好。Spring Boot 2.7 系列。Spring Cloud 2021.0.x 系列。注册中心Nacos 单机模式。数据库MySQL 8.x。缓存Redis 6.x如果觉得环境负担重可以把 Redis 设计为可选组件实际项目里只用于验证码存储和 JWT 黑名单。这里特别提醒Spring Boot 和 Spring Cloud 的版本是绑定的不能随意选最新版。网上搜到的新版本可能让你在导入依赖时直接崩溃。选版本时记住一个原则——先查官方版本对应关系再动手创建工程。中间件的坑也不少。本地开发时Nacos、MySQL、Redis 全开笔记本内存不够会卡到怀疑人生。后面联调部分我会专门讲怎么省内存。3. 后端拆成几个服务内部怎么协作服务拆分是微服务设计的灵魂也是答辩时最能体现水平的地方。拆得太多流水账拆得太少被质疑假微服务。社区图书馆这个业务规模拆三个业务服务是刚刚好的。3.1 服务划分表注册中心、网关与三个业务服务整个后端系统由五部分组成我习惯把这五部分分成基础设施和业务服务两层。基础设施层组件职责registry注册中心服务注册与发现健康检查gatewayAPI 网关统一入口、路由转发、JWT 校验、基础限流业务服务层服务名核心职责关键接口示例member-service读者/管理员账号、登录发令牌、个人信息/auth/login、/member/infobook-service图书书目、分类、馆藏副本、副本状态/book/list、/book/copiesborrow-service借书、还书、续借、预约、逾期计算/borrow/create、/borrow/return、/borrow/renew为什么要把借阅独立成一个服务因为借阅是这个系统里业务规则最重的一块。它不仅要操作借阅记录表还要协调副本状态、处理预约队列、计算逾期天数。把这块单独拆出来职责边界就清楚了。member-service 和 book-service 相对稳定borrow-service 是变化中心。这正好符合微服务拆分里常说的围绕业务能力组织服务。3.2 核心表结构与借阅状态流转设计数据库这里我不给完整建表语句重点看字段设计和状态流转。核心表五张表名关键字段说明memberid, openid, nickname, phone, rolerole 区分 reader/adminbook_infoid, isbn, title, author, category, cover_url书目元信息同一本书多个副本共享book_copyid, book_id, copy_no, status每本实体书一条status 是关键borrow_recordid, copy_id, member_id, borrowed_at, due_at, returned_at, status借阅流水reservationid, book_id, member_id, status, created_at预约排队副本状态设计是整个系统的核心。一本书在架上有 3 本实体副本每本副本都有自己的状态AVAILABLE可借。BORROWED已借出。RESERVED已被预约锁定不能借。OFF_SHELF下架或破损。借阅记录状态相对简单BORROWED借出中。RETURNED已归还。RENEWED续借后仍是借出中但到期时间延后。OVERDUE逾期未还这是从 BORROWED 派生出来的状态可以通过 due_at 实时计算不一定需要额外字段。这里有个设计心得逾期状态不建议做成定时任务天天扫描更新而是查询时实时计算。每次查看我的借阅时如果 due_at 小于当前时间且 status 为 BORROWED就临时标记为逾期。只有真正还书时才把记录落库为 RETURNED。这么做的原因是逾期是一个读多写少的状态实时计算成本极低而且不会出现定时任务漏跑导致状态不更新。3.3 一次借书请求到底经过哪些环节借书是核心链路也是唯一一个需要跨服务写操作的场景这里必须把协作过程讲清楚。借书请求的完整路径小程序点击借书带 token 请求 gateway。gateway 校验 token解析出用户 ID路由转发到 borrow-service。borrow-service 拿到请求后先调 member-service 确认用户状态正常。borrow-service 再调 book-service请求预占对应副本。book-service 先把副本状态置为 RESERVED 或 BORROWED防止并发下被其他人借走。预占成功后borrow-service 写入一条 borrow_record状态为 BORROWED并计算 due_at默认借期 30 天。如果第 6 步写库失败borrow-service 要反过来调 book-service 释放副本状态。可以看到这里有跨服务调用就有分布式一致性的问题。毕设阶段最务实的做法是用一个简单的补偿机制而不是引入 Seata 或消息队列中间件。具体来说borrow-service 里维护一个借阅创建状态字段先预占副本。再写借阅记录。如果写借阅记录成功返回成功。如果写借阅记录失败调 book-service 把副本状态回滚为 AVAILABLE然后返回失败提示。这个过程在答辩时要主动承认我这里用的是补偿式的最终一致性没有用分布式事务中间件因为当前业务量下这个方案最简单且可靠。你越是这样坦诚地讲清楚取舍评委越认可。相反如果在毕设里强行用一套分布式事务框架反而容易被追问到细节而答不上来。4. 小程序端 JavaScript 的实现重点小程序端页面不多但每一页都有值得抠的实现细节。前端这块最容易出现的错误是把后端该做的事拿到前端做了导致数据错误。下面按功能模块拆开讲。4.1 页面骨架与数据驱动小程序页面建议规划六块首页展示公告、热门图书、分类入口。检索页按书名、作者、分类组合筛选图书。图书详情页展示书目信息、副本状态列表、借/预约按钮。我的借阅页当前借阅列表、续借入口、历史记录。预约列表页预约中的图书及排队状态。管理端图书录入、副本管理、借阅审核、超期列表。前端数据流是单向的页面加载时调用接口取数据存到 data 里模板再通过数据绑定渲染。所有按钮的点击事件都走同一个模式先更新 UI按钮 loading→ 发请求 → 成功后刷新数据 → 失败弹提示。这里最容易被忽视的是请求失败的兜底。很多同学只处理成功回调接口报错时页面一直转圈。我建议每个请求封装里都保证无论成功失败都关闭 loading并统一处理 401、500 等状态码。4.2 登录态这一步决定后面所有请求是否能通过网关登录态是整套系统的命门。社区图书馆小程序的普通用户登录流程是小程序端调用平台提供的登录能力换取临时凭证。把临时凭证发给后端 member-service。member-service 拿着凭证去平台换取用户的唯一标识这里可理解为 openid。如果该 openid 没注册过自动创建账号。member-service 签发 JWT 返回给前端。前端把 token 存到本地缓存。后续每个请求在 header 里带上Authorization: Bearer token。网关的 JWT 校验是所有请求的第一道关卡。我在代码里做的是一个全局过滤器伪代码如下Component public class JwtAuthFilter implements GlobalFilter { Override public MonoVoid filter(ServerWebExchange exchange, GatewayFilterChain chain) { ListString auth exchange.getRequest().getHeaders().get(Authorization); if (auth null || auth.isEmpty()) { exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED); return exchange.getResponse().setComplete(); } String token auth.get(0).replace(Bearer , ); Claims claims JwtUtil.parseToken(token); // 解析失败会抛异常 ServerWebExchange mutated exchange.mutate() .request(builder - builder.header(X-User-Id, claims.get(userId).toString())) .build(); return chain.filter(mutated); } }注意这里有个细节网关校验完 token 之后把用户 ID 放在一个新的请求头X-User-Id里向下游传递。业务服务不需要再去解析 JWT直接信任网关照传过来的用户标识。这就是认证在网关、授权在业务的经典分层。前端封装请求时所有接口统一走同一个 request 方法function request(path, method, data) { const token getStorageSync(token); return new Promise((resolve, reject) { request({ url: baseUrl path, method: method, data: data, header: { Authorization: Bearer token }, success: res resolve(res.data), fail: err reject(err) }); }); }这行 header 设置就是之前反复踩坑的地方我后面会讲完整排错过程。4.3 借阅流程的状态判断与竞态规避图书详情页的借阅按钮不能做成永远可点。正确逻辑是遍历该书的副本列表找一个状态为 AVAILABLE 的副本。有可借副本按钮显示借阅。没有可借副本但有预约名额按钮显示预约。既不能借也不能预约按钮置灰。这是前端的第一层校验。真正的并发控制在后端的预占逻辑上。比如两个用户同时点击借阅唯一副本前端都查到了 AVAILABLE但后端 book-service 在扣减时要保证原子性。我这里的做法是用 SQL 条件更新UPDATE book_copy SET status BORROWED WHERE id #{copyId} AND status AVAILABLE如果影响行数为 0说明副本已经被别人抢先借走后端就返回手慢了。这个方案不用加分布式锁对毕设规模完全够用。续借逻辑同样有前置条件只有当前借阅状态是 BORROWED、未逾期且续借次数小于 2 的情况下才能续借。前端和后端都要校验一遍以后端为准。5. 联调时踩的坑和完整排查链路毕业设计最耗时间的往往不是写功能而是联调排错。下面这个 401 问题我印象很深它把网关、token、前端请求封装、系统时间全串起来了。5.1 现象小程序登录成功业务接口一律 401当时现象是这样的登录接口能通也能拿到 token 和用户信息。但只要一调其他业务接口比如查图书列表、查我的借阅网关就返回 HTTP 401小程序端统一弹未登录。我当时第一反应是前端没带 token。检查小程序的 request 封装发现确实没把 token 写进 header。因为登录接口不需要 token能通而其他接口没带 token直接被网关拦截。这是最常见的第一层原因。修复方式就是前面说的统一 request 封装所有请求都自动带上Authorization。5.2 从网关日志一路查到时间基准问题加上 header 之后再测还是一排 401。这次网关日志里出现了JWT expired的错误。查 token 的签发时间和当前时间发现 token 签发时 iat 是当前时间减 8 小时。原因是我本地系统时间和容器环境的时区不一致签发 JWT 时用了默认时区校验时又用另一个时区导致系统认为这个 token 是未来签发的或者已过期。解决办法有两个层面代码层面在 JWT 工具类里强制指定时区。环境层面统一开发环境的系统时区。毕设项目里我建议两个都做。JWT 校验本身还涉及时钟偏移问题生产环境里可以配置允许几秒的偏差本地调试时如果能校准系统时间问题就少一半。5.3 服务间调用令牌丢失Feign 拦截器补上网关校验通过后请求到达 borrow-service但 borrow-service 去调 book-service 时发现下游又报 401。原因是 Feign 在服务间调用时不会自动传递当前请求的 header。网关传给 borrow-service 的X-User-Id和Authorization不会自动出现在 Feign 请求里。这时候需要给 Feign 配一个请求拦截器把上游请求上下文里的 token 透传下去Bean public RequestInterceptor userTokenInterceptor() { return requestTemplate - { RequestAttributes attrs RequestContextHolder.getRequestAttributes(); if (attrs instanceof ServletRequestAttributes servletRequestAttributes) { String token servletRequestAttributes.getRequest().getHeader(Authorization); requestTemplate.header(Authorization, token); } }; }这行代码是服务间调用链路的最后一公里。很多毕设项目单体调试没问题一到微服务联调就挂往往就是这里没处理。排错思路整理成一条线看网关日志确认请求有没有到网关。网关提示缺 header → 检查前端 request 封装。网关提示 token 无效或过期 → 检查时区、时钟偏移。网关通过但业务服务日志报错 → 检查 Feign 是否透传 header。5.4 本地资源不够时微服务怎么缩着跑本地起整套微服务对电脑是很大考验。注册中心、网关、三个业务服务每个 Java 进程默认堆内存就可能占几百 MB再加 MySQL、Redis、小程序开发工具8G 内存的机器直接卡死。我的建议是JVM 启动参数统一加-Xmx256m -Xms128m防止内存溢出。不用的服务先关闭只保留演示链路必需的服务。注册中心用单机模式不要开集群。公告之类的低优先服务做成可选模块演示时再启动。Redis 如果只是用来做验证码本地可以暂时用内存缓存代替减少一个中间件进程。这样处理之后最精简模式下只需要跑注册中心、网关、member-service、borrow-service、book-service 加 MySQL刚刚好。6. 演示脚本与答辩问答怎么准备代码写完不算完演示环节能把效果拉满答辩环节能接住问题这个毕设才算稳。6.1 演示动线从一个异常提示开始讲故事我推荐一条演示动线它不是把功能一个个点过去而是用一个故事把功能串起来。故事线读者小王想看一本书打开小程序检索发现热门书籍已被借完他点击预约排队前面有人归还后系统通知他轮到他来取书并确认借阅两周后他手机收到即将到期的提醒他选择续借一次最后如期归还。演示时每一步都要切到后端日志或注册中心界面让评委看到这个请求实际经过网关和服务调用。比如借书那一刻你可以切到注册中心控制台显示 book-service 和 borrow-service 的实例状态再切到网关日志看到一条路由记录然后展示数据库里 borrow_record 多了一条记录、book_copy 状态从 AVAILABLE 变成了 BORROWED。这条动线把前端体验、后端服务、数据变化三层都覆盖了比单纯点按钮要有说服力得多。6.2 容易被追问的技术点与应对话术答辩提问基本绕不开下面几个问题我整理了一套应对思路。常见提问建议回答方向单体 Spring Boot 也能实现为什么要用 Spring Cloud毕设重点在于展示服务治理、网关、服务间通信能力同时业务边界清晰拆分有依据服务与服务之间怎么通信基于 OpenFeign 的声明式 HTTP 调用配合注册中心做服务发现与负载均衡某个服务挂了怎么办注册中心会摘除实例调用方通过熔断和降级保护主链路本地演示可模拟下线借书过程跨服务写库数据不一致怎么办用预占副本加补偿回滚的方式实现最终一致性并解释为什么不引入分布式事务中间件为什么不给数据分库分表当前数据量级单库完全够用微服务体现在逻辑边界划分物理存储按需演进前端为什么要用 JavaScript 写小程序运行时原生支持 JavaScript不需要额外框架核心交互逻辑全部由 JS 承担回答问题的核心原则是不回避取舍主动讲清楚你做了哪些权衡。很多人答辩被问倒不是因为项目不行而是因为每个选择都说是大家都用所以我也用。能说出当前场景下我选择它是因为什么代价更低这才是评委想听到的内容。我自己的体会是毕设项目的价值不完全取决于技术有多新而在于所有的技术选择都经得起追问。这个题目里 Spring Cloud 给了你足够多的架构素材JavaScript 小程序让系统有了真实的移动端体验业务上又有借阅状态流转这种适合深挖的点。把借书这条链路的每个环节都吃透演示时每一步都能对应到某个服务正在做什么答辩就不会心虚。如果你正在准备类似的毕设我最真诚的建议是先把这个项目的服务拆分和状态流转画在纸上再打开 IDE 写代码。中途遇到问题不要急着改代码先想是哪一层的问题——前端交互、网关校验、服务逻辑还是数据状态。掌握了这套排查思路比多写几百行代码更有价值。