每年选题季计算机类毕设清单里几乎都少不了“基于Java的手机销售网站”“基于SpringBoot的智能手机在线商城”这种题目。它经久不衰不是因为新颖而是因为从用户登录、商品展示到下单支付完整覆盖了Java后端开发最常见的业务闭环非常适合用来检验一个学生能不能把SpringBoot、数据库、前端这些东西真正串起来。我前前后后带过不少做这类题目的学生也自己从零搭过一套移动终端设备销售与展示平台这篇文章就围绕这个题目的完整研发过程展开从选题分析、技术选型、数据库设计到核心业务实现、坑点排查、答辩部署都整理成可以直接复用的经验。想把这个题目做成“优秀毕设”的同学可以去对照着查漏补缺。1. 这个题目为什么年年热门它到底在考察什么1.1 一个商城题目里藏着多少技能点很多人觉得“手机销售网站”就是个增删改查拿来做毕设有点水。这是对题目的误解。同样是商城有的人只做出“能跑”有的人能在答辩时把事务、缓存、安全、并发逐层讲清楚分数的差距就在这里。这个题目至少覆盖了Java开发者日常使用频率最高的几类能力SpringBoot项目搭建与配置、ORM框架的使用与多表查询、MySQL表设计与索引优化、前端页面整合、登录鉴权、文件上传、事务管理。如果再把项目做到可以部署还能涵盖打包、Linux命令、Nginx反向代理、数据库初始化脚本这些正是公司招初级后端开发时最看重的动手能力。所以不要小看这个题目它本质上是把你大学四年的Java知识做了一个“最小完整闭环”。1.2 从需求层面拆解题目的真正范围一个“智能手机在线商城”不是只做商品列表那么简单。我把需求拆成三块来说。前台用户端注册登录、首页轮播、分类浏览、商品搜索分页、商品详情、加入购物车、提交订单、模拟支付、查看订单、修改个人资料。这是用户能直接看到的部分也是工作量最大的地方。后台管理端管理员登录、商品分类管理、品牌管理、商品上下架、库存维护、订单查询与发货、用户管理、轮播图管理。后台部分最能体现工程规范因为每个管理操作都涉及表单校验、权限校验和操作逻辑。非功能性需求密码不能明文存储接口要防XSS注入下单时要保证库存和订单数据一致商品图片要能正常展示项目要能在干净环境里部署运行。很多毕设“页面做得挺好”却在非功能需求上丢分后面我会专门讲这些坑。1.3 时间分配建议如果从零开始我给学生的建议是四周成型第一周搭项目骨架和数据库第二周做用户模块与商品展示第三周做购物车、订单、支付闭环第四周做后台管理并留出余量处理bug和准备演示。不要上来就想着做秒杀、优惠券、分销这些花活儿先把主链路跑通有余力再往里面加亮点这是做毕设最不容易翻车的顺序。2. 技术选型取舍SpringBoot之外的配套怎么搭2.1 后端组件用最小代价搭可靠的基础设施主体用SpringBoot这个没得选题目本身已经定义了。问题在于版本、ORM、缓存、鉴权这些配套怎么取舍。我的建议如下。SpringBoot版本选2.7.x而不是3.x。原因很实际3.x要求JDK 17而不少学校机房和答辩环境还停在JDK 8另外网上能搜到的资料、学长学姐留下的代码绝大多数基于2.7之前的版本遇到坑时排查成本低。经验法则毕设项目不要追最新版本要追最容易查到解决方案的版本。持久层用MyBatis-Plus这也是开发者搜索热词里频繁出现的框架。它最大的价值不是少写那几行CRUD而是提供了单表操作的基础封装和分页插件让你可以把精力集中在订单、统计这些复杂SQL上。这里多说一句用了MyBatis-Plus不代表可以不写SQL商品多条件搜索、订单分组统计这种场景下直接写xml里的SQL反而更清晰两者配合才合理。缓存可以用Redis但不要盲目上。我在项目中主要用缓存存轮播图和商品分类这类变化少、读取频率高的数据。商品列表不建议做过期时间很短的缓存很容易出现缓存和数据库不一致反而给答辩提问埋雷。登录鉴权用JWT配合一个简单的HandlerInterceptor拦截器而不是直接上Spring Security。不是说Spring Security不好而是它概念庞杂初学者很难讲清楚过滤链、认证管理器这些细节一旦被追问就容易露馅。用JWT加拦截器代码虽然写得多一点但每一行自己都清楚在干什么。2.2 前端方案Thymeleaf还是前后端分离两种路线我都见过。时间紧张或者前端基础一般的用服务端渲染Thymeleaf加Bootstrap页面直接放在resources/templates下省去跨域和接口联调的成本项目也能完整。想做前后端分离的用Vue加Element UI做管理后台用户端可以用Vue或简单H5页面这时候后端只需要提供RESTful接口再用一个CORS配置解决跨域。我的判断是如果学校答辩允许现场打开项目跑起来看前后端分离会更有“工程感”毕竟SpringBoot加Vue前后端分离几乎是目前主流项目的标配但如果只剩两周时间老老实实用Thymeleaf别因为前端把后端节奏拖垮。这里没有标准答案核心是选择自己能在答辩时讲得清楚的技术栈。2.3 开发环境的版本细节环境上建议统一为JDK 8、MySQL 5.7或8.0、Maven 3.6以上。最容易忽略的是数据库的字符集和排序规则建库时一定要选utf8mb4否则商品介绍里一旦出现生僻字或者特殊符号页面就可能显示乱码这种问题在答辩前出现会非常影响状态。另外数据库连接串里加上serverTimezoneAsia/Shanghai能避免日期时间在插入和查询时来回差8小时的莫名其妙问题。这两处都是不动脑子就能避开的坑但每年都有人踩。3. 数据库设计十几张表怎么建模才经得起答辩追问3.1 核心主表用户、分类、品牌、商品数据库是整个项目的地基表格设计好不好答辩老师一扫就能看出来。我逐个说一下核心表的字段思路。用户表usersid、username、password、nickname、phone、avatar、created_time、updated_time。password字段存的是BCrypt生成的哈希值不是明文。username加唯一索引登录时快速定位。商品分类表categoryid、name、parent_id、sort_order、status。如果只做一级分类parent_id不填就行但保留这个字段说明你有扩展多级分类的意识这是个小亮点。手机这个品类通常会往下按“品牌”维度分所以我单独建了品牌表brandid、name、logo、description。品牌和商品是一对多关系商品表里保存brand_id。商品表product的字段我会这样设计CREATE TABLE product ( id BIGINT PRIMARY KEY AUTO_INCREMENT, brand_id BIGINT NOT NULL, category_id BIGINT NOT NULL, name VARCHAR(100) NOT NULL, subtitle VARCHAR(255), main_image VARCHAR(255), detail_images TEXT, price DECIMAL(10,2) NOT NULL, original_price DECIMAL(10,2), stock INT NOT NULL DEFAULT 0, sales INT NOT NULL DEFAULT 0, status TINYINT NOT NULL DEFAULT 1 COMMENT 1上架 0下架, deleted TINYINT NOT NULL DEFAULT 0, created_time DATETIME, updated_time DATETIME, KEY idx_brand (brand_id), KEY idx_category (category_id) );价格一律用decimal(10,2)千万不要用double金额用浮点类型存迟早会出精度问题答辩被老师点到会很尴尬。商品删除用逻辑删除deleted字段而不是物理删除理由很简单商品一旦被订单引用物理删除会把历史订单展示搞乱逻辑删除才能保证订单列表里的商品信息可追溯。3.2 交易链路购物车、订单、订单明细购物车表cartid、user_id、product_id、quantity、checked、created_time。有些系统把购物车直接放Redis但毕设建议还是入库表结构更直观逻辑也更好讲如果用了Redis一定要能解释清楚为什么用Redis、数据丢失怎么办这类问题。订单表和订单明细表是交易链路的核心。订单表ordersid、order_no、user_id、total_amount、status、pay_type、pay_time、receiver_address、receiver_name、receiver_phone、remark、created_time、updated_time。订单明细表order_itemsid、order_id、product_id、product_name、product_image、price、quantity、total_price。这里有个非常关键的建模意识订单明细里不但要存product_id还要冗余保存下单那一刻的商品名称、图片和价格。原因很简单商品价格和名称以后可能改如果订单只存商品ID将来商品改名或改价历史订单显示就跟现状走了。这就是业务上的“快照”概念。能把这一点说出来评委基本能确认你不是照着网上代码瞎复制。订单状态字段用int定义好枚举值0待付款、1待发货、2待收货、3已完成、4已取消。不要把中文状态直接写进数据库字符串容易乱也不方便程序判断。支付类型同理用int存枚举值展示层再映射成文字。3.3 辅助表、索引与外键策略辅助表包括收货地址表address、评论表comment、轮播图表banner、管理员表admin。地址表和用户是一对多评论表关联商品和用户轮播图就是一个图片地址加排序字段后台管理时可增删改。外键这个问题值得多说一点。学生时代特别喜欢在表上建物理外键但企业级项目里通常不用物理外键而是靠应用层维护逻辑外键因为物理外键会带来插入顺序约束、分库分表困难、性能损耗。做毕设时不用完全模仿企业但至少不要被问到时说不出“逻辑外键”这个概念。我倾向于在实体类里保留普通字段不加物理外键约束但给user_id、product_id、order_id建普通索引这样关联查询也快被问起来也说得清。4. 核心功能实现从登录到支付的代码闭环4.1 登录注册与JWT鉴权注册逻辑比较简单接收用户名和密码检验用户名是否重复用BCrypt加密密码后插入用户表。BCrypt有一个特点它每次生成的哈希值都不一样但校验时都能通过。好处是即使数据库泄露攻击者也很难反推出原始密码。很多学生用MD5存密码这种做法在答辩时属于送分题送给了评委换成BCrypt成本极低印象分却完全不同。登录逻辑根据用户名查出用户用BCrypt的matches方法校验密码成功后生成JWT返回给前端。JWT里我一般只放userId和username不放其他敏感信息过期时间根据需求设置。之后前端请求时在Header里带Authorization: Bearer token后端用一个拦截器统一校验。拦截器的核心逻辑很好讲拿到token解析成功放行解析失败返回401顺便把userId放入request的attribute中controller里直接取用。这样每个接口不用自己写鉴权代码。一个小补充更新密码或退出登录后想让旧token立刻失效可以在Redis里维护一个token黑名单。这种细节在答辩现场很加分它不是老师要求的功能但体现了你对安全问题的思考。4.2 商品浏览、分页与多条件搜索商品列表接口不要一次性把所有数据查出来。我用的是MyBatis-Plus分页但有个前提条件必须先注册分页插件。Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }这一步最容易漏漏掉的典型症状是分页参数传了但查询结果永远返回整表数据而且不报错。注册之后controller里new Page(current, size)再用LambdaQueryWrapper拼条件keyword对商品名称做likebrandId、categoryId、价格区间做范围过滤orderBy支持按销量、价格、上架时间排序。注意搜索关键词里的特殊字符比如%和_在like条件里需要适当转义否则用户输入一个%会把全表商品都搜出来。这也是一个小加分点。分页返回时建议自定义一个PageResult结构包含total、pages、list等字段不要直接把MyBatis-Plus的Page对象暴露给前端。这样前端拿到的数据结构稳定后面加字段也方便。4.3 购物车与下单的逻辑设计购物车加购逻辑比较简单查这个用户是否已有同款商品记录有就加数量没有就插入一条新记录。真正复杂的是下单流程我的实现思路是这样。从请求里拿购物车中勾选的商品列表逐个检查商品状态和库存。计算总金额插入订单表拿到订单号。遍历商品列表插入订单明细同时扣减库存、增加销量。最后删除购物车中已下单的商品。这一步必须用Transactional包起来任何一个环节失败数据库整体回滚否则就会出现订单建好了但库存没扣或者库存扣了但订单没有的严重数据一致性问题。我见过不少项目没加事务靠运气跑正常下单看起来没问题一旦网络或代码异常对账就对不上。更细的一个坑Spring事务默认只对运行时异常回滚对编译期异常默认不回滚。所以事务方法里如果捕获了异常记得重新抛出一个运行时异常否则回滚不会生效。这个点特别适合在答辩时主动讲出来一听就是写过完整项目的人。库存扣减如果要应对并发场景最简单的做法是商品表加version字段做乐观锁。核心SQL长这样UPDATE product SET stock stock - #{num}, version version 1 WHERE id #{id} AND version #{version} AND stock #{num};如果更新行数为0说明库存不足或版本冲突直接抛异常提示用户“手慢了库存不足”。这种处理在毕设答辩里已经足够有说服力不用硬上分布式锁。4.4 模拟支付与订单状态机真正接入支付宝沙箱对毕设来说是个不错的加分项但复杂度也高。我通常建议先做模拟支付订单列表里点“去支付”进入一个模拟收银台确认金额后点击“确认支付”直接把订单状态从待付款改成已支付并记录支付时间。这样核心链路完整又能演示。如果有余力再按支付宝开放平台的沙箱流程接入注意回调验签和普通接口的token校验是两回事。订单状态流转可以设计成一个简单的状态机待付款、待发货、待收货、已完成待付款可以取消待发货可以退款。状态字段在用户端和后台管理端根据角色控制展示和操作按钮比如用户端只有待付款订单才能看到“去支付”按钮待发货订单才能看到“取消订单”后台才有“发货”按钮。用Map或switch维护“当前状态可执行的操作”列表能有效避免用户绕过界面直接调接口乱改订单状态。这类控制逻辑很简单但体现了工程意识也是我每年代码审查时最关注的点之一。5. 最容易暴露诚意的边角问题分页、XSS、并发、上传5.1 分页插件失效的几种情况前面提到漏注册MybatisPlusInterceptor会导致分页失效这是最常见的一种。除此以外还有几个情况值得注意。第一分页当前页从1开始还是从0开始要统一建议pageNum从1开始size限制最大到100防止有人传一个巨大的size把数据库拖垮。第二多表连查时如果使用了自定义SQL分页可能不生效。解决方法是把分页参数通过方法参数传入或者用MyBatis-Plus的Page对象作为Mapper方法第一个参数。第三排序字段来自前端传参时必须做白名单校验不能直接把字符串拼进order by里否则容易产生SQL注入。我一般维护一个允许排序的字段列表前端传字段名后端映射成白名单里的值。5.2 全局XSS过滤到底要不要做、怎么做XSS是面试题高频也是答辩老师爱问的点。用户在评论、昵称、搜索框里输入scriptalert(xss)/script如果前端不转义、后端不处理这段代码就可能在你浏览器里执行。最省事的方案是前端Vue的插值语法默认转义服务端渲染时手动转义。更稳妥的是后端加一个过滤器把请求参数里的和转义或者把危险标签过滤掉。具体做法定义一个XssFilter实现Filter包装HttpServletRequest在getParameter、getHeader等方法里做清理。但要注意上传文件场景——如果单纯把所有参数都替换掉可能会破坏文件内容。正确的做法是过滤器只处理文本参数不处理multipart文件流上传PDF或图片时走单独的逻辑。很多全局过滤器设计时容易踩这个坑把文件流也清洗一遍结果上传的PDF直接打不开。这个点正好和开发者热词里“springboot项目全局过滤器处理上传pdf文件时xss攻击”对应上说明大家实际做项目时都会遇到。能把这个边界讲清楚的项目功底明显不一样。5.3 数据一致性与并发扣库存快递场景我在下单环节已经提到了乐观锁。这里再展开说一句如果你的项目里还加了秒杀或者限时抢购这些扩展功能建议在Redis里用Lua脚本预减库存再异步同步到数据库。但这个复杂度已经超过毕设必需除非你确实学得明白否则不要为了炫技给自己挖坑。普通商城把事务加对、把乐观锁写好已经能回答大部分并发提问。被问到“同一时间很多人买同一部手机怎么保证不超卖”你就按这个思路讲先查库存、下单、扣库存都在一个事务里扣库存SQL带stock #{num}条件数据库的行锁会保证同一时刻只有一个事务能更新这条记录。5.4 商品图上传本地目录还是MinIO图片上传看起来简单实际有三种方案。方案一直接存到项目目录或本地固定目录application.properties里配置upload.path再用自定义静态资源映射把访问路径和目录关联起来。优点是简单适合短平快完成项目缺点是重启或重新打包时要备份文件。方案二存到数据库BLOB字段不建议。数据库体积会膨胀查询变慢答辩老师一般也不认可。方案三用对象存储比如MinIO。这个方案可讲性最高。在服务器上用Docker启动MinIOSpringBoot里引入minio依赖配置endpoint、accessKey、secretKey、bucket上传时调用putObject返回可访问URL。用MinIO的好处是图片和项目分离搭建过程也能展示对中间件的理解。缺点是本地演示时需要多启动一个服务环境稍麻烦。我给学生的建议是毕设主体用方案一或方案三都行但至少把方案三的原理说清楚。现在搜MinIO相关内容的人很多说明这确实是一个标准化的生产级方案你写了就是加分项。6. 部署、演示与答辩让评委觉得你像个工程师6.1 打包部署的完整路径毕设不用像运维一样搞自动化部署但一个能正常运行的演示环境非常关键。我的建议路径如下。开发环境跑通后用Maven的package打出jar包。准备好SQL初始化脚本在演示用的数据库里跑一遍清掉个人测试数据插入一套干净的演示数据。如果是本地Windows环境直接java -jar xxx.jar启动如果用了云服务器把jar传到服务器上运行。前后端分离项目前端打包后的dist目录放到Nginx的html目录配置/api反向代理到后端端口。最容易翻车的三个地方是端口被占用、数据库账号密码不一致、依赖包没打进jar。所以交付前一定要用java -jar方式完整启动一遍确认能跑通才算完成。我见过太多在IDEA里一切正常、一打包就启动失败的案例原因无非就是用了IDEA内置的数据库配置打成jar后连接信息对不上。6.2 演示脚本怎么设计才不冷场演示时间通常5到10分钟内容要有逻辑主线。我梳理的顺序是先展示前台首页轮播图、分类、商品列表然后注册一个新用户走一遍登录、搜索、看商品详情、加入购物车、下单、模拟支付后台展示管理员登录、编辑商品、上架下架、处理订单发货。每一步控制在半分钟内让评委看到完整闭环。演示前把异常情况预演一遍库存不足时下单会提示什么、重复提交订单会不会生成两条、输入超长文本会不会报错。这些设计好的“防御表现”往往比正常流程更能说明你会思考问题。平时最怕演示时突然报错所以提前把最常用的几条路径跑三遍以上顺手把浏览器缓存清掉再试一次。6.3 被追问时的应对话术答辩常见问题可以分几类为什么选这个技术、数据库为什么这么设计、某个功能怎么实现、并发问题怎么办。我建议准备一个“三句话应答”模板先说是做什么再说怎么做的最后说为什么这样选择。例如被问“为什么用JWT不用Session”可以答“JWT用户登录后不用在服务端保存会话状态适合前后端分离、多端部署过期和刷新都可以通过配置控制Session方案需要依赖服务端存储在扩展性上有局限。”被问“你这个项目是自己做的吗”最好的证明不是拍胸脯而是坦然讲出某个细节当初怎么踩坑、怎么改比如分页插件漏配置导致列表查询异常或者上传图片时静态资源映射路径写错。这些只有真正写过代码的人才能说得这么具体光是背概念是背不出这种细节的。最后补一句我的个人心得做毕设和考试不一样分数从来不只看你功能多不多而是看你能不能把每个决定说清楚。我见过太多花里胡哨的商城项目一被问到为什么用Redis、为什么订单表和订单明细要分开就答不上来反而是那些功能朴素但逻辑完整、能讲清设计和取舍的项目最后拿了不错的成绩。把准备答辩的时间一半留给跑通流程一半留给“问自己为什么”这个题目就不难做成一件真正拿得出手的作品。