企业官网建设流程全解析

计算机毕设 Java 校园网上店铺 SSM 框架：从选题分析到上线部署的完整复盘

这个题目我太熟了。Java + SSM 框架做校园网上店铺，几乎是计算机毕设里被点名最多的一类选题。你拿到题目的时候第一反应可能是：校园网上店铺到底要做到什么程度？SSM 框架里的 Spring、SpringMVC、MyBatis 怎么串起来？购物车、下单、支付这些流程怎么拧成一条线？

一句话概括：这是一个面向校园场景、覆盖用户注册登录、商品浏览、购物车、提交订单、模拟支付、订单管理和后台商品管理等功能闭环的 Java Web 全流程电商系统，核心框架是 Spring + SpringMVC + MyBatis（SSM），数据库用 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 数据库设计：核心表结构与建模思路

数据库设计是整个项目的地基，也是最容易在评审时被翻出来问的部分。我一个一个说清楚设计理由和坑点。

人员相关表里，最基础的是用户表 user：id（自增主键）、username（唯一索引）、password、real_name、phone、role（0买家，1商家，2管理员）、status（0正常，1禁用）、address、create_time。这里字段别贪多，能支撑业务即可。需要注意 password 不要存明文，用 MD5 加盐，盐可以简单用注册时间戳，虽然强度一般，但比明文强一个档次，答辩时算一个技术点。

分类表 category：id、name、sort_order。商品表 product：id、name、category_id、price、stock、image、description、status（0下架，1上架）、seller_id（关联商家用户）、sales_count、create_time。price 字段必须用 DECIMAL(10,2)，别用 FLOAT 或 DOUBLE，二进制浮点数算金额会有精度问题，老师问到"为什么不用 double"时，你能答出"DECIMAL 是定点数，避免金额精度误差"就已经领先不少同学了。

购物车表 cart：id、user_id、product_id、quantity，user_id 和 product_id 做唯一联合索引，避免同一商品重复插入多行。订单表 orders：id、order_no（唯一索引）、user_id、total_amount、status、receiver_name、receiver_phone、receiver_address、create_time、pay_time、ship_time、finish_time。订单明细表 order_item：id、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.xml

Maven 依赖版本搭配是第一个无声的杀手。我实测稳定的一套组合是：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，而且要放在过滤器链最前面。很多同学页面乱码查了半天，其实是这个过滤器没配。接着配置 DispatcherServlet，url-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 加盐，盐可以用时间戳，代码层面不建议用明文存储，这是安全底线。

登录逻辑要同时处理两种不同的状态跳转。根据用户名密码查库，比对通过后将用户对象写入 session，key 建议叫 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 必须加 serverTimezone=Asia/Shanghai 参数，否则报时区错误。

数据库准备可以直接用一份初始化 SQL 脚本，一张表一建，并插入测试数据。测试数据要"够真"：商品名称用"瑞幸校园店 生椰拿铁""水果捞 大份""机械键盘 青轴"这类校园场景真实消费的品类；图片可以先用占位图链接，能正常展示即可。至少准备 20 条商品、5 个分类、3 个测试账号（买家、商家、管理员各一个），账号密码写死在 README 里，答辩时直接登录不浪费时间。

IDEA 建项目时选 Maven 的 webapp 骨架，然后把上面说的目录结构手动补齐。Maven 依赖下载慢的问题，在 settings.xml 里配阿里云镜像，能省掉大量等待时间。

4.2 一个商品列表页的完整链路实现

我以商品列表页为例子，把 SSM 的请求链路完整讲一遍，这是理解整个项目结构的最佳路径，也方便你举一反三到其他页面。

第一步，编写 entity 的 Product 类，属性与表字段一一对应。写法注意 MyBatis 的驼峰映射：配好 mapUnderscoreToCamelCase=true 后，数据库字段 seller_id 能自动映射成 sellerId，不用每个字段写 resultMap。

第二步，编写 Mapper 接口和 XML。查询商品列表的 SQL 支持按分类筛选和关键词搜索：

SELECT * FROM product WHERE status = 1 <if test="categoryId != null"> AND category_id = #{categoryId} </if> <if test="keyword != null and keyword != ''"> AND name LIKE CONCAT('%', #{keyword}, '%') </if> ORDER BY create_time DESC

select 结果用 resultType 指定 Product 实体即可。null 判断要写清楚，否则没传分类时 SQL 拼接出错。

第三步，Service 接口定义 queryProductList(categoryId, keyword) 方法，实现类中先做参数合法性校验，再调 Mapper。

第四步，Controller 接收页面参数，调用 Service，把返回的 List 放进 Model 并 return "mall/list"。Controller 方法里顺便查出分类列表也放进 Model，供页面顶部导航使用。

第五步，JSP 页面用 JSTL 的 c:forEach 循环渲染商品卡片，图片、价格、名称、销量逐个展示。加入购物车按钮用>