计算机毕设 Java 校园网上店铺 SSM 框架从选题分析到上线部署的完整复盘这个题目我太熟了。Java SSM 框架做校园网上店铺几乎是计算机毕设里被点名最多的一类选题。你拿到题目的时候第一反应可能是校园网上店铺到底要做到什么程度SSM 框架里的 Spring、SpringMVC、MyBatis 怎么串起来购物车、下单、支付这些流程怎么拧成一条线一句话概括这是一个面向校园场景、覆盖用户注册登录、商品浏览、购物车、提交订单、模拟支付、订单管理和后台商品管理等功能闭环的 Java Web 全流程电商系统核心框架是 Spring SpringMVC MyBatisSSM数据库用 MySQL前端以 JSP Bootstrap 为主。它既是计算机专业本科毕设的经典选题也是想从零吃透 SSM 整合逻辑的入门项目。下面我把整个项目的需求拆解、架构设计、代码实现、部署过程和答辩避坑一次讲清楚全是实际操作层面的经验。1. 项目整体设计与需求拆解1.1 这个毕设题目到底要做什么先说结论校园网上店铺的核心不是网上店铺这四个字而是全流程管理。这个词才是题目真正的重点。很多同学拿到题目直接往电商平台的大而全方向冲首页搞轮播图、商品详情搞SKU规格、支付对接微信支付宝、后台搞数据大屏最后三个月开发周期被拖垮答辩还被老师问你这规模是不是超过毕设范围了。正确的做法是先界定边界。校园网上店铺的服务对象是校园内的三类人学生买家、校园店铺商家、平台管理员。核心业务链路是商家上架商品 → 买家浏览搜索 → 加入购物车 → 下单填写收货地址 → 模拟支付 → 商家发货 → 确认收货 → 订单完成。后台则围绕用户管理、商品审批或维护、订单全状态管理展开。所谓全流程不是指功能多而是指交易链路完整从商品上架、用户下单、支付确认、发货履约到订单完结每个环节都要有一条清晰的状态流转线。这恰恰是毕设评分里系统完整性和业务闭环两个评分点。站在答辩的角度老师更希望看到一个精简但闭环清晰的系统而不是一堆没串起来的碎片功能。另外别忘了校园这个场景的价值。校园用户密度高、配送半径小、需求时段集中可以设计一些差异点比如按宿舍楼配送、校园卡模拟支付、商家入驻校验校园资质这些细节不需要多复杂却能在答辩时体现出你对业务场景的理解比凭空加功能有说服力得多。1.2 为什么选 SSM 框架而不是 Spring Boot先说明一点用 Spring Boot 做毕设当然可以而且开发效率更高。但这道题目明确写了 SSM所以核心问题是你能否说清楚为什么保留这个技术选型以及怎么让 SSM 发挥它的价值。SSM 的价值在于拆开明白。Spring Boot 把什么都自动配置好了你写一个注解就能跑起来但对于答辩来说老师追问Spring 容器是怎么启动的MyBatis 的 Mapper 代理是怎么生成的事务是通过什么机制回滚的如果你只依赖 Boot 的自动配置很容易卡壳。SSM 要求你手动配置 applicationContext.xml、springmvc.xml、web.xml这个过程逼你把每个组件的职责理清楚。用开车做个类比Spring Boot 是自动挡SSM 是手动挡。自动挡上路快但手动挡让你知道发动机和变速箱是怎么咬合的。毕设的评价体系里学习过程和对框架原理的理解本身就占分SSM 在这方面的训练价值是 Boot 给不了的。当然如果你时间紧、基础薄弱也可以基于 SSM 核心代码跑通后在文档里补充说明如何迁移到 Spring Boot这个思路反而更显工程素养。选 SSM 还有一个现实原因学校教材和实验室环境大量沿用这套体系指导教师对你查代码、做调试更轻车熟路。项目遇到瓶颈时能更快得到有效指导这对毕设周期极其重要。1.3 功能模块拆解与角色设计功能拆解不应该是拍脑袋列清单而是从角色出发把每个角色的操作场景列出来再转成功能点。买家角色需要的是注册登录、商品按分类浏览、按关键词搜索、查看商品详情、加入购物车、修改购物车数量、提交订单、模拟支付、查看订单列表和详情、确认收货、编辑个人资料。商家角色需要的是店铺商品管理新增、上下架、编辑库存和价格、订单处理发货、查看自己店铺的订单列表。平台管理员角色需要的是用户管理禁用/恢复账号、商品分类管理、全部订单管理、基础数据统计用户数、商品数、订单数、交易额。这里有一个很多毕设项目都会踩的坑角色权限只做了前端按钮隐藏后端接口没有任何控制。比如商家直接改 URL 就能访问管理员接口这在答辩演示时虽然看不到但被老师问一句后端接口怎么防越权就会露馅。正确做法是写一个拦截器统一校验 session 中用户角色与访问路径前缀是否匹配商品管理路径前缀 /admin/seller/ 仅允许商家角色/admin/platform/ 仅允许管理员角色。模块划分上建议拆成前台商城门户、买家中心、商家中心、平台管理、登录注册、公共模块六块。每个模块的 controller 包路径按模块分比如 controller/mall、controller/buyer、controller/seller、controller/admin、controller/common后面写代码和答辩讲架构都会清楚很多。2. 核心技术选型与工程架构落地2.1 数据库设计核心表结构与建模思路数据库设计是整个项目的地基也是最容易在评审时被翻出来问的部分。我一个一个说清楚设计理由和坑点。人员相关表里最基础的是用户表 userid自增主键、username唯一索引、password、real_name、phone、role0买家1商家2管理员、status0正常1禁用、address、create_time。这里字段别贪多能支撑业务即可。需要注意 password 不要存明文用 MD5 加盐盐可以简单用注册时间戳虽然强度一般但比明文强一个档次答辩时算一个技术点。分类表 categoryid、name、sort_order。商品表 productid、name、category_id、price、stock、image、description、status0下架1上架、seller_id关联商家用户、sales_count、create_time。price 字段必须用 DECIMAL(10,2)别用 FLOAT 或 DOUBLE二进制浮点数算金额会有精度问题老师问到为什么不用 double时你能答出DECIMAL 是定点数避免金额精度误差就已经领先不少同学了。购物车表 cartid、user_id、product_id、quantityuser_id 和 product_id 做唯一联合索引避免同一商品重复插入多行。订单表 ordersid、order_no唯一索引、user_id、total_amount、status、receiver_name、receiver_phone、receiver_address、create_time、pay_time、ship_time、finish_time。订单明细表 order_itemid、order_id、product_id、product_name、price、quantity。注意 order 是 MySQL 关键字表名最好用 orders 规避语法坑。外键我个人的建议是表结构上建立逻辑关联但不一定非要在 MySQL 里声明物理外键。毕设项目里物理外键在删除用户或商品时会遇到一堆约束问题代码里通过业务逻辑控制引用关系更灵活。这个做法在真实企业开发中也很常见答辩时解释为保证扩展性和删除灵活性即可。要从实际需求出发设计几张索引除主键外user.username 建唯一索引orders.order_no 建唯一索引orders.user_id 建普通索引product.category_id 和 seller_id 建普通索引product.status 建普通索引。理由很简单搜索、列表、状态筛选都要走到这些字段没有索引在数据量大了之后慢查询是必然的。2.2 工程目录结构与 Maven 依赖管理SSM 项目结构最忌讳的是所有类堆在一起。我推荐的分层结构如下照着建就行src/main/java ├── com.campus.shop │ ├── controller # 表现层参数接收与视图返回 │ │ ├── mall # 前台商城 │ │ ├── buyer # 买家中心 │ │ ├── seller # 商家中心 │ │ ├── admin # 平台管理 │ │ └── common # 登录注册等公共模块 │ ├── service # 业务层接口 │ ├── service.impl # 业务层实现事务在这层 │ ├── mapper # MyBatis Mapper接口 │ ├── entity # 实体类与表对应 │ ├── interceptor # 登录与角色拦截器 │ ├── common # 常量、结果封装、工具类 │ └── dto # 页面传参的封装对象 src/main/resources │ ├── jdbc.properties │ ├── mybatis-config.xml │ ├── springmvc.xml │ └── applicationContext.xml src/main/webapp │ ├── static # css、js、images │ └── WEB-INF │ ├── views # JSP页面按模块分目录 │ └── web.xmlMaven 依赖版本搭配是第一个无声的杀手。我实测稳定的一套组合是JDK 1.8、Spring 5.1.x、MyBatis 3.5.x、mybatis-spring 2.0.x、mysql-connector-java 8.0.x、Druid 1.1.x、JSTL 1.2、Jackson 2.9.x。Servlet 和 JSP 相关依赖用 provided 范围Tomcat 自带的没必要打进 war 包。Druid 连接池强烈建议用除了链接管理外它自带监控页面可以看 SQL 执行情况。答辩时现场打开 Druid 监控展示慢 SQL 和活跃连接数是很大的加分项。2.3 SSM 三大配置文件的整合逻辑SSM 整合的难点不在单个框架而在三个配置文件的职责划分和衔接顺序。我把整合思路讲透你按这个理解去写配置基本不会乱。applicationContext.xml 是 Spring 的根容器管 service 和 mapper。核心配置项有三个开启注解扫描但排除 Controller用 context:component-scan context:exclude-filter 指定 Controller 注解排除引入 jdbc.properties 并配置 Druid 数据源配置 SqlSessionFactoryBean注入数据源和 MyBatis 配置文件路径同时用 MapperScannerConfigurer 扫描 mapper 接口包这样 Mapper 不需要写实现类就能注入。事务管理用 DataSourceTransactionManager再配上 tx:annotation-driven 打开 Transactional 注解支持。springmvc.xml 是 SpringMVC 的子容器管 Controller 和视图层。要配置的地方有开启注解驱动annotation-driven配置视图解析器 InternalResourceViewResolver前缀设置为 /WEB-INF/views/后缀为 .jsp这样 Controller 里 return mall/index 就能对应到 /WEB-INF/views/mall/index.jsp配置静态资源映射把 /static/** 映射到 /static/同时要放行静态资源否则 CSS、JS、图片全被 DispatcherServlet 拦截。web.xml 里最常踩的坑是字符编码过滤器。必须加上 CharacterEncodingFilter强制 encoding 为 UTF-8而且要放在过滤器链最前面。很多同学页面乱码查了半天其实是这个过滤器没配。接着配置 DispatcherServleturl-pattern 用 /注意不是 /。/ 不会拦截 JSP 和静态资源但 / 会把 JSP 也拦截下来导致页面 404 或者白屏这个细节反复出现的频率非常高。还有一点配合 IDEA 使用时要特别注意如果用了 Maven 的 tomcat7 插件运行项目指路由 / 没问题但 IDEA 自带的 Tomcat 集成方式更推荐直接在 Run Configuration 里配置 local Tomcat。war 包方式部署时 context path 默认是项目名前端所有跳转路径要么用绝对路径加项目前缀要么基于 pageContext.request.contextPath 拼路径最省心的是全部使用相对 contextPath 的绝对路径避免部署后一堆 404。3. 核心业务流程与代码实现3.1 用户登录注册与后端权限控制登录注册是入口但它在答辩中被追问的频率远超你的想象。先说注册页面表单校验用户名格式、密码长度、两次密码一致性这些用前端 JS 做一层就够了但后端也必须做同样的校验不能信任任何前端传参。查重逻辑是 username 是否已存在存在则提示密码加密用 MD5 加盐盐可以用时间戳代码层面不建议用明文存储这是安全底线。登录逻辑要同时处理两种不同的状态跳转。根据用户名密码查库比对通过后将用户对象写入 sessionkey 建议叫 loginUser后续所有角色判断都用它。如果用户是买家跳回主页如果是商家或管理员跳对应后台。这里有一个我被问过的点如何在登录后跳回之前访问的页面。简单做法是登录时带上 redirect 参数记录来源 URL登录成功后重定向回该地址一个小功能显得系统体验完整。拦截器是权限控制的骨架。我写两个拦截器LoginInterceptor 和 RoleInterceptor。LoginInterceptor 判断 session 中是否有 loginUser没有则重定向到登录页有则放行并顺手把用户对象塞进 request。RoleInterceptor 再判断访问路径前缀和角色匹配度例如 /seller/** 需要角色等于 1/admin/** 需要角色等于 2不匹配则返回 403 页面。在 springmvc.xml 里配置 mvc:interceptors 时登录页、注册页、静态资源、商品浏览这些公开路径要排除在外。3.2 购物车Session 方案还是数据库表方案购物车是电商系统的核心交互枢纽毕设里有两种主流实现方式取舍逻辑我先讲清楚。方案一是纯 Session 存 List好处是不用建表、下单时直接取内存数据坏处是浏览器关闭就丢失、换设备不同步。方案二是走数据库 cart 表好处是用户换个浏览器购物车还在、服务器重启数据不丢坏处是每次增删改都要查一次库。我的建议是选数据库方案。为什么毕设展示阶段老师很可能让你演示加入购物车后刷新页面、重新登录购物车还在数据库方案能稳稳接住这个演示场景。Session 方案虽然实现更简单但演示一翻车就得不偿失。数据表方案代码量其实也就多三四十行主要多出来的代码是联表查询把商品 id 关联商品表的图片和单价。购物车列表的查询逻辑直接用三表联查cart 表关联 product 表再关联 user 表满足权限隔离SQL 写成 JOIN product ON cart.product_id product.id WHERE cart.user_id #{userId}需要显示的字段包括商品图片、名称、单价、数量、小计。加入购物车时先查该用户是否已经有该商品有则数量加一没有则插入新行。购物车里减数量到零时直接删行。总金额在 Service 层算用 BigDecimal不要用 double 累加这也是精度问题的延续。接口设计上购物车所有操作路径都以 /cart/** 开头修改数量用单独接口删除用单独接口。页面用 Ajax 调用局部刷新购物车数量小计体验比整页刷新好很多。3.3 下单事务订单号生成与库存扣减下单是全流程管理里最考验功底的一段代码因为它同时涉及多条写操作和一致性问题。下单的操作序列是校验购物车非空 → 计算总金额 → 插入订单主表 → 批量插入订单明细 → 扣减库存 → 清空购物车 → 返回订单号跳转支付页。整个序列必须在同一个事务里任何一步失败都要整体回滚。Service 层方法加 Transactional 注解这是标准做法。但有三个细节值得展开。第一事务注解的传播行为和回滚条件。默认传播级别 REQUIRED 够用rollbackFor 要显式写成 Exception.class因为 Spring 默认只回滚 RuntimeException如果业务代码抛了受检异常事务不会回滚这个 bug 极其隐蔽。为了保险可以在方法里捕获所有异常手动抛出 RuntimeException 触发回滚。第二订单号生成策略。格式建议yyyyMMddHHmmss 用户ID 4位随机数。生成时检查唯一性如果碰撞则重新生成。这个方案虽然在高并发下覆盖率有限但毕设场景绰绰有余。千万别用数据库自增主键当订单号一是暴露订单量二是和业务特征脱节答辩很容易被挑刺。第三扣减库存的边界条件。常规做法是 SELECT 查库存再在 Java 里判断 stock 是否足够不够则抛异常。但这个做法有并发漏洞正确姿势是直接在 SQL 里做条件更新UPDATE product SET stock stock - #{quantity} WHERE id #{productId} AND stock #{quantity}这个 UPDATE 的返回值就是受影响行数。Java 里判断返回值如果为 0说明库存不足抛出运行时异常触发事务回滚。一条 SQL 就解决了超卖问题也是整个系统里最能体现工程能力的一段代码。批量插入订单明细可以用 MyBatis 的 foreach 标签一条 insert 语句循环执行多条明细相比逐条插入性能好不少。3.4 订单状态机与商家后台发货流程订单状态是整个系统的业务进度条设计时要保证状态流转是单向且明确的。我用一个整数状态字段表示-1 已取消0 待支付1 已支付待发货2 已发货3 已完成。每步状态迁移都写死在 Service 层方法里不提供直接 jump 的接口比如只有待支付订单可以取消只有已支付订单可以发货只有已发货订单可以确认收货。买家端订单操作就三个待支付时取消订单、已发货时确认收货、查看订单详情。取消订单要把商品库存加回来这里同样要放在事务里做。确认收货则把状态置为 3记录 finish_time。商家端核心操作是发货。系统里没有物流单号的概念毕设简化为填写备注点击发货本质是把状态从 1 改为 2填 ship_time。但这个接口要校验订单归属于当前登录商家不能把别人店铺的订单也发了。联表查询 order_item 里的 product 找到 seller_id与当前用户比对不匹配则拒绝。支付环节在毕设里是用模拟支付完成的。买家点去支付跳到支付确认页页面上展示订单金额和模拟支付成功按钮点击后把状态从 0 改为 1写入 pay_time。这里可以扩展一下在支付页里加入校园卡号输入框模拟校园卡支付让系统更贴合校园场景虽然只是前端加个字段但答辩时能讲出场景故事。4. 实战步骤从搭建骨架到部署上线4.1 环境准备与数据库初始化开发环境建议固定一套组合避免版本兼容性折磨JDK 1.8、Maven 3.6 以上、Tomcat 8.5 或 9、MySQL 5.7 或 8.0、IDEA 2020 以上。MySQL 8.0 和 5.7 在 JDBC 驱动和连接参数上略有差异8.0 必须加 serverTimezoneAsia/Shanghai 参数否则报时区错误。数据库准备可以直接用一份初始化 SQL 脚本一张表一建并插入测试数据。测试数据要够真商品名称用瑞幸校园店 生椰拿铁水果捞 大份机械键盘 青轴这类校园场景真实消费的品类图片可以先用占位图链接能正常展示即可。至少准备 20 条商品、5 个分类、3 个测试账号买家、商家、管理员各一个账号密码写死在 README 里答辩时直接登录不浪费时间。IDEA 建项目时选 Maven 的 webapp 骨架然后把上面说的目录结构手动补齐。Maven 依赖下载慢的问题在 settings.xml 里配阿里云镜像能省掉大量等待时间。4.2 一个商品列表页的完整链路实现我以商品列表页为例子把 SSM 的请求链路完整讲一遍这是理解整个项目结构的最佳路径也方便你举一反三到其他页面。第一步编写 entity 的 Product 类属性与表字段一一对应。写法注意 MyBatis 的驼峰映射配好 mapUnderscoreToCamelCasetrue 后数据库字段 seller_id 能自动映射成 sellerId不用每个字段写 resultMap。第二步编写 Mapper 接口和 XML。查询商品列表的 SQL 支持按分类筛选和关键词搜索SELECT * FROM product WHERE status 1 if testcategoryId ! null AND category_id #{categoryId} /if if testkeyword ! null and keyword ! AND name LIKE CONCAT(%, #{keyword}, %) /if ORDER BY create_time DESCselect 结果用 resultType 指定 Product 实体即可。null 判断要写清楚否则没传分类时 SQL 拼接出错。第三步Service 接口定义 queryProductList(categoryId, keyword) 方法实现类中先做参数合法性校验再调 Mapper。第四步Controller 接收页面参数调用 Service把返回的 List 放进 Model 并 return mall/list。Controller 方法里顺便查出分类列表也放进 Model供页面顶部导航使用。第五步JSP 页面用 JSTL 的 c:forEach 循环渲染商品卡片图片、价格、名称、销量逐个展示。加入购物车按钮用>