SpringBoot做校园餐厅评价系统这个选题说实话在毕设里属于“看起来平平无奇、做起来大有文章”的类型。很多同学一听到“点评系统”就觉得是CRUD堆功能结果做完才发现要么太单薄答辩没东西讲要么业务逻辑一团乱线代码改都改不动。我前前后后帮人复现和改造过几个类似的食堂评价平台这里直接把拆解思路、技术选型和踩坑实录一次性讲透希望能帮你把这个项目做出真正的区分度。1. 项目概述与场景解构1.1 这个系统到底要解决什么问题高校食堂一直有个尴尬的局面学生想吃合口的饭菜只能靠同学口口相传食堂档口想知道自己哪道菜受欢迎只能靠卖得好不好猜学校后勤想要提升餐饮服务质量又缺乏量化的评价数据。这三方其实是互相有需求的但缺少一个能沉淀评价数据的平台。这个项目就是来补这个缺口的。学生登录后可以按餐厅、按菜品维度去打分和写评语同时能看到其他人的推荐食堂管理者可以查看自己档口的评分趋势和热门菜品系统管理员负责审核内容、管理用户和统计数据。一句话概括用SpringBoot做后端接口层承载用户、餐厅、菜品、评论、点赞、收藏、通知等核心业务模块配合前端页面形成完整的评价闭环。1.2 适合谁做、能学到什么如果你处于这几个状态这个项目会非常合适有Java SE基础、正在学SpringBoot但缺一个能写进简历的完整项目准备考研复试需要展示工程能力但不想做大而全的电商或管理系统找工作想证明自己会用主流技术栈做实际业务而不是只会写增删改查对前后端交互、RESTful接口设计、数据库建模等工程化实践有兴趣。做完这个项目你得到的核心能力有三块第一真正理解SpringBoot的自动装配、起步依赖、配置文件绑定这些机制在实际项目中是怎么运作的第二掌握一套从建表到接口开发到联调到部署的完整流程这种节奏感比单个技术点的掌握重要得多第三能说出每个表为什么这么设计、接口为什么这么划分这在答辩时是实打实的加分项。2. 技术选型与架构设计思路2.1 为什么核心框架选SpringBoot而不是SSH或SSM老牌的SSH和SSM不是不能用但想用它们把项目搭起来光环境配置就能耗掉一周。SpringBoot最大的价值在于它把“约定大于配置”落到了实处。起步依赖直接拉取整套兼容的依赖版本比如引入spring-boot-starter-web就自动带上了Spring MVC、内嵌Tomcat和Jackson引入spring-boot-starter-data-jpa或mybatis相关启动器就免去了手写SqlSessionFactory等一堆配置。我特别建议你打开项目的pom.xml去挨个看依赖这对面试“SpringBoot框架”相关提问非常管用。比如spring-boot-starter-test里为什么自带JUnit 5和Mockitospring-boot-maven-plugin插件打包时做了什么都是高频考点。2.2 完整技术栈选型清单层次选型思考过程后端核心框架SpringBoot 2.7.x选择2.x而不是3.x是因为绝大多数毕设和教学资料都基于2.x遇到问题能找到的解决方案多而且对JDK版本要求更友好持久层MyBatis-Plus自定义SQL满足报表统计类查询同时内置BaseMapper和LambdaQueryWrapper把简单的CRUD代码量砍掉一大半数据库MySQL 5.7 / 8.0数据规模小表结构清晰事务和索引机制成熟稳定前端Vue 2 / 3 Element UI按你熟悉程度选择如果时间紧可以直接用Vue 2 Element UI资料最全权限控制Spring Security JWT登录认证和接口鉴权一套搞定JWT无状态设计天然适配前后端分离缓存Redis用于存储验证码、热门餐厅排行榜、在线用户状态避免每次请求都打数据库接口文档Knife4j / Swagger自动生成可调试的API文档联调和答辩演示都方便部署Docker Nginx展示工程化意识用Docker镜像打包后端Nginx反向代理前端静态资源这里要解释一下权限控制这个选型。很多学生为了贪图方便直接用拦截器判断session里有没有用户但Spring Security JWT这套组合的含金量更高。JWT本身是一个经过签名的JSON字符串服务端不用保存会话状态用户在登录后将token放在请求头里后端通过过滤器解析验证天然适合前后端分离和多终端复用。虽然学习曲线陡一点但搞明白它的过滤器链结构和认证流程面试时能讲的东西就非常多了。2.3 项目目录结构与分层思路我推荐采用标准的分层架构虽然看起来比controller-service-mapper三层多了一点东西但职责边界清晰后续加功能不会牵一发动全身src/main/java/com/campus/canteen ├── common // 通用工具类、统一返回结果、全局异常处理 ├── config // 配置类JWT过滤器、Redis配置、CORS跨域配置 ├── controller // 接口层只负责接收参数和返回结果 ├── service // 业务层编写业务逻辑和事务控制 ├── mapper // 数据访问层放MyBatis-Plus的Mapper接口和自定义SQL ├── entity // 实体类与数据库表字段一一对应 ├── dto // 数据传输对象比如登录请求、评价提交参数的封装 ├── vo // 视图对象返回到前端展现层的数据结构 └── utils // JWT生成解析、文件存储等工具方法有人可能会觉得entity和dto重复建类很麻烦但在实际开发中数据库表字段一定会比前端需要的数据多比如用户表里有密码字段返回用户信息时绝不能把它带出去。用dto和vo来隔离既安全又灵活。3. 数据库设计评价系统的核心地基3.1 数据表整体规划数据库设计在这个项目里决定了一半的成败。我见过很多版本的表结构要么五张表走天下要么设计冗余字段搞得更新的时候各种不一致。这里给出一套我验证过的完整方案包含10张核心表用户表(user)id、username、password(BCrypt加密存储)、nickname、avatar、role(0学生/1食堂管理员/2系统管理员)、status、create_time餐厅表(canteen)id、name、location、description、image、avg_rating、rating_count、status、create_time菜品表(dish)id、canteen_id、name、image、price、description、monthly_sales、status评价表(comment)id、user_id、canteen_id、dish_id、rating(1-5分)、content、images、anonymous(是否匿名)、like_count、create_time回复表(reply)id、comment_id、user_id、content、reply_to_user_id、create_time点赞表(like_record)id、user_id、comment_id、create_time收藏表(favorite)id、user_id、dish_id、create_time通知表(notification)id、user_id、type、content、is_read、create_time管理员操作日志表(admin_log)id、admin_id、action、target_type、target_id、detail、create_time举报表(report)id、user_id、comment_id、reason、status、handle_result、create_time尤其要注意的是餐厅表和菜品表里的冗余统计字段(avg_rating、rating_count、monthly_sales)。很多人第一反应是这些数据实时算不就行了但实际查询会遇到性能瓶颈用户看菜品列表时需要按评分排序每次排序都去评价表里做聚合计算数据量上来后会非常慢。折中的方案是列表展示读冗余字段评论变更时更新统计字段单个菜品的详细评分分布再实时查。这就是典型的“用空间换时间”也是工程里常用的手段。3.2 主外键关系用什么方式处理设计表关联时有两个派系数据库层面加物理外键约束或者只在应用层维护逻辑外键。在毕设阶段我推荐逻辑外键为主可以适当加物理外键。逻辑外键的意思是comment表里有canteen_id和dish_id字段但不做数据库级的FOREIGN KEY约束。优点很明显方便做分布式改造的迁移、删除数据时更灵活、测试数据构造更简单。缺点是有可能产生孤儿数据但如果应用层用事务控制好问题不大。这里还要强调一下删除策略。用户删除了一个评论但其他用户可能已经点过赞或者管理员处理过举报物理删除会导致一系列连锁问题。推荐的做法是加一个deleted字段做逻辑删除查询时默认过滤掉已删除的数据MyBatis-Plus的TableLogic注解就能实现自动帮你拼上where deleted 0这个条件。3.3 索引设计不能随便建数据库表结构定了还不够索引设计同样重要。评价表里查询频率最高的场景是“查看某个餐厅或某个菜品下的评价列表”所以canteen_id, create_time和dish_id, create_time这两个联合索引必须建。点赞表要防重复插入所以user_id, comment_id建立唯一索引。用户表登录时按username查询该字段上也要加唯一索引。这些你都应该能在答辩时说清楚不要笼统说“建了索引”要说出最左前缀原则和覆盖索引这些概念。比如联合索引canteen_id, create_time它能同时支撑按canteen_id的等值查询和按canteen_idcreate_time的范围排序这就是索引设计中的“一箭双雕”。我见过太多人把每个字段都单独建索引结果MySQL优化器反而不知道选哪个好还白白占空间。4. 核心功能模块的完整实现4.1 用户认证模块从JWT签发到接口放行这个模块是所有功能的基础实现逻辑值得拆开揉碎讲清楚。用户输入账号密码提交到后端流程是这样的先调用userService根据username查用户然后用BCryptPasswordEncoder的matches方法比对密码哈希值比对通过后生成JWT把用户id和角色塞进token的claims里。JWT生成后返回给前端前端存到localStorage里每次请求在Authorization头里带上。后端这边要写一个OncePerRequestFilter继承Spring的过滤器基类在过滤逻辑里取请求头里的token并校验签名解析出的用户信息放进ThreadLocal或SecurityContext里这样后续的Controller和Service就能随时拿到当前登录用户是谁。在这套基础之上还需要配置哪些接口是公开的哪些必须登录哪些只有管理员才能访问。以食堂管理员身份为例他想删除一条差评请求到达Controller之前JWT过滤器已经解析出他的角色是ROLE_CANTEEN_ADMIN然后Spring Security的授权管理器会根据注解PreAuthorize(hasRole(CANTEEN_ADMIN))来决定放行还是返回403。把权限规则和业务代码解耦这是工程化程度的一个体现。注意不要把JWT的secret明文写在代码里应放到application.yml配置文件中并用ConfigurationProperties或Value注入。更保险的做法是secret长度至少32字节否则HS256算法的签名强度会打折扣。4.2 评价提交与多条件组合打分评价模块是业务核心具体来说要处理这几个逻辑用户提交评价时包含canteen_id、dish_id、rating、content、images等字段后端先判断用户是否已经评价过同一菜品30天内防止刷屏评分范围校验rating必须为1到5的整数content长度不能超过500字高分非好评绑定问题这里需要一个巧妙的设计用户在打分之后需要选择“推荐菜品”才能提交成功这就保证了评价不只是评分而是有具体内容的保存评论后同步更新canteen表和dish表的rating_count和avg_rating字段如果是匿名评价返回数据时user_id显示为nullnickname显示为“匿名用户”。其中同步更新冗余字段这一步千万不能漏我见过很多项目评论发了但排名不更新就是因为漏了这一步。再讲一个容易被忽视的设计评分与文本解耦。也就是说评价表并不需要在主表上既存评分又存长文本。如果需要更复杂的评价维度比如口味、价格、环境三个维度分开打分可以在主表存总体评分再加一张评价详情表存各子维度的分数。不过毕设阶段5分制整数评分已经够用了追求复杂维度反而会让前端交互变重、数据质量变差。4.3 图片上传本地存储与动静分离图片上传也是常见的功能点。毕设阶段我强烈建议用本地磁盘存储外加Nginx映射静态访问路径先别碰云存储服务省去各种配置成本。具体做法是在application.yml中配置一个upload.path比如/data/canteen/images/用户上传时通过MultipartFile的transferTo方法把文件写到该目录下文件名用UUID重命名防止重复。然后定义一个WebMvcConfigurer把虚拟路径和磁盘路径做映射这样图片URL就能像访问静态资源一样直接展示。这里有几件重要的细节上传前校验文件类型不能只校验后缀名还要校验文件的MIME类型防止有人传个WebShell上去限制单个文件大小在SpringBoot的配置文件里设置spring.servlet.multipart.max-file-size: 5MB和max-request-size: 10MB图片压缩可以不做但图片体积限制必须做否则服务器磁盘容易被塞爆删除评论时不能只删数据库记录磁盘上的图片也要清理否则积累一年就是几十GB垃圾。4.4 个性化推荐基于标签的简化协同过滤如果你想在这个项目里做出亮点强烈建议加一个**“猜你喜欢”**的推荐模块。别一听推荐就觉得要搞深度学习光一个Spark或TensorFlow就够你喝一壶的而且毕设的场景下数据量根本喂不饱模型。实用做法是基于标签的推荐。菜品表加一个tags字段存“麻辣”“清淡”“招牌”这类标签。用户每次评价菜品时系统自动把他的偏好向量加上该菜品的标签权重。推荐时先找和当前用户偏好最相似的Top N用户群再从这些用户高频正向评价的菜品中选当前用户没吃过的进行推荐。逻辑不算复杂但能讲出基于物品的协同过滤思想同时核心代码自己可控、答辩能讲清楚。如果觉得这个复杂度还是高可以退一步做“热门排行好友动态”的简化版通过Redis的ZSet数据结构维护点赞榜和评论活跃榜数据更新和排名查询都非常高效。4.5 通知系统从主动查询到事件驱动当有人回复你的评论或者你关注的档口出了新品系统需要给用户发通知。比较完善的实现有两个层次基础层次是查询时生成。用户拉取通知时查回复表找到“目标评论id属于该用户”的回复数据再加上菜品上新等信息动态组装。这种方式实现简单数据永远是最新的但每次拉取都要做几表关联。进阶层次是事件驱动写入。用户A回复了用户B的评论业务代码在事务里同时写一条notification记录通知类型为REPLY内容摘要为回复正文。用户拉取通知时直接查notification表已读标记更新即可。这样拉取接口很简单查询也快而且天然支持后续扩展站内信、邮件提醒等场景。我在你的需求里看到“校园美食互动评价系统”互动才是精髓。通知模块不只是锦上添花它是让用户感受到“被回应”的关键设计强烈建议保留。5. 项目启动与联调从IDEA到前端页面5.1 用IDEA创建和配置SpringBoot项目全流程很多新手在刚开始时卡在项目创建这一步这里把整个流程过一遍。用IDEA最新版新建项目时选择Spring Initializr在Spring Boot版本那里选2.7.x。如果你本地JDK是8或11不要手贱去选3.x版本因为3.x要求JDK 17起步选错版本后面全是妖魔问题。这也是你在热搜词里看到“springboot版本太高”这种烦心事的原因版本不匹配是很多新手第一道大坎。依赖选择的时候勾上Web、MySQL Driver、MyBatis-Plus Framework如果你用的是个人版IDEA可以用Maven方式引入依赖、Lombok、Spring Security、Redis、Validation。注意MyBatis-Plus不在IDEA的初始依赖列表里需要在pom.xml手动加坐标。然后是配置文件。检查application.yml里的数据源和Redis连接、JWT密钥和过期时间、文件上传路径、MyBatis-Plus的日志打印和逻辑删除配置。以一个典型的本地配置为例server: port: 8080 spring: datasource: url: jdbc:mysql://localhost:3306/canteen_db?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai username: root password: 123456 driver-class-name: com.mysql.cj.jdbc.Driver redis: host: localhost port: 6379 database: 0 servlet: multipart: max-file-size: 5MB max-request-size: 10MB mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl map-underscore-to-camel-case: true global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0 jwt: secret: your-32-character-secret-key-please-change expire: 604800这里有个细节map-underscore-to-camel-case字段映射必须开启不然数据库的create_time映射不到Java实体类的createTime接口查出来全是null排查非常费时间。5.2 前端联调时最容易翻车的几个点前端联调是很多后端同学头疼的地方这里分享几个典型的坑和解决思路。首先是跨域问题。前端跑在8081端口后端在8080端口属于跨域请求。解决方法有两种后端在配置类里实现WebMvcConfigurer的addCorsMappings方法配置允许跨域或者前端通过Vite/Nginx的代理转发。我推荐前端配置代理这样生产环境Nginx做反向代理时前端请求地址不用改后端同时也配好CORS方便本地调试。两层都配上不会冲突。其次是接口返回格式要统一。建议所有接口都返回一个统一的Result对象格式为{code: 200, message: success, data: {...}}。这样前端可以做统一的响应拦截不用每个请求都单独判断成功失败。我见过接口有的返回对象、有的返回List、有的直接返回null前端处理起来非常痛苦。第三是日期格式问题。后端返回的LocalDateTime默认序列化格式是2025-01-15T10:30:00前端直接显示会很难看。解决方式是在application.yml里加配置spring: jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT85.3 用Postman/Apifox做完整接口自测接口写完不要直接丢给前端自己先用Apifox或Postman完整跑一遍流程。近两年我更推荐Apifox因为它内置了Mock数据和接口文档管理一个平台搞定调试和协作。自测流程要覆盖业务闭环注册用户、登录拿token用token创建一条餐厅评价带图片上传用另一用户账号对这条评价点赞验证餐厅评分是否从无到有发生变化管理员登录对敏感评论做隐藏再拉取评论列表确认已经看不到被隐藏的评论。这套流程走通后大部分接口的问题都能暴露出来。实测下来最常触发Bug的是“评论后更新餐厅平均分”这步很多人只更新了菜品表忘了餐厅表或者事务没有生效导致分数更新了但评价记录没插入成功。建议update方法上加Transactional注解并在测试时故意制造一次插入失败看看事务是否真的回滚。6. 数据可视化与后台管理别让PPT式图表糊弄事6.1 餐厅评分趋势与热力图分析毕设里数据可视化是非常出彩的一部分。热门关键词里出现了“基于springboot vue的前后端分离”架子搭好之后可视化就能直接体现数据的价值。比较推荐做三个维度的可视化餐厅评分雷达图对一个餐厅的评分做多维度拆分比如口味、环境、服务、价格四个维度做成五维雷达图用户能直观看出这家食堂的优势短板。评分时间趋势折线图按周或月聚合用户对特定餐厅的评分均值看趋势变化。食堂管理方可以通过趋势图感知到“这道菜最近评分下滑”及时调整菜品配方或更换档口。热门菜品词云清洗菜品评价文本用HanLP或Jieba做分词统计高频词和情感倾向词生成词云图。比如“微辣”“入味”“太油”这些高频关键词比单纯看分数更能反映真实口碑。后端为可视化提供数据时SQL聚合查询是基本功。以月度评分趋势为例SQL大概长这样SELECT DATE_FORMAT(create_time, %Y-%m) AS month, AVG(rating) AS avg_rating, COUNT(*) AS comment_count FROM comment WHERE canteen_id #{canteenId} AND deleted 0 GROUP BY DATE_FORMAT(create_time, %Y-%m) ORDER BY month ASC;类似这种SQL要能随口说出设计思路MyBatis-Plus的QueryWrapper搞不定复杂聚合在Mapper里写XML简单清晰还能走索引。6.2 管理员后台的权限边界设计后台管理分三类角色权限边界必须清晰系统管理员用户管理封号、重置密码、餐厅与菜品审核、评论内容审核与置顶、数据统计总览食堂管理员只能管理自己所在餐厅的菜品信息、查看本餐厅的评价、对恶意差评提起申诉由系统管理员处理普通学生用户没有后台访问权限。在Spring Security配置里不同的URL前缀绑定不同的角色要求即可。比如/api/admin/**需要ROLE_ADMIN/api/canteen/**需要ROLE_CANTEEN_ADMIN。尤其注意水平权限问题食堂管理员A不能通过手动改URL里的餐厅ID去操作食堂B的数据。在service层做数据归属校验查询时强制加上WHERE canteen_id 当前管理员的餐厅ID不能只依赖前端把餐厅ID传进来。7. 性能优化与安全加固进阶加分的实操项目7.1 Redis缓存在评价系统中的落地用法缓存的位置选得好效果立竿见影热门餐厅排行榜用Redis的ZSetkey为canteen:rankmember为餐厅IDscore为综合热度分评价数点赞数加权每小时定时任务重算一次。榜单加载约消耗个位数毫秒远比实时查数据库聚合快。菜品详情缓存菜品基础信息变化频率低、读取频率高适合缓存。用Spring Cache的Cacheable注解放在getDishDetail方法上CacheManager配置为Rediskey为菜品的JSON序列化结果TTL设为30分钟。验证码存储登录或注册时的图形/短信验证码存Redis5分钟过期天然带过期特性。一个关键注意点是缓存穿透和缓存击穿。菜品的id是自增整数恶意请求一个不存在的ID会每次穿透到数据库。解决方案是在接口层对请求参数做基础校验查不到数据的缓存空值并设置较短TTL。此外热点餐厅的缓存突然过期会导致一瞬间大量请求打到数据库加入互斥锁或逻辑过期时间去保护。7.2 接口安全防刷、鉴权、参数校验三层防线一个在线公开的系统最容易受到的是自动脚本攻击。三步防线必不可少第一层接口限流。发评论或点赞接口加上简单限流用Redis的incr命令实现计数器一分钟内同一用户最多评论5次、点赞20次超出返回“操作太频繁”。这种小成本设计能把大量恶意刷屏挡在业务逻辑之外。也可以用AOP自定义注解RateLimiter对整个Controller类一对一生效。第二层JWT鉴权与Token续期。JWT过期时间设置为7天是一次性的用户7天后必须重新登录。为了让体验更顺滑可以采用双Token方案accessToken 30分钟过期refreshToken 7天有效期accessToken过期后用refreshToken去换新的。答辩时提到这个设计面试官眼中你的工程经验值会直接拉满。第三层参数校验与XSS防护。Spring Validation框架的NotBlank、Size、Min、Max在Controller入参上做好校验避免脏数据进入数据库。文本内容做HTML标签过滤防止存储型XSS。简单做法是引入一个自定义的XssFilter对请求体中的script等危险标签进行转义和清除。7.3 日志记录与异常处理机制日志这个环节被很多学生直接跳过但它是线上排查问题的生命线。用Slf4j在关键Service类打info和warn日志内容包括请求用户ID、操作参数、耗时和异常栈。配合Spring Boot的全局异常处理器RestControllerAdvice按异常类型返回不同的错误信息格式参数校验异常返回400级错误码和具体字段错误业务异常返回自定义CodeMsg未捕获异常统一返回500并对日志做error级别记录避免把异常堆栈直接抛给前端。注意日志里绝不能打印用户的明文密码、身份证号等敏感信息。真实开发中因为日志泄露密码的事故比想象中的多得多。8. 常见问题与避坑指南8.1 高频报错的排查路径问题1启动时报Failed to configure a DataSource原因多半是数据源没有配置或者连接失败。先检查application.yml里url、用户名、密码是否正确再确认MySQL服务是否启动、数据库是否已创建。如果是连接成功、但找不到数据库执行CREATE DATABASE canteen_db DEFAULT CHARACTER SET utf8mb4;问题2MyBatis-Plus分页不生效检查是否配置了分页插件。MyBatis-Plus新版需要手动添加MybatisPlusInterceptor并把PaginationInnerInterceptor作为内置拦截器注册进去否则Page参数会被当成普通参数处理查询不报错但全表数据都返回了。问题3JWT过滤器对所有请求生效导致登录接口无法访问把登录注册接口的URL加入过滤器的白名单。在SecurityConfig的permitAll()里配好白名单JWT过滤器也要有对应的路径断言。顺带提醒白名单的路径匹配规则要和Controller里写的路径完全一致别一个写/api/auth/login一个写/api/login这种小坑能卡一整晚。问题4前端上传图片显示404优先确认Nginx或后端的虚拟路径映射是否指向了正确的磁盘目录再查看文件是否真的被上传到目标位置。命令行里ls -al /data/canteen/images/检查一下文件是否存在、权限是否正常。真实开发很大比例是目录没有写权限导致的。8.2 答辩时会被告知的几个加分细节做毕设时系统能跑只是及格线能讲清楚每个模块为什么这么做才是高分关键。这里列几个我指导论文时反复强调的点数据库表设计里冗余统计字段的选择比一张大宽表一次性算到底更有说服力评价既要“数值量化”也要“文本洞察”评分和NLP关键词提取结合让数据真正有分析价值JWT无状态认证为什么适合前后端分离对应会带来什么问题和补偿措施自定义异常体系的设计而不只是用try-catch出来一个假结果抛给前端并发场景下的超卖问题比如同一道菜同时被大量用户点赞、同一用户重复点赞它们分别用的什么手段唯一索引、Redis计数、事务隔离级别来控制。8.3 时间规划建议八周开发节奏最后给一个制订开发计划的时间参考这个节奏我试过能顺利完成第1周跑通项目骨架完成数据库建表搞定登录注册和JWT认证第2周完成餐厅、菜品模块和用户中心头像上传、资料编辑第3-4周评价模块完整闭环包括多条件评分、图片上传、匿名、点赞、回复和通知第5周管理后台和可视化图表第6周Redis缓存、接口限流、安全加固XSS、权限校验第7周联调、修复接口问题、整理数据库脚本和启动文档第8周压测、性能调优、准备答辩PPT和数据备份。这个节奏不算紧但也不宽裕重点是把两三周的战略时间留给评价模块和可视化这两块是答辩时最容易出彩的地方。别一上来就埋头写代码先把建表SQL和接口文档定下来否则后面改起来全是重复劳动。这个项目做下来最大的感受是SpringBoot只是一个载体真正值钱的是你如何把业务需求转化为表结构、接口设计和技术方案的能力。校园餐厅评价系统虽然看起来不大但用户端、商家端、管理端三类角色、评价闭环、通知互动、数据可视化、安全风控全都要覆盖做完之后你对一个完整项目从0到1的理解会上一个台阶。如果时间允许建议在系统里真实录入一个月的数据哪怕自己写脚本模拟有真实数据支撑的可视化和推荐模块才是答辩时最有说服力的部分。