1. 从选题到落地如何把“宠物商城”做成能过审的SpringBoot毕设每年毕业季计算机专业的同学都会卡在同一道坎上题目选得太简单答辩时评委几句就问穿题目选得太复杂又怕自己写不完。我在带毕设的这几年里发现“宠物用品商城”这类电商系统恰恰是性价比最高的选题之一——它够生活化、业务链路完整、技术上能覆盖后端开发的核心考点又不像“秒杀系统”“推荐系统”那样容易给自己挖坑。一个“萌宠在线”宠物商城系统本质上要回答三个问题谁在买、卖什么、怎么交易。拆开来看就是前台用户注册登录、浏览商品、加购物车、下单支付后台管理员管理商品分类、库存、订单状态。这套链路放进SpringBoot里几乎每一环都能找到对应的成熟组件Spring Security管登录、MyBatis Plus操作数据库、Redis扛热点数据、支付宝沙箱模拟支付。更重要的是这套系统的难点不在“做出来”而在“把它讲清楚”——答辩时你能说出为什么用Redis缓存商品列表、为什么订单表要单独拆出来、为什么秒杀场景下库存要加锁这比交付一个能跑的Demo值钱得多。我个人最推荐的选择是基于SpringBoot 2.7.x MyBatis Plus Vue 3前后端分离的方案。为什么等一下展开说。先给还在纠结题目的同学一颗定心丸宠物用品商城这个方向既有电商系统的通用性又有“宠物”这个垂直领域带来的差异化展示空间。你可以在论文里写“针对宠物用品消费频次高、品类杂、囤货需求强的特点”也可以在系统里加“宠物档案”这种小功能来体现你的设计思考——同样的架构比做“图书商城”“服装商城”更容易让评委看出你动了脑筋。2. 整体设计与技术选型思路2.1 为什么是SpringBoot而非SSH或SSM问十个用过SpringBoot的人九个会说“省事”但省在哪、凭什么省得说清楚。SSHSpring Struts2 Hibernate那个年代光配置文件就能写几百行XML里互相引用让人头皮发麻。SSMSpring SpringMVC MyBatis好一些但引入依赖、整合配置仍需手动处理。SpringBoot最核心的贡献是约定优于配置它内置了Tomcat起步依赖帮你把常用库的版本全部对齐application.yml里写几个关键参数就能跑起一个Web服务。对于时间和精力都有限的毕设场景这意味着你可以把省下来的时间花在业务代码上而不是和Maven依赖对版本。SpringBoot也不是没有“坑”比如它默认的spring-boot-starter-parent锁死了依赖版本你想用更高版本的MyBatis Plus时可能会碰到冲突——这个在后面的问题排查章节我会专门讲。但总的来说选SpringBoot做毕设是当前环境下最稳妥、资料最多、遇到问题最容易搜到答案的选择。2.2 技术栈选型与各层职责划分我的推荐选型如下每一层都做了明确的职责划分层级技术选型核心职责选型理由前端Vue 3 Element Plus Axios页面渲染、交互、请求发送前后端分离趋势、组件库成熟、学习曲线平缓后端框架SpringBoot 2.7.x接口层、业务编排、事务控制社区资料最多、生态稳定、兼容性最好持久层MyBatis Plus单表CRUD、条件构造器、分页省去大量XML编写、API友好、易上手数据库MySQL 8.x数据持久化存储学院环境最普及、面试常考、备份迁移方便缓存Redis商品热点数据、验证码、购物车缓存非关系型数据库考点、电商场景标配鉴权JWT Spring Security登录态管理、接口访问控制无状态鉴权、前后端分离的主流方案文件存储本地存储 / 七牛云OSS商品图片、头像上传毕设场景不推荐上MinIO/分布式文件系统太重看到这里你可能会问不就是个毕设吗搞这么多技术栈会不会贪多嚼不烂我的回答是——关键在于你怎么界定边界。上面的技术栈里Redis和Spring Security属于“你有能力写但不写也完全不影响核心功能”的部分。我见过太多人一开始全都要结果项目写到一半卡在Redis集群配置上最后草草交差。如果你时间紧张我建议这样取舍基础版只做SpringBoot MyBatis Plus MySQL把增删改查和订单流程写扎实进阶版再加Redis缓存商品和JWT登录完整版才考虑Spring Security、支付宝沙箱、OSS存储。先保证核心链条能跑通再谈锦上添花。2.3 数据库设计的核心要点数据库设计决定了整个项目的上限。宠物商城再怎么包装核心逃不开这几张表用户表userid、username、passwordBCrypt加密存储、nickname、avatar、phone、create_time商品分类表categoryid、name、parent_id支持二级分类、sort_order商品表productid、category_id、name、subtitle副标题、main_image、detail、price、stock、sales、status购物车表cartid、user_id、product_id、quantity、checked是否选中订单表orderid、order_no订单编号、user_id、total_price、status、pay_time、create_time订单明细表order_itemid、order_id、product_id、product_name、product_image、current_unit_price、quantity、total_price收货地址表shippingid、user_id、receiver_name、receiver_phone、province、city、district、detail_address这里有两个必须讲清楚的设计决策第一为什么订单和订单明细要拆成两张表因为一个订单可能包含多个商品而每个商品在购买时刻的价格、快照信息需要独立记录。如果你只存一张订单表用户买了一个狗粮和一支梳子你就得把商品列表塞进某个字段里——查询、统计、售后全都难受。拆表后order表记录一次交易的总金额和状态order_item表记录每一件商品的独立快照。第二为什么订单明细里要冗余product_name、product_image因为商品信息是可变的管理员修改商品名称、价格后历史订单里的相关记录不应该跟着变。冗余字段本质上是一份“交易快照”这是电商系统的通行做法。3. 核心功能模块的实操落地3.1 用户注册登录从MD5到BCrypt的进化用户模块是每个系统的门面。有些同学图省事存密码时直接MD5(userInput)一把梭这在校园项目里很常见但放在答辩现场容易被追问“MD5有什么漏洞”。正确的做法是使用BCryptPasswordEncoder它对同一密码加盐后每次生成的哈希值都不一样即使数据库泄露也很难通过彩虹表反推出原密码。Spring Security集成BCrypt极其简单Bean public BCryptPasswordEncoder passwordEncoder() { return new BCryptPasswordEncoder(); }注册时加密user.setPassword(passwordEncoder.encode(user.getPassword()));登录时校验boolean matches passwordEncoder.matches(rawPassword, encodedPassword);关于注册登录还有一个容易被忽视的细节用户名唯一性校验要放在数据库层面而不是只靠代码判断。我见过太多项目在UserService里先queryByUsername()再决定能不能注册这在高并发下会出现两个同名用户同时注册成功的情况。正确做法是在user表给username加唯一索引代码里捕获DuplicateKeyException并转成友好提示。3.2 商品列表与详情分页查询和Redis缓存商品列表页是用户浏览最多的页面也是缓存收益最明显的地方。如果每个用户打开首页都直接打MySQL数据库压力很大用Redis把热门分类的商品列表缓存起来逻辑简单且效果直观。第一步用MyBatis Plus的分页插件分页查询。需要先配置一个MybatisPlusInterceptor注册PaginationInnerInterceptorConfiguration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }第二步在Service层加缓存逻辑。这里分享一个**“先查缓存、查不到回源DB、再回填缓存”**的套路public PageProduct listProducts(Integer categoryId, Integer pageNum, Integer pageSize) { String cacheKey product:list: categoryId : pageNum : pageSize; Object cached redisTemplate.opsForValue().get(cacheKey); if (cached ! null) { // 反序列化返回 return JSON.parseObject(cached.toString(), Page.class); } PageProduct page new Page(pageNum, pageSize); LambdaQueryWrapperProduct wrapper new LambdaQueryWrapper(); wrapper.eq(categoryId ! null, Product::getCategoryId, categoryId) .eq(Product::getStatus, 1) .orderByDesc(Product::getSales); productMapper.selectPage(page, wrapper); // 写回缓存设置5分钟过期 redisTemplate.opsForValue().set(cacheKey, JSON.toJSONString(page), 5, TimeUnit.MINUTES); return page; }这段代码里藏着两个坑我当年都踩过。一是JSON序列化Page对象时records里的泛型信息会丢失反序列化后拿到的List元素是JSONObject类型转换直接报错。解决办法是手动构造对象或者用Jackson的TypeReference。二是缓存删除时机管理员后台修改商品价格或库存后必须同步删除相关缓存键否则前端看到的是脏数据。最粗暴但有效的做法是在商品更新的Service方法里redisTemplate.delete(keys)删掉全量商品缓存键。3.3 购物车合并登录态与Redis存储方案购物车模块有两种实现思路。简单版是存在前端LocalStorage用户没登录也能往购物车里加正规版是后端存储基于用户ID关联。毕设项目建议做后端版因为能展示你对状态管理的理解也为后续“下单”流程提供数据基础。后端版购物车最优雅的存储介质其实是Redis用Hash结构key为cart:userIdfield为productIdvalue为数量// 加入购物车 stringRedisTemplate.opsForHash().increment(cartKey, productId.toString(), quantity); // 查询购物车 MapObject, Object entries stringRedisTemplate.opsForHash().entries(cartKey); // 修改数量 stringRedisTemplate.opsForHash().put(cartKey, productId.toString(), newQuantity); // 删除条目 stringRedisTemplate.opsForHash().delete(cartKey, productId.toString());选择Redis做购物车的原因很好理解购物车是高频操作用户每加减一件商品都要读写用Redis能扛住更高的并发。但Redis的缺点是数据易失——服务重启后购物车就空了。所以在下单结算时一定要把Redis里的购物车数据同步写入MySQL的cart表或生成订单后清空以此保证数据可靠性。兜底方案是全程用MySQL的cart表加user_id和product_id的唯一索引。这种方案在毕设答辩中更容易解释清楚事务和关联查询也完全够用。我的建议是如果你对Redis操作熟练就用Redis如果没把握就全用MySQL不要弄一个“混合双打”的复杂结构。3.4 下单流程事务、库存扣减和订单号生成从购物车生成订单是整系统里最能体现功力的环节。一个完整的下单流程包括校验登录态 - 读取购物车中勾选的商品 - 校验商品是否存在且上架 - 计算总价 - 扣减库存 - 生成订单主记录 - 生成订单明细 - 清空购物车。这个流程中任何一步失败都不应该留下半截脏数据所以整个流程必须包在事务里。SpringBoot里用Transactional注解即可但有几个细节必须注意第一库存扣减要使用乐观锁。简单写法是UPDATE product SET stock stock - #{quantity} WHERE id #{productId} AND stock #{quantity}通过stock quantity这个条件让扣减操作要么成功、要么因为库存不足影响行数为0。检查影响行数如果为0说明超卖。这一点是答辨析时的高频考点值得跟“为什么不用先查询再扣减”做对比讲清楚先查再扣会存在并发间隙两个请求同时读到stock1各自扣1库存就变成了-1。第二订单号生成不要用数据库自增ID也不要用时间戳随机数并发容易碰撞。推荐使用“时间戳 用户ID后四位 随机四位”的方式或者引入雪花算法。时间戳加随机数的写法如下String orderNo String.format(%s%s%04d, new SimpleDateFormat(yyyyMMddHHmmss).format(new Date()), userId % 10000, ThreadLocalRandom.current().nextInt(1000));第三事务方法调本类方法会失效。这是Spring AOP的经典问题——Transactional是通过代理对象生效的如果外部类直接调用this.createOrder()绕过了代理事务就不会开启。要么两个方法不在同一个类里要么用AopContext.currentProxy()要么把事务注释加到Controller调用的那个Service方法上。3.5 管理员后台商品管理与订单状态流转后台管理模块核心是对商品和订单的状态管理。商品上下架、库存修改、分类调整各做一个页面订单方面需要支持查看订单列表、按状态筛选、发货操作。订单状态流转建议用状态机的思维去设计不要允许任意跳转。一般电商订单在毕设中简化为待付款10→ 已付款/待发货20→ 已发货30→ 已完成40待付款10→ 已取消0已付款20→ 申请退款后 → 退款成功-1可选后端要做的是在每次状态变更的Service方法里校验前置状态if (!20.equals(order.getStatus())) { throw new BusinessException(当前订单状态不允许发货); } order.setStatus(30);这个逻辑看着简单但能帮你挡住“把已取消的订单发货”这类低级漏洞在答辩演示时也能讲出一个“完整业务闭环”的故事。3.6 文件上传图片上传功能的避坑指南宠物用品商城的商品图、评价图、用户头像都需要上传能力。很多同学在这里想上OSS或者MinIO但如果你没有云服务器本地存储反而是最务实的选择。核心实现是在配置里指定上传目录通过MultipartFile接收入参把文件保存到本地并返回可访问的URLPostMapping(/upload) public Result upload(RequestParam(file) MultipartFile file) { if (file.isEmpty()) { return Result.error(文件不能为空); } String originalFilename file.getOriginalFilename(); String ext originalFilename.substring(originalFilename.lastIndexOf(.)); // 校验扩展名只允许jpg/png/gif if (!Arrays.asList(.jpg, .jpeg, .png, .gif).contains(ext.toLowerCase())) { return Result.error(图片格式不支持); } String fileName UUID.randomUUID().toString().replace(-, ) ext; File dest new File(uploadDir File.separator fileName); if (!dest.getParentFile().exists()) { dest.getParentFile().mkdirs(); } file.transferTo(dest); String url /images/ fileName; return Result.success(url); }这里有个必须注意的坑上传目录和项目源码目录不要混在一起。如果你把图片直接存到src/main/resources/static下每次重新打包上传的图片就全没了。推荐在application.yml中配置一个绝对路径的upload.dir同时加一个本地资源映射规则让/images/**能访问到磁盘上的文件。upload: dir: D:/pet-shop-upload spring: mvc: static-path-pattern: /** resources: static-locations: classpath:/static/, file:${upload.dir}/3.7 JWT登录鉴权无状态方案的最简落地前后端分离项目里传统Session方案没那么方便同源部署还好跨域下要处理Cookie和CSRF问题十分麻烦。JWT方案是更贴合当前主流实践的选型。JWT的实现本质上需要三步第一步登录成功后签发Token把用户ID和角色放进去String token Jwts.builder() .setSubject(user.getId().toString()) .claim(role, user.getRole()) .setExpiration(new Date(System.currentTimeMillis() 7 * 24 * 3600 * 1000)) .signWith(secretKey, SignatureAlgorithm.HS256) .compact();第二步写一个拦截器或过滤器解析Header里的Authorization字段校验Token把用户信息存到ThreadLocal或Request Attribute供后续接口使用。第三步写一个注解如RequireLogin或AdminOnly标记在需要登录的Controller方法上。拦截器里通过反射读取注解并校验权限。关于JWT有几个常见追问毕设答辩前务必准备JWT过期时间设多久合理答案是7天到30天太短影响体验太长不安全服务端能不能主动踢掉一个用户答案是不能无状态需要引入黑名单机制把Token加入Redis黑名单直到自然过期。把这两个问题讲清楚面试官对你的评价会提高一截。4. 项目结构优化与部署问题4.1 后端分层为什么要用Controller-Service-Mapper三层有些同学图省事把业务逻辑全写进Controller一个接口几百行代码看着很“痛快”但后续维护和答辩评讲都会很痛苦。标准的三层架构是Controller层只做参数接收、参数校验、调用Service、返回统一结果不写任何业务逻辑。Service层业务核心处理事务、编排数据。Mapper层DAO层数据访问MyBatis Plus的BaseMapper接口提供通用方法。分包命名可以这样组织com.example.petshop ├── controller │ ├── UserController.java │ ├── ProductController.java │ ├── OrderController.java │ └── AdminController.java ├── service │ ├── UserService.java │ ├── ProductService.java │ ├── OrderService.java │ └── CartService.java ├── mapper │ ├── UserMapper.java │ ├── ProductMapper.java │ └── OrderMapper.java ├── entity │ ├── User.java │ ├── Product.java │ └── Order.java ├── common │ ├── Result.java │ ├── BusinessException.java │ └── GlobalExceptionHandler.java └── config ├── MybatisPlusConfig.java ├── RedisConfig.java └── WebMvcConfig.java我见过太多毕设项目是一个包下塞几十个类命名也随意Test.java、Utils.java这种结构即使功能全对天生就掉了档次。加上统一的Result返回类和GlobalExceptionHandler能让你的代码容错能力瞬间提升——前端无论拿到的数据是什么形态都能通过code字段判断成功与否而不是各种try-catch散落在 controller 里。4.2 SpringBoot的自动装配原理答辩必备知识点用SpringBoot这么久如果被问“自动装配到底怎么回事”就卡壳那就太浪费这个框架了。简单讲自动装配的入口是SpringBootApplication里包含的EnableAutoConfiguration注解。这个注解通过AutoConfigurationImportSelector读取META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件旧版本是spring.factories里声明的所有自动配置类再按条件装配注解ConditionalOnClass、ConditionalOnMissingBean逐一判断是否生效。举一个我们项目里的实际例子SpringBoot自带的RedisAutoConfiguration就是检测到RedisOperations类在classpath中才会生效DataSourceAutoConfiguration则检测到DataSource.class以及JDBC相关的类。所以你在pom.xml里加什么依赖SpringBoot就知道你要做什么再通过配置项和默认值帮你把Bean组装好。把这段逻辑讲清楚比死记硬背“SpringBoot简化了SSM的开发”有价值得多。顺带一提之前网上传的“把SpringBoot的jar反编译成项目”也是基于这一点——jar里不仅有编译后的class还带有自动配置的元信息反编译能把嵌套的依赖关系理出来但业务代码可不会自己跑出来。4.3 打包与部署从jar到能跑在服务器上在最终打包前先梳理一条命令链路。本地开发时用mvn spring-boot:run或IDE直接跑不再多说生成可部署的文件需要执行mvn clean package这就是之前一个热搜问到的“SpringBoot jar包反编译”的那个jar。打包前务必确认三件事application.yml中的数据库账号密码、Redis地址是否正确前端构建后的dist目录文件是否已复制到后端src/main/resources/static下如果做的是前后端一体部署本地调试用的测试数据是否已准备好。服务器部署的方式有很多种最贴合毕设的是简单粗暴的java -jar方式nohup java -jar pet-shop-1.0.0.jar --spring.profiles.activeprod app.log 21 日志输出到app.log后排查问题时用tail -f app.log查看。如果项目里使用了外部上传目录记住在服务器上创建对应目录否则文件上传接口会报“系统找不到指定的路径”。如果想让项目“更专业一点”可以再用Docker把MySQL、Redis、后端应用编排起来写一个docker-compose.yml让评委看到你的工程化思维。但不建议毕设阶段上K8s之类的重型工具因为有复杂度却没有相应的收益。4.4 如何应对“SpringBoot版本太高”的问题SpringBoot 3.x发布之后一堆跟着较新教程写的同学踩了坑。问题集中在三块javax改为jakarta——老代码的import javax.servlet.*全部报错得改成jakarta.servlet.*Spring Security的配置方式大幅变更很多基于WebSecurityConfigurerAdapter的旧教程在3.x中已作废仅剩基于SecurityFilterChain的写法一些第三方starter比如早期版本的MyBatis Plus还不支持SpringBoot 3.x需要升级到对应新版本。避坑的方法是毕设项目老老实实用SpringBoot 2.7.x。它的社区资料最多、兼容性最稳、各种组件的坑早被填平了。如果你学校的毕业要求里写了“必须用新版”那就要做好多花一周时间适配所有依赖版本的心理准备。这个选择问题属于典型的“用2.x的旧版还是3.x的新版”的权衡我在下面的问题章节还会再展开一次。5. 常见问题与排查技巧实录5.1 问题排查速查表现象可能原因排查思路与解决方案启动报Failed to configure a DataSource未配置数据库连接检查application.yml中spring.datasource.url/username/password与MySQL是否正常启动访问接口报404Controller扫描路径不对确认启动类位置在包的根路径确保能扫描到所有controller集成Spring Security后所有接口都无法访问未放行登录注册接口在SecurityConfig中permitAll登录、注册、商品浏览等公开接口前端访问后端接口跨域未配置CORS写一个WebMvcConfigureraddCorsMappings里设置allowedOriginPatterns(*)上传图片后刷新页面打不开静态资源映射未配置检查file:路径是否正确、物理路径是否真实存在Redis连接失败Redis服务未启动/地址配置错误本地先redis-cli ping返回PONG说明正常用MyBatis Plus查不到数据实体类字段映射有问题检查TableName、TableId、TableField与表结构是否匹配开启SQL日志打印前端传JSON后端接收为null请求头未指定Content-Type: application/json确认Axios的POST请求设置了正确content-type后端用RequestBody而非RequestParam分页查询total总是0分页插件未注册确认MybatisPlusInterceptor里的PaginationInnerInterceptor已配置打包后运行jar图片功能失效上传目录相对路径问题使用绝对路径存储不依赖jar运行时的当前工作目录事务不生效数据部分成功同类调用或方法未被代理把要加事务的逻辑分离出去或通过代理调用确保Transactional加在public方法上修改数据库表结构后代码报错实体类与表结构不一致用MyBatis Plus的代码生成器重新生成实体避免手写字段名出错5.2 围绕毕设答辩的三个高频追问追问一为什么订单表不用自增ID作为主键数据库自增ID会暴露订单数量且多表合并、迁移时容易冲突。订单号order_no是业务编号跟主键分离主键用自增id或雪花id作为内部标识对外暴露的永远是订单号。分布式场景下自增ID依赖数据库自身的递增机制难以扩容。所以即便毕设规模不大也要养成“业务编号与主键ID分离”的习惯。追问二登录状态如何避免Token被篡改JWT的过程是签名保证的。Token中载荷的Base64部分如果被改最后的签名就校验不过。密钥放在后端配置里不要放到前端代码或Git仓库中。若担心Token被窃取XSS攻击从localStorage读取Token可从两个方面缓解设置较短的过期时间、将Token保存在HttpOnly的Cookie中降低被脚本读取的风险。追问三项目里如何保证数据一致性分块回答关系型数据库的数据用Transactional管事务Redis缓存和MySQL的数据通过“先更新数据库再删缓存”来避免不一致如果存在跨库或复杂的事务需求超出毕设范围引入消息队列做最终一致性但当前不需要。回答时先讲清事务级别默认可重复读再讲缓存一致性的取舍兼顾细节和全局已经是很好的现场表现。5.3 高版本依赖冲突的复现与解决用SpringBoot 2.7.x时大家都比较省心。但如果你装的是3.0以上版本同时引用了老版本MyBatis Plus比如3.5.3.1之前的版本启动时会直接抛ClassNotFoundException: javax.servlet.Filter之类的异常。这也是网上“SpringBoot版本太高”类问题最多的来源。解决依赖冲突的基本思路是依赖树排查。在项目根目录执行mvn dependency:tree -Dverbose查看哪个依赖引了旧包、哪些版本产生了冲突。大多数情况下新的SpringBoot 3.x项目需要mybatis-plus-spring-boot3-starter而不是旧版starter。在pom里排除冲突依赖也是常用操作比如dependency groupIdcom.baomidou/groupId artifactIdmybatis-plus-boot-starter/artifactId version3.5.3.1/version exclusions exclusion groupIdorg.mybatis/groupId artifactIdmybatis-spring/artifactId /exclusion /exclusions /dependency排查原则说直白一点先固定SpringBoot版本再选配套的Starter版本最后看Maven的冲突报告。别一开始就追最新版本那不是技术的胜利是运维的灾难。6. 从“做完”到“做好”内容规划扩展与个人经验项目能跑通只能说明你完成了编码工作。但从“能跑”到“答辩稳过”中间还差几步打磨。第一给项目一个能自圆其说的业务故事。别上来就说“我做了一个宠物商城”。换成“针对宠物主人在主粮、零食、玩具、医疗用品上的复购需求设计了一个商品分类清晰、订单流程完整、后台可管理的宠物用品交易平台”听感立马不同。你的需求分析、功能设计、数据库规划都应该围绕这个故事展开。第二提前准备演示数据和演示脚本。我见过太多同学答辩时现场注册账号、现场添加商品结果验证码输入半天或者图片上传失败场面非常被动。更晚一点建议准备三五个演示账号一个普通用户购物车里已有商品、一个管理员后台数据齐全。演示时只需要点击几下来展示核心链路而不是从零开始造数据。第三README文档要写得像个开源项目。包括项目介绍、技术栈、快速启动步骤、默认账号、测试数据说明。这个文档在导师和评委那里很加分它代表你有交付意识。再进一步画一张简单的系统架构图和流程图用Visio或draw.io就行放进论文里技术分能上一个档次。第四关于宠物档案、秒杀、优惠券这些扩展功能要懂得“演示时点到为止”。如果时间允许叠加一个“宠物档案”模块或“优惠券”模块会显得你有思考深度但如果核心链路还没跑稳就加功能反而容易拖垮整体质量。功能是1花边是01立不住后面的0都没有意义。我在实际带项目的过程中发现最容易拉开差距的不是代码本身而是对待毕设的态度。有些人把毕设当成一个“应付差事”数据库表结构随便建代码能跑就算交差有些人则把毕设当成一个“微型项目”来经营从表结构设计到异常处理每一层都认真对待。最后答辩的成绩、导师的评价、甚至求职时拿出来的作品集差别是非常明显的。如果你正在为选题抓狂不用再纠结“宠物商城是不是太简单”——简单不简单不取决于题目取决于你把什么讲出来、把什么做扎实。用SpringBoot把这条电商链路走通你学到的不仅仅是一个框架而是从需求分析到设计建模、从编码实现到部署排错的全流程经验。这套经验放到任何一个Java岗位上都能复用得上。最后再分享一个实实在在的小技巧开发过程中每天都把遇到的问题和解决方案记录在项目根目录的DEVELOPMENT_LOG.md里。答辩前翻一遍这个日志你会发现自己的成长路径非常清晰——这个东西在任何总结润色过程中都无法编造出来。做毕设不是为别人交差是为自己沉淀。这比任何API调用都重要。