做Java后端的人对SSM这三个字母肯定不会陌生。这个项目标题“基于SSM的水果蔬菜商城系统_812llq05”一眼能看出是典型的Java Web课程设计/毕业设计项目核心是Spring SpringMVC MyBatis三件套组合的电商系统。市面上的商城项目多如牛毛但果蔬生鲜这个品类其实比普通的图书、数码商城更有意思因为它天然带库存、保质期、配送状态这些真实业务约束做起来不会只是个“玩具项目”。这篇内容我不打算只贴功能列表而是把这个项目从数据建模、后台管理、购物车、下单扣库存到后台权限、图片上传等完整链路拆开讲清楚。无论你是要自己动手写一个交作业还是拿别人的源码来跑通然后做二次开发这篇都能给你一条能落地的路线。1. 项目整体设计与技术选型思路1.1 果蔬商城这种选题到底在考核什么很多同学选系统做课设的时候喜欢挑“学生管理系统”“图书管理系统”这种平平无奇的题目结果答辩时老师问一句“你这个系统有什么难点”半天答不上来。果蔬商城不一样它的业务链路比普通信息管理系统长得多从用户注册登录、浏览商品、加购物车到生成订单、模拟支付、后台发货再到库存扣减和统计报表整条链路走完基本覆盖了一个Web系统最常见的业务场景。而且果蔬生鲜有个特点库存变动频繁、订单状态多。今天土豆到货50斤卖出去30斤你需要在系统里实时扣减用户下单后不付款你要在超时后取消订单后台管理员发货后用户端状态要跟着变。这些逻辑加在一起系统必须具备清晰的状态机设计和严谨的事务处理这恰好是SSM项目最能体现“含金量”的地方。1.2 功能模块怎么拆前后台各自管什么我在规划这个系统时没有把它做成一个单一大模块而是按“前台用户端”和“后台管理端”两个子域来拆这是电商系统很常见的做法也是后期扩展和分工的基础。前台用户端包含四块核心功能用户模块注册、登录、个人信息维护、收货地址管理商品模块商品列表展示、按分类筛选、关键词搜索、商品详情查看购物车模块加入购物车、修改数量、删除、批量结算订单模块提交订单、模拟支付、订单列表、订单详情、取消订单后台管理端包含三块核心功能商品管理商品CRUD、上下架、库存调整、图片上传订单管理订单列表、订单详情、发货操作、订单状态修改数据统计商品数量、订单数、销售额、用户数等核心指标这样拆的好处是前后台的功能边界很清晰代码分包的时候也能严格遵循前台访问/user/**、/cart/**、/order/**后台访问/admin/**后面做登录拦截、权限控制时直接按URL前缀来划分非常方便。1.3 为什么选SSM而不是SpringBoot这个问题基本是答辩必问我自己也经常被学员问“老师现在企业都用SpringBoot为什么课设还要用SSM”。我的回答是课设的目的不是追赶技术潮流而是让你理解Web开发的底层协作流程。SSM三个组件各管一摊Spring负责管理对象Service、DAO这些Bean的创建和依赖注入SpringMVC负责接收HTTP请求并把请求参数绑定到Java对象上MyBatis负责Java对象和数据库记录之间的映射。三者是分工协作的关系而不是重复造轮子。你在SSM项目里手动配置web.xml、spring-mvc.xml、spring-mybatis.xml时会真切感受到“原来一个请求从URL到数据库中间要经过这么多层次的转手”。理解了这套流程后面学SpringBoot就只是一层封装的问题本质没变。当然如果指导老师允许你完全可以把MyBatis换成MyBatis-Plus来减少样板代码或者提前配置好通用Mapper这些都是优化选项不改变SSM这个框架组合的本质。2. 数据模型与核心表结构设计2.1 商品、分类、用户、购物车这几张关键表怎么建数据库设计是整个系统最不能偷懒的环节。表结构设计得好后面的Mapper写起来就顺业务代码也少很多恶心的判断。下面是这个果蔬商城项目中最核心的四张表SQL直接按照这个建库思路来。用户表是系统的基础表包含用户身份信息和默认收货信息。这里要注意密码字段不能存明文至少要存MD5或SHA-256加密后的值。很多课设项目直接明文存密码答辩时被老师点一下就很尴尬。系统提供一个收货地址字段就够完整的地址簿功能可以留作扩展。CREATE TABLE user ( id int(11) NOT NULL AUTO_INCREMENT COMMENT 用户ID, username varchar(50) NOT NULL COMMENT 用户名, password varchar(64) NOT NULL COMMENT 密码(MD5加密), phone varchar(20) DEFAULT NULL COMMENT 手机号, address varchar(200) DEFAULT NULL COMMENT 收货地址, role tinyint(4) DEFAULT 0 COMMENT 角色 0-普通用户 1-管理员, create_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT 注册时间, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;商品信息表是商城系统的核心资产。对于果蔬类商品我特别加了一个unit字段用来表示计量单位斤、盒、份等这个字段看着不起眼但在前台展示和下单计算时非常关键没有它就会出现“用户买了个苹果不知道是一斤还是一个”的困惑。CREATE TABLE goods ( id int(11) NOT NULL AUTO_INCREMENT COMMENT 商品ID, category_id int(11) NOT NULL COMMENT 分类ID, name varchar(100) NOT NULL COMMENT 商品名称, subtitle varchar(200) DEFAULT NULL COMMENT 副标题, price decimal(10,2) NOT NULL COMMENT 单价, unit varchar(20) DEFAULT 斤 COMMENT 计量单位, stock int(11) NOT NULL DEFAULT 0 COMMENT 库存, sales int(11) NOT NULL DEFAULT 0 COMMENT 销量, image varchar(255) DEFAULT NULL COMMENT 商品图片路径, description text COMMENT 商品详情, status tinyint(4) DEFAULT 1 COMMENT 状态 1-上架 0-下架, create_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, PRIMARY KEY (id), KEY idx_category (category_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;分类表就很简单但它是商品模块的一个基础维度。前台导航、后台商品管理、筛选功能都依赖它。设计时给它加一个sort字段可以控制前台分类的展示顺序。CREATE TABLE category ( id int(11) NOT NULL AUTO_INCREMENT, name varchar(50) NOT NULL, sort int(11) DEFAULT 0, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;购物车表我选择了数据库存储方案而不是Session购物车后面第3章我会详细解释这么选的考量。这张表本质是用户和商品的关联表额外记录数量再加一个创建时间去重。CREATE TABLE cart ( id int(11) NOT NULL AUTO_INCREMENT, user_id int(11) NOT NULL, goods_id int(11) NOT NULL, quantity int(11) NOT NULL DEFAULT 1, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_user_goods (user_id, goods_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;注意这张表有个非常关键的点user_id和goods_id加了一个联合唯一索引。这意味着同一用户往购物车加同一个商品时数据库层面就保证只有一条记录我们只需要做数量累加不会出现两条重复记录。这个设计能免掉很多非必要的查询判断。2.2 订单主表、订单明细表为什么要拆开订单模块是电商系统里最重要的部分也是最容易被课设项目做糊弄的部分。很多人图省事直接在订单表里存商品名称和价格一张表走天下。这样做的后果是一旦用户在一个订单里买了多个商品数据就变得非常难以处理。更合理的方案是拆成两张表订单主表和订单明细表。订单主表存储订单的整体信息包括订单号、用户ID、订单总金额、收货信息、订单状态等。订单号我推荐用时间戳加随机数的组合格式类似20250115103812001保证唯一即可不一定非要搞一套复杂雪花算法。CREATE TABLE order_master ( id int(11) NOT NULL AUTO_INCREMENT, order_no varchar(64) NOT NULL COMMENT 订单号, user_id int(11) NOT NULL, total_amount decimal(10,2) NOT NULL COMMENT 订单总金额, receiver_name varchar(50) DEFAULT NULL, receiver_phone varchar(20) DEFAULT NULL, receiver_address varchar(200) DEFAULT NULL, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已发货 3已完成 4已取消, pay_time datetime DEFAULT NULL, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;订单明细表存储订单里每个商品的快照信息。快照这个词很关键下单时把商品名称、单价、图片都拷贝一份到这个表里后面哪怕后台把商品改价、删除历史订单依然能完整显示当时买了什么、花了多少钱。这种设计在真实电商系统里是标配放在课设项目里就是一个很亮眼的细节。CREATE TABLE order_item ( id int(11) NOT NULL AUTO_INCREMENT, order_id int(11) NOT NULL, goods_id int(11) NOT NULL, goods_name varchar(100) NOT NULL, goods_image varchar(255) DEFAULT NULL, price decimal(10,2) NOT NULL COMMENT 下单时单价, quantity int(11) NOT NULL, total_price decimal(10,2) NOT NULL, PRIMARY KEY (id), KEY idx_order (order_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里特别提醒一个容易被忽略的坑order_master里的total_amount应该等于明细表中total_price的总和。实现方式最好是在Service层循环计算二选一但不要一处用前台传入的值、一处用数据库查出来的值前后对不上。我曾经见过一个项目因为前台下单时把商品总金额和商品明细传给后端后端图省事直接把前台传的total存进表里结果用户篡改请求参数就能把订单金额改成一分钱。正确做法是后端拿商品单价和数量重新计算下单金额前台的金额只作展示用不作存储依据。2.3 订单状态流转用数字还是字符串订单status字段我建议直接用一个tinyint数字来标识而不是存“待支付”“已支付”这样的中文。原因有两个一是数字存储更省空间查询效率更高二是状态机在代码里用数字判断更清晰不容易被数据库里的中文脏数据干扰。这个系统的订单状态流转我设计成一条单链各种状态对应如下状态值含义可流转到0待支付已支付、已取消1已支付已发货、已取消2已发货已完成3已完成终止4已取消终止在代码里写状态流转判断时最推荐的做法是使用常量类或枚举来定义这些状态而不是散落在业务代码里的魔法数字。比如定义一个OrderStatusEnum代码可读性瞬间提升一个档次。public enum OrderStatusEnum { WAIT_PAY(0, 待支付), PAID(1, 已支付), SHIPPED(2, 已发货), FINISHED(3, 已完成), CANCELLED(4, 已取消); private int code; private String desc; OrderStatusEnum(int code, String desc) { this.code code; this.desc desc; } public int getCode() { return code; } public String getDesc() { return desc; } }有了这个枚举前端渲染订单状态时就直接拿OrderStatusEnum转成中文描述后端业务里判断状态也不会出现“这个3到底是我定义的第3个状态还是什么其他含义”的情况。3. 核心业务链路实操从商品浏览到下单支付3.1 商品列表与搜索Controller到Mapper的一条完整调用链拿商品列表这个功能来说整个请求路径是这样的浏览器发起HTTP GET请求到/goods/list?categoryId1keyword苹果SpringMVC的DispatcherServlet把请求交给GoodsControllerController调用GoodsServiceService调用GoodsMapper的接口方法MyBatis把接口方法和XML里的SQL映射起来执行最后把查询结果逐层返回。这中间有两个细节值得展开。第一个是分页商品列表一定要做分页否则数据库里商品一多整个页面就卡死。SSM项目最常用的分页方案是PageHelper插件使用非常简单// Service层只需一行代码启动分页 PageHelper.startPage(pageNum, pageSize); ListGoods goodsList goodsMapper.selectGoodsByCondition(categoryId, keyword, orderBy); PageInfoGoods pageInfo new PageInfo(goodsList);通过PageHelper.startPage设置页码和每页条数紧接着的第一条查询语句会自动拼接LIMIT语句PageInfo对象里封装了总记录数、总页数等分页参数前端拿到这个对象就能渲染页码栏。第二个细节是搜索时的模糊查询。GoodsMapper.xml里的SQL写法要小心空值判断不能简单拼一个WHERE g.name LIKE CONCAT(%, #{keyword}, %)否则关键词为空时会把所有商品筛出来。正确做法是使用if标签动态拼接条件这也是MyBatis一个很好用的特性。select idselectGoodsByCondition resultTypeGoods SELECT * FROM goods where if testcategoryId ! null AND category_id #{categoryId} /if if testkeyword ! null and keyword ! AND (name LIKE CONCAT(%, #{keyword}, %) OR subtitle LIKE CONCAT(%, #{keyword}, %)) /if AND status 1 /where ORDER BY choose when testorderBy salessales DESC/when when testorderBy priceAscprice ASC/when when testorderBy priceDescprice DESC/when otherwisecreate_time DESC/otherwise /choose /selectwhere标签会很智能地处理多个条件之间的AND连接没有条件时它会自动去掉WHERE关键字。choose就相当于Java里的switch用于排序方式切换。这些小技巧掌握后写Mapper的效率会高很多。3.2 购物车选型Session购物车还是数据库购物车购物车是个很有意思的模块因为可以有两种截然不同的实现方案。第一种用Session存购物车用户不登录也能加购物车实现简单但换浏览器数据就没了第二种用数据库存购物车数据持久化和用户强绑定用户登录后在任何设备上都能看到同一份购物车数据。我选的是数据库方案核心原因是课设系统的购物车数据量非常小几百上千条记录对MySQL来说毫无压力但数据库方案带来的用户体验提升和架构清晰度是Session方案比不了的。而且从答辩角度讲“用MySQL存购物车保证用户跨设备数据同步”明显比“购物车保存在服务器Session中”更有说头。数据库购物车的关键操作有两个。第一个是加购因为表上有(user_id, goods_id)联合唯一索引所以可以很优雅地实现“存在则数量累加不存在则新插入”的逻辑。public void addToCart(Integer userId, Integer goodsId, Integer quantity) { Cart cart cartMapper.selectByUserIdAndGoodsId(userId, goodsId); if (cart ! null) { // 商品已在购物车数量累加 cartMapper.increaseQuantity(cart.getId(), quantity); } else { // 商品不在购物车新插入一条 Cart newCart new Cart(); newCart.setUserId(userId); newCart.setGoodsId(goodsId); newCart.setQuantity(quantity); cartMapper.insertSelective(newCart); } }这里有个实际操作中容易踩到的坑加购前要判断商品状态是否上架、库存是否充足。如果商品已下架还允许加购用户结算时只会得到一堆报错体验很糟糕。我习惯加购时顺手查一次商品状态下架商品直接提示“商品已下架”不给用户留到结算时才发现买不了的尴尬。第二个是购物车结算也就是把购物车里选中的商品变成订单的过程。这一步是事务操作的核心不能只做插入订单表一件事还需要同步扣减购物车记录、扣减库存、增加销量三个动作任何一个失败都要整体回滚。因此在Service层的这个方法上必须加上Transactional注解。Transactional(rollbackFor Exception.class) public OrderMaster checkout(Integer userId, ListInteger cartIds) { // 1. 根据cartIds查询购物车记录关联查询商品信息 // 2. 校验商品是否上架、库存是否充足 // 3. 计算订单总金额 // 4. 生成订单主表记录 // 5. 生成订单明细记录 // 6. 扣减库存、增加销量 // 7. 删除对应购物车记录 }关于事务多说一句。很多人写SSM项目时在Controller层直接调用多个Mapper方法完全没有事务边界结果下单时订单表插进去了库存却因为异常没扣到数据对不上真的很头疼。正确做法一定是所有涉及写操作的核心链路都放到Service层管理并使用Transactional声明事务边界。这个习惯一定要养成。3.3 下单扣库存并发场景下如何避免“超卖”超卖是电商项目里最经典的问题也是课设答辩时老师最喜欢问的一个点。场景是商品库存只剩5件但有10个用户同时下单每个用户都先查询到库存是5都认为库存足够结果10个订单全部生成成功库存却变成负数。很多人第一次写这个逻辑时代码是这样的// 错误示范先查库存再扣减 Goods goods goodsMapper.selectById(goodsId); if (goods.getStock() quantity) { throw new RuntimeException(库存不足); } goodsMapper.decreaseStock(goodsId, quantity);这种写法在并发量低的时候没问题但稍微有一点并发就会超卖。因为多个线程同时读到库存为5都通过了if判断再一起执行decreaseStock库存直接被扣成了负数。正确的做法是把判断和扣减做成一个原子操作在SQL层面直接完成条件更新UPDATE goods SET stock stock - #{quantity}, sales sales #{quantity} WHERE id #{goodsId} AND stock #{quantity}这样扣减库存时如果库存不足受影响行数为0程序通过判断受影响行数就知道库存不足直接抛出异常让事务回滚。这个操作同时完成了扣库存和加销量效率也更高。对应Service代码int rows goodsMapper.deductStock(goodsId, quantity); if (rows 0) { throw new RuntimeException(库存不足); }当然这个方案还不能解决极端高并发下的性能问题真正的秒杀系统会引入Redis预扣库存、消息队列异步下单等机制但放在一个课设系统里“SQL条件更新事务回滚”已经是一个足够标准且能讲清楚的并发控制方案。面试时能把这条链路讲清楚比你背一堆分布式理论有用得多。3.4 模拟支付为什么不做真实支付真实接入微信支付或支付宝支付需要企业资质、商户号、应用证书个人开发者很难搞定而且课设项目也不需要真的收款。所以这里做一个“模拟支付”用户在前台点击“立即支付”后端把订单状态从待支付改成已支付记录支付时间。虽然只是模拟订单状态机的流转逻辑还是要写清楚。我习惯把支付逻辑单独放在一个PayService里而不是散落在订单Service中这样后面如果真要接入真实支付只需要替换这个Service的实现类。public void pay(Integer userId, String orderNo) { OrderMaster order orderMapper.selectByOrderNo(orderNo); if (order null) { throw new RuntimeException(订单不存在); } // 校验订单归属 if (!order.getUserId().equals(userId)) { throw new RuntimeException(无权操作该订单); } // 状态机校验 if (order.getStatus() ! OrderStatusEnum.WAIT_PAY.getCode()) { throw new RuntimeException(订单状态异常无法支付); } // 更新状态 orderMapper.updateStatus(order.getId(), OrderStatusEnum.PAID.getCode(), new Date()); }这里又一次用到了状态机校验只有“待支付”状态的订单才可以支付这个判断是必须的。我之前见过一个项目用户把一个已经取消的订单拿来支付因为缺少状态校验成功改了状态导致整个状态流完全乱套。任何状态流转操作前都必须校验当前状态这是电商系统状态机设计的铁律。4. 后台管理端与文件上传的处理细节4.1 登录拦截器如何实现简单的权限控制后台管理端必须做权限控制不然任何人都能直接访问/admin/goods/list来管理商品那这个后台管理就形同虚设。SSM项目里做登录拦截最标准的做法是使用SpringMVC的HandlerInterceptor。先写一个拦截器类实现HandlerInterceptor接口在preHandle方法里判断session里有没有管理员信息如果没有就重定向到登录页public class AdminInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { User admin (User) request.getSession().getAttribute(admin); if (admin null) { response.sendRedirect(request.getContextPath() /admin/login); return false; } return true; } }然后在spring-mvc.xml里注册这个拦截器并配置拦截和排除拦截的路径mvc:interceptors mvc:interceptor mvc:mapping path/admin/**/ mvc:exclude-mapping path/admin/login/ mvc:exclude-mapping path/admin/loginSubmit/ mvc:exclude-mapping path/admin/css/**/ mvc:exclude-mapping path/admin/js/**/ mvc:exclude-mapping path/admin/images/**/ mvc:bean classcom.example.interceptor.AdminInterceptor/ /mvc:interceptor /mvc:interceptors这里还要处理一个很细节的问题静态资源放行。CSS、JS、图片这些文件如果被拦截后台登录页样式就全挂了。/admin/css/**这类路径的排除配置不能漏掉。另外如果项目用了前端框架的JS文件也要确保对应的路径放行。用户端的拦截器也类似拦截/cart/**、/order/**、/user/**等路径判断session里有没有登录用户没有就踢到登录页。前后台共用的是同一套用户表只是角色字段不同前台user端和管理员登录后存到session的key要区分清楚避免混淆。4.2 商品图片上传存数据库还是存磁盘商品图片上传是后台管理里一个比较麻烦的模块。我见过有些项目图省事直接把图片转成Base64字符串存进数据库字段一个几百KB的图片变成几十万字符的字符串数据库瞬间膨胀查询性能也受拖累。这种做法只适合存头像这类小图商品图不建议。正确的方案是图片上传后存到服务器的磁盘目录数据库里只存图片的相对路径。比如把图片存到项目的/upload/goods/目录数据库image字段存/upload/goods/20250115_123456.jpg前端img标签直接把这个相对路径拼上项目根路径就能显示。使用SpringMVC处理上传时核心代码比较简单MultipartFile对象封装了上传文件的所有信息。但有几个安全细节需要特别注意。文件名校验和统一规划。不能直接使用用户上传的原始文件名因为可能存在中文、特殊字符、路径穿越等问题。我习惯用UUID.randomUUID()生成新文件名保留原文件后缀再拼上日期目录这样既避免重名也便于按日期归档。// 生成存储文件名UUID 原后缀 String originalFilename file.getOriginalFilename(); String ext originalFilename.substring(originalFilename.lastIndexOf(.)); String fileName UUID.randomUUID().toString().replace(-, ) ext; // 按日期分子目录 String dateDir new SimpleDateFormat(yyyyMMdd).format(new Date()); String relativePath /upload/goods/ dateDir / fileName; String realPath uploadRootDir relativePath; File dest new File(realPath); if (!dest.getParentFile().exists()) { dest.getParentFile().mkdirs(); } file.transferTo(dest);后缀白名单检查。只允许jpg、jpeg、png、gif、webp这些图片格式其他一律拒绝。上传文件大小也要做限制通常在spring-mvc.xml里配置multipartResolver时指定上限比如5MB。bean idmultipartResolver classorg.springframework.web.multipart.commons.CommonsMultipartResolver property namemaxUploadSize value5242880/ property namedefaultEncoding valueUTF-8/ /bean最后是部署路径问题。很多同学在自己电脑上把图片写到E:/upload/代码里写绝对路径结果部署到服务器后图片全挂。更合理的做法是把上传根目录做成可配置项通过properties文件定义部署时改配置即可不要硬编码。# application.properties upload.root.dir/data/upload本地跑时配置成你自己的目录部署时改成服务器路径这样项目换环境不用改代码。4.3 后台数据统计几个SQL搞定的核心指标后台首页通常要显示几个关键数据商品总数、用户总数、订单总数、今日销售额。这些数据没有太多技术难点核心就是几行SQL但在意境上这个模块很能提升系统完整度。今日销售额的SQL很典型SELECT IFNULL(SUM(total_amount), 0) AS today_sales FROM order_master WHERE status IN (1, 2, 3) AND pay_time CURDATE()这里有个容易出错的地方销售额只统计已支付的订单待支付订单不算在销售额里。pay_time CURDATE()是取今天零点以后的支付记录如果要统计的是“近7天销售额”就改成pay_time DATE_SUB(CURDATE(), INTERVAL 7 DAY)。除了数字指标我建议再加一个“近7天订单趋势”的折线图用ECharts在前端展示。后端返回一个包含日期和订单数的列表SELECT DATE(pay_time) AS d, COUNT(*) AS cnt FROM order_master WHERE status IN (1, 2, 3) AND pay_time DATE_SUB(CURDATE(), INTERVAL 7 DAY) GROUP BY DATE(pay_time) ORDER BY d前端用Ajax请求这个数据再用ECharts渲染成折线图整个后台首页瞬间就有“管理系统”的感觉了。ECharts图表的引入方式也很简单在JSP页面引入echarts.min.js写一个div容器然后init生成图表即可。5. 常见问题与排查技巧实录5.1 项目启动阶段最容易遇到的三个报错SSM项目最让人崩溃的往往不是业务代码而是环境搭建阶段的一堆配置问题。下面这三个报错基本每个做SSM的人都会遇到我把排查思路整理成一张速查表。报错现象根本原因排查与解决Tomcat启动后访问404项目没有正确部署到webapps或者访问路径不对检查IDEA中Artifacts配置确认web.xml里的欢迎页面路径确认URL是否带了项目上下文路径启动时报ClassNotFoundExceptionMaven依赖缺失或包冲突检查pom.xml依赖执行mvn clean install重新导入重点检查Spring相关包版本是否一致数据库连接超时或Access denied数据库配置错误、权限不足检查jdbc.properties连接串、用户名、密码如果MySQL 8.x还要检查驱动是否匹配连接串是否配置了serverTimezoneAsia/Shanghai额外说一个很隐蔽但经常犯的错误jdbc.properties里的连接串写成jdbc:mysql://localhost:3306/mall?serverTimezoneUTC但MySQL服务端时区比UTC早8小时插入时间字段时就会出现“显示时间比当前时间早8小时”的尴尬。解决方案是统一设置serverTimezoneAsia/Shanghai或者在MySQL连接URL里直接加useSSLfalsecharacterEncodingutf8。5.2 MyBatis的Mapper文件“失灵”怎么办Mapper接口定义了方法但执行时却提示Invalid bound statement (not found)。这个问题90%的原因都是Mapper XML文件和Mapper接口没有正确绑定。排查思路按顺序来先确认XML文件是否在resources目录下并且目录结构和接口的包路径一致。比如接口是com.example.mapper.GoodsMapper那XML文件的namespace也必须是com.example.mapper.GoodsMapper且XML文件路径通常放在com/example/mapper/下面。然后用到了MyBatis的Mapper扫描配置在spring-mybatis.xml里配置mapper-scanner或者MapperScannerConfigurer让它能扫描到接口。我再提供一个小技巧在Mapper接口方法上添加Options(useGeneratedKeys true, keyProperty id)这样插入数据后就能直接获取自增主键。详情开发时经常需要拿到新插入记录的ID这个配置能省一次额外查询。 ### 5.3 联调时如何快速定位问题 项目前后端联调时遇到问题不要急着改代码先养成“分层定位”的思维方式。 第一步是确认请求是否到达后端。在Controller方法第一行打印日志或者断点如果没进来问题多半出在URL路径或参数绑定上。第二步确认SQL执行情况。在mybatis-config.xml里开启日志 xml settings setting namelogImpl valueSTDOUT_LOGGING/ /settings这样MyBatis会把执行的SQL和参数打到控制台你一眼就能看出SQL拼接得对不对。第三步是检查返回结果。如果SQL正确但结果不对多半是映射问题比如数据库字段是create_timeJava属性是createTime要么开启MyBatis的驼峰映射要么在SQL里用别名二选一即可。开启驼峰映射的配置settings setting namemapUnderscoreToCamelCase valuetrue/ /settings这行配置能让MyBatis自动把数据库的create_time映射到Java的createTime属性能省掉大量手写resultMap的样板代码。6. 从课设项目到面试项目的升级思路这个系统做到这里已经是一个功能完整、结构清晰的SSM电商项目了。但如果你希望它不只是交个作业而是变成面试时能拿得出手的项目经历我建议你在这几个方向上稍微升级一下。第一个是缓存。商品列表和详情是读取频率最高的接口你可以引入Redis做缓存缓存商品的列表数据或热门商品数据。不用做得多复杂核心接口加一层缓存面试时就能讲出“我通过Redis缓存降低了数据库压力”这句话。第二个是接口参数校验。现在项目里Controller层参数基本靠手动判断非常繁琐。可以引入Hibernate Validator在实体类字段上加NotNull、Min等注解代码简洁而且更正规。第三个是日志记录。给关键操作下单、支付、发货增加操作日志比如用Log注解配合AOP统一记录用户操作这样系统不再是一个“黑盒”出问题了也能追溯。不过话说回来课程设计项目的边界是有限的你不需要把所有企业级技术都堆进去。一个SSM项目真正值钱的不是用了多少个框架而是你在做的时候踩过多少坑对业务逻辑的理解有多深。把这个果蔬商城的购物车、订单、库存链路吃透再去学SpringBoot、Redis、消息队列你会发现一切都是相通的。我这个项目从Spring、SpringMVC、MyBatis手动装配开始到后台权限拦截、商品上传、模拟支付再到并发扣库存一路写下来最大的体会就是SSM项目最宝贵的不是能跑起来而是你能讲清楚每个请求进来之后发生了什么事每个业务操作背后的数据是怎么流转的。这份理解才是做项目真正的收获。
SSM果蔬商城系统：从数据建模到订单支付的完整实践
做Java后端的人对SSM这三个字母肯定不会陌生。这个项目标题“基于SSM的水果蔬菜商城系统_812llq05”一眼能看出是典型的Java Web课程设计/毕业设计项目核心是Spring SpringMVC MyBatis三件套组合的电商系统。市面上的商城项目多如牛毛但果蔬生鲜这个品类其实比普通的图书、数码商城更有意思因为它天然带库存、保质期、配送状态这些真实业务约束做起来不会只是个“玩具项目”。这篇内容我不打算只贴功能列表而是把这个项目从数据建模、后台管理、购物车、下单扣库存到后台权限、图片上传等完整链路拆开讲清楚。无论你是要自己动手写一个交作业还是拿别人的源码来跑通然后做二次开发这篇都能给你一条能落地的路线。1. 项目整体设计与技术选型思路1.1 果蔬商城这种选题到底在考核什么很多同学选系统做课设的时候喜欢挑“学生管理系统”“图书管理系统”这种平平无奇的题目结果答辩时老师问一句“你这个系统有什么难点”半天答不上来。果蔬商城不一样它的业务链路比普通信息管理系统长得多从用户注册登录、浏览商品、加购物车到生成订单、模拟支付、后台发货再到库存扣减和统计报表整条链路走完基本覆盖了一个Web系统最常见的业务场景。而且果蔬生鲜有个特点库存变动频繁、订单状态多。今天土豆到货50斤卖出去30斤你需要在系统里实时扣减用户下单后不付款你要在超时后取消订单后台管理员发货后用户端状态要跟着变。这些逻辑加在一起系统必须具备清晰的状态机设计和严谨的事务处理这恰好是SSM项目最能体现“含金量”的地方。1.2 功能模块怎么拆前后台各自管什么我在规划这个系统时没有把它做成一个单一大模块而是按“前台用户端”和“后台管理端”两个子域来拆这是电商系统很常见的做法也是后期扩展和分工的基础。前台用户端包含四块核心功能用户模块注册、登录、个人信息维护、收货地址管理商品模块商品列表展示、按分类筛选、关键词搜索、商品详情查看购物车模块加入购物车、修改数量、删除、批量结算订单模块提交订单、模拟支付、订单列表、订单详情、取消订单后台管理端包含三块核心功能商品管理商品CRUD、上下架、库存调整、图片上传订单管理订单列表、订单详情、发货操作、订单状态修改数据统计商品数量、订单数、销售额、用户数等核心指标这样拆的好处是前后台的功能边界很清晰代码分包的时候也能严格遵循前台访问/user/**、/cart/**、/order/**后台访问/admin/**后面做登录拦截、权限控制时直接按URL前缀来划分非常方便。1.3 为什么选SSM而不是SpringBoot这个问题基本是答辩必问我自己也经常被学员问“老师现在企业都用SpringBoot为什么课设还要用SSM”。我的回答是课设的目的不是追赶技术潮流而是让你理解Web开发的底层协作流程。SSM三个组件各管一摊Spring负责管理对象Service、DAO这些Bean的创建和依赖注入SpringMVC负责接收HTTP请求并把请求参数绑定到Java对象上MyBatis负责Java对象和数据库记录之间的映射。三者是分工协作的关系而不是重复造轮子。你在SSM项目里手动配置web.xml、spring-mvc.xml、spring-mybatis.xml时会真切感受到“原来一个请求从URL到数据库中间要经过这么多层次的转手”。理解了这套流程后面学SpringBoot就只是一层封装的问题本质没变。当然如果指导老师允许你完全可以把MyBatis换成MyBatis-Plus来减少样板代码或者提前配置好通用Mapper这些都是优化选项不改变SSM这个框架组合的本质。2. 数据模型与核心表结构设计2.1 商品、分类、用户、购物车这几张关键表怎么建数据库设计是整个系统最不能偷懒的环节。表结构设计得好后面的Mapper写起来就顺业务代码也少很多恶心的判断。下面是这个果蔬商城项目中最核心的四张表SQL直接按照这个建库思路来。用户表是系统的基础表包含用户身份信息和默认收货信息。这里要注意密码字段不能存明文至少要存MD5或SHA-256加密后的值。很多课设项目直接明文存密码答辩时被老师点一下就很尴尬。系统提供一个收货地址字段就够完整的地址簿功能可以留作扩展。CREATE TABLE user ( id int(11) NOT NULL AUTO_INCREMENT COMMENT 用户ID, username varchar(50) NOT NULL COMMENT 用户名, password varchar(64) NOT NULL COMMENT 密码(MD5加密), phone varchar(20) DEFAULT NULL COMMENT 手机号, address varchar(200) DEFAULT NULL COMMENT 收货地址, role tinyint(4) DEFAULT 0 COMMENT 角色 0-普通用户 1-管理员, create_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT 注册时间, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;商品信息表是商城系统的核心资产。对于果蔬类商品我特别加了一个unit字段用来表示计量单位斤、盒、份等这个字段看着不起眼但在前台展示和下单计算时非常关键没有它就会出现“用户买了个苹果不知道是一斤还是一个”的困惑。CREATE TABLE goods ( id int(11) NOT NULL AUTO_INCREMENT COMMENT 商品ID, category_id int(11) NOT NULL COMMENT 分类ID, name varchar(100) NOT NULL COMMENT 商品名称, subtitle varchar(200) DEFAULT NULL COMMENT 副标题, price decimal(10,2) NOT NULL COMMENT 单价, unit varchar(20) DEFAULT 斤 COMMENT 计量单位, stock int(11) NOT NULL DEFAULT 0 COMMENT 库存, sales int(11) NOT NULL DEFAULT 0 COMMENT 销量, image varchar(255) DEFAULT NULL COMMENT 商品图片路径, description text COMMENT 商品详情, status tinyint(4) DEFAULT 1 COMMENT 状态 1-上架 0-下架, create_time datetime DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, PRIMARY KEY (id), KEY idx_category (category_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;分类表就很简单但它是商品模块的一个基础维度。前台导航、后台商品管理、筛选功能都依赖它。设计时给它加一个sort字段可以控制前台分类的展示顺序。CREATE TABLE category ( id int(11) NOT NULL AUTO_INCREMENT, name varchar(50) NOT NULL, sort int(11) DEFAULT 0, PRIMARY KEY (id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;购物车表我选择了数据库存储方案而不是Session购物车后面第3章我会详细解释这么选的考量。这张表本质是用户和商品的关联表额外记录数量再加一个创建时间去重。CREATE TABLE cart ( id int(11) NOT NULL AUTO_INCREMENT, user_id int(11) NOT NULL, goods_id int(11) NOT NULL, quantity int(11) NOT NULL DEFAULT 1, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_user_goods (user_id, goods_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;注意这张表有个非常关键的点user_id和goods_id加了一个联合唯一索引。这意味着同一用户往购物车加同一个商品时数据库层面就保证只有一条记录我们只需要做数量累加不会出现两条重复记录。这个设计能免掉很多非必要的查询判断。2.2 订单主表、订单明细表为什么要拆开订单模块是电商系统里最重要的部分也是最容易被课设项目做糊弄的部分。很多人图省事直接在订单表里存商品名称和价格一张表走天下。这样做的后果是一旦用户在一个订单里买了多个商品数据就变得非常难以处理。更合理的方案是拆成两张表订单主表和订单明细表。订单主表存储订单的整体信息包括订单号、用户ID、订单总金额、收货信息、订单状态等。订单号我推荐用时间戳加随机数的组合格式类似20250115103812001保证唯一即可不一定非要搞一套复杂雪花算法。CREATE TABLE order_master ( id int(11) NOT NULL AUTO_INCREMENT, order_no varchar(64) NOT NULL COMMENT 订单号, user_id int(11) NOT NULL, total_amount decimal(10,2) NOT NULL COMMENT 订单总金额, receiver_name varchar(50) DEFAULT NULL, receiver_phone varchar(20) DEFAULT NULL, receiver_address varchar(200) DEFAULT NULL, status tinyint(4) NOT NULL DEFAULT 0 COMMENT 0待支付 1已支付 2已发货 3已完成 4已取消, pay_time datetime DEFAULT NULL, create_time datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;订单明细表存储订单里每个商品的快照信息。快照这个词很关键下单时把商品名称、单价、图片都拷贝一份到这个表里后面哪怕后台把商品改价、删除历史订单依然能完整显示当时买了什么、花了多少钱。这种设计在真实电商系统里是标配放在课设项目里就是一个很亮眼的细节。CREATE TABLE order_item ( id int(11) NOT NULL AUTO_INCREMENT, order_id int(11) NOT NULL, goods_id int(11) NOT NULL, goods_name varchar(100) NOT NULL, goods_image varchar(255) DEFAULT NULL, price decimal(10,2) NOT NULL COMMENT 下单时单价, quantity int(11) NOT NULL, total_price decimal(10,2) NOT NULL, PRIMARY KEY (id), KEY idx_order (order_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;这里特别提醒一个容易被忽略的坑order_master里的total_amount应该等于明细表中total_price的总和。实现方式最好是在Service层循环计算二选一但不要一处用前台传入的值、一处用数据库查出来的值前后对不上。我曾经见过一个项目因为前台下单时把商品总金额和商品明细传给后端后端图省事直接把前台传的total存进表里结果用户篡改请求参数就能把订单金额改成一分钱。正确做法是后端拿商品单价和数量重新计算下单金额前台的金额只作展示用不作存储依据。2.3 订单状态流转用数字还是字符串订单status字段我建议直接用一个tinyint数字来标识而不是存“待支付”“已支付”这样的中文。原因有两个一是数字存储更省空间查询效率更高二是状态机在代码里用数字判断更清晰不容易被数据库里的中文脏数据干扰。这个系统的订单状态流转我设计成一条单链各种状态对应如下状态值含义可流转到0待支付已支付、已取消1已支付已发货、已取消2已发货已完成3已完成终止4已取消终止在代码里写状态流转判断时最推荐的做法是使用常量类或枚举来定义这些状态而不是散落在业务代码里的魔法数字。比如定义一个OrderStatusEnum代码可读性瞬间提升一个档次。public enum OrderStatusEnum { WAIT_PAY(0, 待支付), PAID(1, 已支付), SHIPPED(2, 已发货), FINISHED(3, 已完成), CANCELLED(4, 已取消); private int code; private String desc; OrderStatusEnum(int code, String desc) { this.code code; this.desc desc; } public int getCode() { return code; } public String getDesc() { return desc; } }有了这个枚举前端渲染订单状态时就直接拿OrderStatusEnum转成中文描述后端业务里判断状态也不会出现“这个3到底是我定义的第3个状态还是什么其他含义”的情况。3. 核心业务链路实操从商品浏览到下单支付3.1 商品列表与搜索Controller到Mapper的一条完整调用链拿商品列表这个功能来说整个请求路径是这样的浏览器发起HTTP GET请求到/goods/list?categoryId1keyword苹果SpringMVC的DispatcherServlet把请求交给GoodsControllerController调用GoodsServiceService调用GoodsMapper的接口方法MyBatis把接口方法和XML里的SQL映射起来执行最后把查询结果逐层返回。这中间有两个细节值得展开。第一个是分页商品列表一定要做分页否则数据库里商品一多整个页面就卡死。SSM项目最常用的分页方案是PageHelper插件使用非常简单// Service层只需一行代码启动分页 PageHelper.startPage(pageNum, pageSize); ListGoods goodsList goodsMapper.selectGoodsByCondition(categoryId, keyword, orderBy); PageInfoGoods pageInfo new PageInfo(goodsList);通过PageHelper.startPage设置页码和每页条数紧接着的第一条查询语句会自动拼接LIMIT语句PageInfo对象里封装了总记录数、总页数等分页参数前端拿到这个对象就能渲染页码栏。第二个细节是搜索时的模糊查询。GoodsMapper.xml里的SQL写法要小心空值判断不能简单拼一个WHERE g.name LIKE CONCAT(%, #{keyword}, %)否则关键词为空时会把所有商品筛出来。正确做法是使用if标签动态拼接条件这也是MyBatis一个很好用的特性。select idselectGoodsByCondition resultTypeGoods SELECT * FROM goods where if testcategoryId ! null AND category_id #{categoryId} /if if testkeyword ! null and keyword ! AND (name LIKE CONCAT(%, #{keyword}, %) OR subtitle LIKE CONCAT(%, #{keyword}, %)) /if AND status 1 /where ORDER BY choose when testorderBy salessales DESC/when when testorderBy priceAscprice ASC/when when testorderBy priceDescprice DESC/when otherwisecreate_time DESC/otherwise /choose /selectwhere标签会很智能地处理多个条件之间的AND连接没有条件时它会自动去掉WHERE关键字。choose就相当于Java里的switch用于排序方式切换。这些小技巧掌握后写Mapper的效率会高很多。3.2 购物车选型Session购物车还是数据库购物车购物车是个很有意思的模块因为可以有两种截然不同的实现方案。第一种用Session存购物车用户不登录也能加购物车实现简单但换浏览器数据就没了第二种用数据库存购物车数据持久化和用户强绑定用户登录后在任何设备上都能看到同一份购物车数据。我选的是数据库方案核心原因是课设系统的购物车数据量非常小几百上千条记录对MySQL来说毫无压力但数据库方案带来的用户体验提升和架构清晰度是Session方案比不了的。而且从答辩角度讲“用MySQL存购物车保证用户跨设备数据同步”明显比“购物车保存在服务器Session中”更有说头。数据库购物车的关键操作有两个。第一个是加购因为表上有(user_id, goods_id)联合唯一索引所以可以很优雅地实现“存在则数量累加不存在则新插入”的逻辑。public void addToCart(Integer userId, Integer goodsId, Integer quantity) { Cart cart cartMapper.selectByUserIdAndGoodsId(userId, goodsId); if (cart ! null) { // 商品已在购物车数量累加 cartMapper.increaseQuantity(cart.getId(), quantity); } else { // 商品不在购物车新插入一条 Cart newCart new Cart(); newCart.setUserId(userId); newCart.setGoodsId(goodsId); newCart.setQuantity(quantity); cartMapper.insertSelective(newCart); } }这里有个实际操作中容易踩到的坑加购前要判断商品状态是否上架、库存是否充足。如果商品已下架还允许加购用户结算时只会得到一堆报错体验很糟糕。我习惯加购时顺手查一次商品状态下架商品直接提示“商品已下架”不给用户留到结算时才发现买不了的尴尬。第二个是购物车结算也就是把购物车里选中的商品变成订单的过程。这一步是事务操作的核心不能只做插入订单表一件事还需要同步扣减购物车记录、扣减库存、增加销量三个动作任何一个失败都要整体回滚。因此在Service层的这个方法上必须加上Transactional注解。Transactional(rollbackFor Exception.class) public OrderMaster checkout(Integer userId, ListInteger cartIds) { // 1. 根据cartIds查询购物车记录关联查询商品信息 // 2. 校验商品是否上架、库存是否充足 // 3. 计算订单总金额 // 4. 生成订单主表记录 // 5. 生成订单明细记录 // 6. 扣减库存、增加销量 // 7. 删除对应购物车记录 }关于事务多说一句。很多人写SSM项目时在Controller层直接调用多个Mapper方法完全没有事务边界结果下单时订单表插进去了库存却因为异常没扣到数据对不上真的很头疼。正确做法一定是所有涉及写操作的核心链路都放到Service层管理并使用Transactional声明事务边界。这个习惯一定要养成。3.3 下单扣库存并发场景下如何避免“超卖”超卖是电商项目里最经典的问题也是课设答辩时老师最喜欢问的一个点。场景是商品库存只剩5件但有10个用户同时下单每个用户都先查询到库存是5都认为库存足够结果10个订单全部生成成功库存却变成负数。很多人第一次写这个逻辑时代码是这样的// 错误示范先查库存再扣减 Goods goods goodsMapper.selectById(goodsId); if (goods.getStock() quantity) { throw new RuntimeException(库存不足); } goodsMapper.decreaseStock(goodsId, quantity);这种写法在并发量低的时候没问题但稍微有一点并发就会超卖。因为多个线程同时读到库存为5都通过了if判断再一起执行decreaseStock库存直接被扣成了负数。正确的做法是把判断和扣减做成一个原子操作在SQL层面直接完成条件更新UPDATE goods SET stock stock - #{quantity}, sales sales #{quantity} WHERE id #{goodsId} AND stock #{quantity}这样扣减库存时如果库存不足受影响行数为0程序通过判断受影响行数就知道库存不足直接抛出异常让事务回滚。这个操作同时完成了扣库存和加销量效率也更高。对应Service代码int rows goodsMapper.deductStock(goodsId, quantity); if (rows 0) { throw new RuntimeException(库存不足); }当然这个方案还不能解决极端高并发下的性能问题真正的秒杀系统会引入Redis预扣库存、消息队列异步下单等机制但放在一个课设系统里“SQL条件更新事务回滚”已经是一个足够标准且能讲清楚的并发控制方案。面试时能把这条链路讲清楚比你背一堆分布式理论有用得多。3.4 模拟支付为什么不做真实支付真实接入微信支付或支付宝支付需要企业资质、商户号、应用证书个人开发者很难搞定而且课设项目也不需要真的收款。所以这里做一个“模拟支付”用户在前台点击“立即支付”后端把订单状态从待支付改成已支付记录支付时间。虽然只是模拟订单状态机的流转逻辑还是要写清楚。我习惯把支付逻辑单独放在一个PayService里而不是散落在订单Service中这样后面如果真要接入真实支付只需要替换这个Service的实现类。public void pay(Integer userId, String orderNo) { OrderMaster order orderMapper.selectByOrderNo(orderNo); if (order null) { throw new RuntimeException(订单不存在); } // 校验订单归属 if (!order.getUserId().equals(userId)) { throw new RuntimeException(无权操作该订单); } // 状态机校验 if (order.getStatus() ! OrderStatusEnum.WAIT_PAY.getCode()) { throw new RuntimeException(订单状态异常无法支付); } // 更新状态 orderMapper.updateStatus(order.getId(), OrderStatusEnum.PAID.getCode(), new Date()); }这里又一次用到了状态机校验只有“待支付”状态的订单才可以支付这个判断是必须的。我之前见过一个项目用户把一个已经取消的订单拿来支付因为缺少状态校验成功改了状态导致整个状态流完全乱套。任何状态流转操作前都必须校验当前状态这是电商系统状态机设计的铁律。4. 后台管理端与文件上传的处理细节4.1 登录拦截器如何实现简单的权限控制后台管理端必须做权限控制不然任何人都能直接访问/admin/goods/list来管理商品那这个后台管理就形同虚设。SSM项目里做登录拦截最标准的做法是使用SpringMVC的HandlerInterceptor。先写一个拦截器类实现HandlerInterceptor接口在preHandle方法里判断session里有没有管理员信息如果没有就重定向到登录页public class AdminInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { User admin (User) request.getSession().getAttribute(admin); if (admin null) { response.sendRedirect(request.getContextPath() /admin/login); return false; } return true; } }然后在spring-mvc.xml里注册这个拦截器并配置拦截和排除拦截的路径mvc:interceptors mvc:interceptor mvc:mapping path/admin/**/ mvc:exclude-mapping path/admin/login/ mvc:exclude-mapping path/admin/loginSubmit/ mvc:exclude-mapping path/admin/css/**/ mvc:exclude-mapping path/admin/js/**/ mvc:exclude-mapping path/admin/images/**/ mvc:bean classcom.example.interceptor.AdminInterceptor/ /mvc:interceptor /mvc:interceptors这里还要处理一个很细节的问题静态资源放行。CSS、JS、图片这些文件如果被拦截后台登录页样式就全挂了。/admin/css/**这类路径的排除配置不能漏掉。另外如果项目用了前端框架的JS文件也要确保对应的路径放行。用户端的拦截器也类似拦截/cart/**、/order/**、/user/**等路径判断session里有没有登录用户没有就踢到登录页。前后台共用的是同一套用户表只是角色字段不同前台user端和管理员登录后存到session的key要区分清楚避免混淆。4.2 商品图片上传存数据库还是存磁盘商品图片上传是后台管理里一个比较麻烦的模块。我见过有些项目图省事直接把图片转成Base64字符串存进数据库字段一个几百KB的图片变成几十万字符的字符串数据库瞬间膨胀查询性能也受拖累。这种做法只适合存头像这类小图商品图不建议。正确的方案是图片上传后存到服务器的磁盘目录数据库里只存图片的相对路径。比如把图片存到项目的/upload/goods/目录数据库image字段存/upload/goods/20250115_123456.jpg前端img标签直接把这个相对路径拼上项目根路径就能显示。使用SpringMVC处理上传时核心代码比较简单MultipartFile对象封装了上传文件的所有信息。但有几个安全细节需要特别注意。文件名校验和统一规划。不能直接使用用户上传的原始文件名因为可能存在中文、特殊字符、路径穿越等问题。我习惯用UUID.randomUUID()生成新文件名保留原文件后缀再拼上日期目录这样既避免重名也便于按日期归档。// 生成存储文件名UUID 原后缀 String originalFilename file.getOriginalFilename(); String ext originalFilename.substring(originalFilename.lastIndexOf(.)); String fileName UUID.randomUUID().toString().replace(-, ) ext; // 按日期分子目录 String dateDir new SimpleDateFormat(yyyyMMdd).format(new Date()); String relativePath /upload/goods/ dateDir / fileName; String realPath uploadRootDir relativePath; File dest new File(realPath); if (!dest.getParentFile().exists()) { dest.getParentFile().mkdirs(); } file.transferTo(dest);后缀白名单检查。只允许jpg、jpeg、png、gif、webp这些图片格式其他一律拒绝。上传文件大小也要做限制通常在spring-mvc.xml里配置multipartResolver时指定上限比如5MB。bean idmultipartResolver classorg.springframework.web.multipart.commons.CommonsMultipartResolver property namemaxUploadSize value5242880/ property namedefaultEncoding valueUTF-8/ /bean最后是部署路径问题。很多同学在自己电脑上把图片写到E:/upload/代码里写绝对路径结果部署到服务器后图片全挂。更合理的做法是把上传根目录做成可配置项通过properties文件定义部署时改配置即可不要硬编码。# application.properties upload.root.dir/data/upload本地跑时配置成你自己的目录部署时改成服务器路径这样项目换环境不用改代码。4.3 后台数据统计几个SQL搞定的核心指标后台首页通常要显示几个关键数据商品总数、用户总数、订单总数、今日销售额。这些数据没有太多技术难点核心就是几行SQL但在意境上这个模块很能提升系统完整度。今日销售额的SQL很典型SELECT IFNULL(SUM(total_amount), 0) AS today_sales FROM order_master WHERE status IN (1, 2, 3) AND pay_time CURDATE()这里有个容易出错的地方销售额只统计已支付的订单待支付订单不算在销售额里。pay_time CURDATE()是取今天零点以后的支付记录如果要统计的是“近7天销售额”就改成pay_time DATE_SUB(CURDATE(), INTERVAL 7 DAY)。除了数字指标我建议再加一个“近7天订单趋势”的折线图用ECharts在前端展示。后端返回一个包含日期和订单数的列表SELECT DATE(pay_time) AS d, COUNT(*) AS cnt FROM order_master WHERE status IN (1, 2, 3) AND pay_time DATE_SUB(CURDATE(), INTERVAL 7 DAY) GROUP BY DATE(pay_time) ORDER BY d前端用Ajax请求这个数据再用ECharts渲染成折线图整个后台首页瞬间就有“管理系统”的感觉了。ECharts图表的引入方式也很简单在JSP页面引入echarts.min.js写一个div容器然后init生成图表即可。5. 常见问题与排查技巧实录5.1 项目启动阶段最容易遇到的三个报错SSM项目最让人崩溃的往往不是业务代码而是环境搭建阶段的一堆配置问题。下面这三个报错基本每个做SSM的人都会遇到我把排查思路整理成一张速查表。报错现象根本原因排查与解决Tomcat启动后访问404项目没有正确部署到webapps或者访问路径不对检查IDEA中Artifacts配置确认web.xml里的欢迎页面路径确认URL是否带了项目上下文路径启动时报ClassNotFoundExceptionMaven依赖缺失或包冲突检查pom.xml依赖执行mvn clean install重新导入重点检查Spring相关包版本是否一致数据库连接超时或Access denied数据库配置错误、权限不足检查jdbc.properties连接串、用户名、密码如果MySQL 8.x还要检查驱动是否匹配连接串是否配置了serverTimezoneAsia/Shanghai额外说一个很隐蔽但经常犯的错误jdbc.properties里的连接串写成jdbc:mysql://localhost:3306/mall?serverTimezoneUTC但MySQL服务端时区比UTC早8小时插入时间字段时就会出现“显示时间比当前时间早8小时”的尴尬。解决方案是统一设置serverTimezoneAsia/Shanghai或者在MySQL连接URL里直接加useSSLfalsecharacterEncodingutf8。5.2 MyBatis的Mapper文件“失灵”怎么办Mapper接口定义了方法但执行时却提示Invalid bound statement (not found)。这个问题90%的原因都是Mapper XML文件和Mapper接口没有正确绑定。排查思路按顺序来先确认XML文件是否在resources目录下并且目录结构和接口的包路径一致。比如接口是com.example.mapper.GoodsMapper那XML文件的namespace也必须是com.example.mapper.GoodsMapper且XML文件路径通常放在com/example/mapper/下面。然后用到了MyBatis的Mapper扫描配置在spring-mybatis.xml里配置mapper-scanner或者MapperScannerConfigurer让它能扫描到接口。我再提供一个小技巧在Mapper接口方法上添加Options(useGeneratedKeys true, keyProperty id)这样插入数据后就能直接获取自增主键。详情开发时经常需要拿到新插入记录的ID这个配置能省一次额外查询。 ### 5.3 联调时如何快速定位问题 项目前后端联调时遇到问题不要急着改代码先养成“分层定位”的思维方式。 第一步是确认请求是否到达后端。在Controller方法第一行打印日志或者断点如果没进来问题多半出在URL路径或参数绑定上。第二步确认SQL执行情况。在mybatis-config.xml里开启日志 xml settings setting namelogImpl valueSTDOUT_LOGGING/ /settings这样MyBatis会把执行的SQL和参数打到控制台你一眼就能看出SQL拼接得对不对。第三步是检查返回结果。如果SQL正确但结果不对多半是映射问题比如数据库字段是create_timeJava属性是createTime要么开启MyBatis的驼峰映射要么在SQL里用别名二选一即可。开启驼峰映射的配置settings setting namemapUnderscoreToCamelCase valuetrue/ /settings这行配置能让MyBatis自动把数据库的create_time映射到Java的createTime属性能省掉大量手写resultMap的样板代码。6. 从课设项目到面试项目的升级思路这个系统做到这里已经是一个功能完整、结构清晰的SSM电商项目了。但如果你希望它不只是交个作业而是变成面试时能拿得出手的项目经历我建议你在这几个方向上稍微升级一下。第一个是缓存。商品列表和详情是读取频率最高的接口你可以引入Redis做缓存缓存商品的列表数据或热门商品数据。不用做得多复杂核心接口加一层缓存面试时就能讲出“我通过Redis缓存降低了数据库压力”这句话。第二个是接口参数校验。现在项目里Controller层参数基本靠手动判断非常繁琐。可以引入Hibernate Validator在实体类字段上加NotNull、Min等注解代码简洁而且更正规。第三个是日志记录。给关键操作下单、支付、发货增加操作日志比如用Log注解配合AOP统一记录用户操作这样系统不再是一个“黑盒”出问题了也能追溯。不过话说回来课程设计项目的边界是有限的你不需要把所有企业级技术都堆进去。一个SSM项目真正值钱的不是用了多少个框架而是你在做的时候踩过多少坑对业务逻辑的理解有多深。把这个果蔬商城的购物车、订单、库存链路吃透再去学SpringBoot、Redis、消息队列你会发现一切都是相通的。我这个项目从Spring、SpringMVC、MyBatis手动装配开始到后台权限拦截、商品上传、模拟支付再到并发扣库存一路写下来最大的体会就是SSM项目最宝贵的不是能跑起来而是你能讲清楚每个请求进来之后发生了什么事每个业务操作背后的数据是怎么流转的。这份理解才是做项目真正的收获。
