企业官网建设流程全解析

每年到这个时间点，总有一批人被毕设折磨得焦头烂额，尤其是选了Java方向的同学。要么题目太空，不知道从哪动手，要么题目太老，做完自己都没信心写进简历。今天这个宠物用品商城系统，属于那种看着普通、但做过之后才发现信息量很大的题目。它既覆盖了Java后台开发最常见的技术栈，又包含了电商系统里最核心的几条业务链路：用户从注册登录到浏览商品，从加购到下单，再到后台发货处理订单。整套流程走下来，你对"一个Web业务系统是怎么跑起来的"会有一个非常立体的认知。

这篇帖子不是给你贴一堆课程设计报告里那种纸面代码，而是把我自己带毕设、做项目过程中实际踩过的坑、验证过没问题的方案，以及拿到答辩老师面前能有底气讲清楚的设计思路，全部倒出来。适合正在做类似商城系统的毕业生，也适合想快速热身一个完整Java Web项目的在校生。不管你是拿它当毕设，还是准备扩展成面试作品，这篇文章都能给你省不少折腾时间。

1. 项目整体设计与需求拆解

1.1 业务场景与角色定位

宠物用品商城，本质是一个标准化的B2C电商系统，只不过把商品从数码、服饰换成了猫粮、狗窝、玩具、驱虫药这些宠物用品。做之前先想清楚一件事：这个系统里到底有哪几类人用它，每类人关心什么。

用户端是普通消费者，他们要能注册登录、浏览商品分类、搜索商品、看商品详情、加购物车、生成订单、在线付款（或者货到付款）、查看历史订单。这些功能听起来简单，但每个环节都有对应的数据表和接口逻辑，缺一个整个链路就不闭环。

管理端是运营人员，他们要能维护商品分类、上下架商品、调整库存、处理用户订单（发货、取消、退款）、管理轮播图和公告，还要能查看基本的数据统计，比如每日订单量、销售额。管理端做不好，就意味着你没法向老师证明这个系统"是可运营的"，只能算一个展示性Demo。

还有一类角色容易被忽略，就是游客。游客可以浏览商品，但一旦要下单就必须登录。这个设计看似简单，实际涉及整个拦截器体系和登录注册逻辑的边界控制，很多毕设在这块做得含糊，导致游客也能直接访问后台接口，这是严重的权限漏洞。

1.2 功能模块怎么拆才合理

模块拆得好不好，直接决定你后面代码写起来是顺畅还是混乱。我推荐按前台用户操作和后台管理两条线拆，不要按"商品模块、购物车模块"这种平铺方式拆，因为你拆到最后会发现，购物车和订单是高度关联的，单独拆开会很别扭。

标准的功能拆解是这样的：

• 用户模块：注册、登录、退出、个人信息修改、地址管理（收货地址新增、编辑、删除、设为默认）。
• 商品模块：商品分类展示（一级分类、二级分类）、商品列表分页、关键词搜索、商品详情、热门商品推荐。
• 购物车模块：加入购物车、修改购买数量、删除购物车条目、全选/取消全选、汇总结算金额。
• 订单模块：生成订单（从购物车结算或直接购买）、订单确认页（展示地址和商品清单）、支付模拟、订单列表、订单详情、取消订单、确认收货。
• 后台管理模块：管理员登录、商品分类管理、商品管理（增删改查、上下架、设置库存）、订单管理（查看订单、发货、取消）、用户管理（启用/禁用账号）、轮播图管理、公告管理。
• 统计模块：简单图表展示销售统计，按日/周/月汇总订单量和销售额。

这个拆法最大的好处是：每个模块在代码层面都有清晰的Controller、Service、Mapper对应，答辩的时候，老师问到哪个功能，你都能明确告诉他去哪一层找实现。

1.3 页面与接口的映射关系

页面层面建议复用经典的前台商城模板，比如预算猫、宠物之家这类免费HTML模板，改造成JSP或Thymeleaf页面。但这里有一个重要的认知：不要被模板限制你的接口设计。很多人拿到模板后发现页面上有"猜你喜欢"，于是临时加接口，最后接口列表乱七八糟。

正确做法是，先定好页面有哪些交互动作，再定接口。比如首页有轮播图区域、最新商品区域、热门商品区域，那你的接口至少要有getBanners、getNewGoods、getHotGoods。商品列表页有分页和搜索，那接口就是带pageNum、pageSize、keyword参数的商品查询。确定接口时顺便把返回的JSON结构定好，前端页面才能顺利对接。

我是强烈建议前后端分离或者半分离的。即便毕设要求用JSP，你也应该在Controller层只返回JSON数据给Ajax调用，JSP负责静态页面渲染。这样后期如果想把项目升级成Vue前端，只需要重写页面层，业务逻辑完全不用动。

2. 技术选型与架构落地

2.1 为什么这个项目用SSM更合适

现在不少同学一上来就问，为什么不用Spring Boot？这里要把逻辑讲清楚：如果毕设题目明确要求"SSM框架"，那用Spring Boot就是跑题。SSM指的是Spring + Spring MVC + MyBatis的组合，而Spring Boot本身只是对Spring生态的自动化配置封装，它底层还是Spring和Spring MVC。很多学校的课程设计大纲，讲的就是这套经典组合，用Spring Boot反而无法让老师看到你对配置文件、依赖注入、拦截器这类知识点的掌握程度。

这个项目选择SSM还有一个现实层面原因：代码可验证。Spring Boot的自动化配置对新手来说像个"黑盒子"，出了问题不知道去哪里找原因。SSM的配置是显式的，数据源、事务管理器、视图解析器、拦截器全部在XML或者JavaConfig里明明白白，一旦报错你能顺着配置一步步排查。这个排查过程，恰恰是答辩时展现能力的关键场景。

从求职角度讲，很多中小公司的老项目，尤其是金融、政务、传统企业系统，至今跑在SSM上。学会SSM，你去接手这些项目的维护，不会觉得自己是个门外汉。如果直接学Spring Boot，你可能连XML配置都不一定会看，这些项目的维护工作也就与你无缘了。所以不要觉得SSM没用，它是Java Web开发的地基。

2.2 数据库设计与表结构规划

数据库设计是这类项目的灵魂。我见过很多同学，表设计得乱七八糟，比如把订单商品直接拼成一个字符串存进订单表，结果后面做统计时想死的心都有。这个项目的表设计，按下面的方案基本不会翻车。

用户表t_user：主键id、用户名username、密码password（必须用MD5加密存储）、手机号phone、邮箱email、头像avatar、注册时间create_time、状态status（1正常、0禁用）。注意密码不要明文存，哪怕毕设也要有这个意识。

商品分类表t_category：主键id、分类名称name、父分类id parent_id（0表示一级分类）、排序sort、是否删除deleted（逻辑删除，省得物理删数据导致关联断裂）。

商品表t_goods：主键id、商品名称name、副标题subtitle、所属分类category_id、主图main_image、详情图片detail_images（一般用逗号分隔多个图片路径）、价格price（用BigDecimal，避免double精度问题）、原价original_price、库存stock、销量sales、是否上架is_on_sale、创建时间create_time、更新时间update_time。

购物车表t_cart：主键id、用户id user_id、商品id goods_id、商品数量quantity、是否勾选checked（1勾选、0不勾选）、加入时间create_time。在商品和用户之间建立多对多关系，所以需要一张中间表记录两者关联。

订单表t_order：主键id、订单号order_no（用时间戳+随机数生成，唯一且不可预测）、用户id user_id、收货人姓名receiver_name、收货人电话receiver_phone、收货地址receiver_address、订单总金额total_amount、支付方式pay_type（1在线支付、2货到付款）、订单状态status（0待付款、1待发货、2已发货、3已完成、4已取消）、下单时间create_time、支付时间pay_time、发货时间deliver_time。

订单明细表t_order_item：主键id、订单id order_id、商品id goods_id、商品名称goods_name（下单时冗余快照，防止之后商品改名影响历史订单）、商品主图goods_image、商品单价goods_price、购买数量quantity、小计amount。

收货地址表t_address：主键id、用户id user_id、收货人姓名receiver_name、收货人电话receiver_phone、详细地址full_address、是否默认is_default。

轮播图表t_banner：主键id、图片地址image_url、跳转链接link_url、排序sort、是否启用is_active。

这几张表之间的关系非常清楚：商品挂在分类下面，购物车记录用户和商品的关系，订单关联用户和收货地址，订单明细关联订单和商品。回答答辩老师"你这系统有哪些表、表关系是什么"时，这张关系网络就是你的底气。

2.3 项目分层与目录结构

SSM项目一定要严格分层，Controller只管参数接收和前端交互，Service写业务逻辑，Mapper只负责和数据打交道。不要出现Controller里直接调Mapper的写法，那是大忌。

推荐的目录结构是标准的Maven Web项目：

com.example.petstore ├── controller # 前台和后台的控制器 │ ├── admin │ └── portal ├── service # 业务接口 ├── service.impl # 业务实现 ├── mapper # MyBatis的Mapper接口 │ ├── UserMapper.java │ ├── GoodsMapper.java │ └── ... ├── entity # 实体类（对应数据表） ├── dto # 数据传输对象（前端传参） ├── vo # 视图对象（接口返回给前端的数据） ├── interceptor # 拦截器（登录拦截、管理员拦截） ├── config # 配置类（如果有JavaConfig） ├── common # 通用类（统一返回结果、分页工具类） └── resources ├── mapper # MyBatis的XML映射文件 ├── spring # Spring和SpringMVC的配置文件 └── mybatis-config.xml

这个结构的好处是，每组类型都有明确归属，团队协作或者自己维护的时候，找代码不用靠猜。写成这样的项目，在答辩时的第一印象就比十个交乱代码的同学都要好。

3. 核心功能实现与关键代码

3.1 基于拦截器的登录权限控制

商城系统里有一个高频需求：某些页面和接口只有登录用户才能访问。比如购物车、订单结算、个人中心，而首页和商品列表是可以匿名访问的。实现这个需求，拦截器是标准答案。

先定义拦截器类，继承HandlerInterceptorAdapter，并在preHandle里完成一个任务：从session里拿当前登录用户，拿不到就说明未登录，直接重定向到登录页。但注意，用户访问后台管理路径时，不仅要登录，还要校验角色是管理员，所以需要写两个拦截器：一个针对用户端，一个针对admin端。

这里有个坑：如果你在Controller里手动编写校验逻辑，每个方法都要重复写一遍，容易漏。用拦截器可以统一拦截规则，但你得知道怎么放行登录接口本身。不配置排除路径，拦截器会把登录请求也拦住，形成死循环。

正确配置如下（SpringMVC的XML配置或JavaConfig方式都一样）：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); User user = (User) session.getAttribute("loginUser"); if (user == null) { // 判断是否是Ajax请求，Ajax请求要返回JSON错误码 String requestType = request.getHeader("X-Requested-With"); if ("XMLHttpRequest".equals(requestType)) { response.setContentType("application/json;charset=utf-8"); response.getWriter().write(JSON.toJSONString(ResultBean.error("未登录"))); } else { response.sendRedirect("/login"); } return false; } return true; } }

在SpringMVC配置中注册拦截器时：排除登录接口、注册接口、商品列表接口、商品详情接口、图片资源路径，其余全部拦截。这样既确保游客可以逛商城，又保证非法用户进不了购物车和订单页。

3.2 商品搜索与分页功能怎么写才不卡

商品列表页是日常开发中最常见的需求，但十个同学有八个写出来的分页是和数据库一次性查全部数据再在内存中切片。如果数据量只有几百条确实看不出来区别，但答辩时老师问你"如果商品有一万条，你这个方案还稳定吗"，就露馅了。

正确方案是使用MyBatis的PageHelper分页插件。先在Spring配置文件中引入PageHelper的Bean，然后在Service层查询前调用PageHelper.startPage(pageNum, pageSize)，紧接着执行的查询就会自动拼接LIMIT语句，返回的PageInfo对象里包含总记录数、当前页数据列表、总页数等信息，前端拿到后可以直接渲染分页导航。

搜索功能的实现，建议参数都放一个DTO里接收，比如商品名keyword、分类parentId、排序规则sortBy。不建议直接在浏览器地址栏拼多个零散参数，业务一复杂就很难维护。MapperXML里用动态SQL拼接查询条件，比如判断keyword不能为空才追加商品名模糊匹配，判断分类ID不能为空才追加分类过滤。排序规则用ORDER BY加占位符拼接，但这里有一个安全点：排序字段不能手拼，否则会导致SQL注入。要么在代码里做一个字段白名单Map映射，要么只允许传入自定的枚举值。

注意LIKE查询的写法，不要直接LIKE '%#{keyword}%'，这样MyBatis解析会报错或查不到数据。正确的是使用CONCAT('%', #{keyword}, '%')。这个细节，很多教程都没讲透，但实际测试中经常踩这个坑。

3.3 购物车与下单流程的事务控制

购物车模块在代码上难度不大，简单说就是：确认商品ID和数量，查商品是否还在售、库存是否充足，满足条件就插入购物车表。但下单流程就不一样了，它是整个系统里最容易出逻辑漏洞的地方。

我推荐的完整下单流程是这样的：

1. 接收用户提交的地址ID、支付方式，以及购物车中被勾选的商品条目ID列表（或者直接商品ID+数量的数据结构）。
2. 根据用户ID查询所有勾选商品和数量，合并成待结算列表。
3. 遍历待结算列表，逐项查询最新商品信息，校验是否上架、库存是否足够。
4. 如果任一商品库存不足，直接结算失败，并提示具体是哪件商品库存不足。
5. 全部通过后，生成订单号，保存订单主表，再循环插入订单明细表。
6. 将订单明细里所有小计相加，得到总金额，回填订单主表。
7. 减扣每件商品的库存，同时累加销量。
8. 清空购物车中已结算的条目。
9. 如果选择在线支付，跳转到模拟支付页面；等到支付成功回调，再把订单状态更新为待发货。

这9步中间任何一步失败，都不应该产生"订单建了但库存没扣"或者"库存扣了但订单没生成"这种脏数据。解决办法就是给下单方法加@Transactional事务注解，让所有步骤处于同一事务，遇到运行时异常自动回滚。

这里需要特别注意两点：第一，事务只对运行时异常回滚，如果你手动差出异常的话，记得用RuntimeException或显式注解rollbackFor = Exception.class。第二，扣库存时要使用带条件的UPDATE语句，比如UPDATE t_goods SET stock = stock - #{quantity} WHERE id = #{goodsId} AND stock >= #{quantity}，在数据库层面做库存防负数判断。这是应对超卖最简单有效的方案，比在你代码里先查后减要可靠得多。

关于在线支付，毕设里不需要接真实支付平台，接口资质也没法申请。做一个模拟支付页面，展示订单号、金额、支付按钮即可，点击支付后更新订单状态。答辩时讲清楚这个设计是为了模拟正常支付流程，没有真实扣款，老师都能接受。

3.4 后台商品管理与文件上传

后台管理端的商品管理，本质上就是一组CRUD接口：新增商品、编辑商品、删除商品（逻辑删除）、查询商品列表。其中文件上传是个容易被低估的点，因为涉及图片的存储路径和访问映射，做不好会出现"图片能传成功但页面加载不出来"的诡异问题。

上传图片建议用SpringMVC的CommonsMultipartResolver，配置好上传临时目录和最大文件大小。存储位置不要放在Tomcat的webapps目录下，否则每次重新部署项目，上传的图片就全部丢失了。正确做法是单独指定一个本地磁盘路径，比如D:/upload/goods/，再给这个目录配置一个静态资源映射，让访问/upload/goods/xxx.jpg时能映射到磁盘上对应的文件。

SpringMVC静态资源配置示例：

<mvc:resources mapping="/upload/**" location="file:D:/upload/" />

这样图片文件独立于应用，重装Tomcat、重新部署war包，图片都还在。另外图片名不能直接用用户上传的原始文件名，会有重名横杠和中文乱码问题，用UUID拼接文件后缀，安全又简洁。

还有一个小细节：新增和编辑商品是同一个表单页面，前端通过隐藏域传商品ID来区分操作。接收参数时，用一个GoodsDTO来接收，里面包含商品基础字段和图片地址。校验用Hibernate Validator注解，比如@NotBlank(message = "商品名称不能为空")、@NotNull(message = "商品价格不能为空")。这类基础校验能写就写，别省，答辩时提到"我在后端统一做了参数校验"是加分项。

4. 开发中的关键难点与避坑指南

4.1 商品分类的层级如何处理

宠物用品商城一般需要一级分类和二级分类，比如"狗粮"下面有"干粮""罐头""零食"。如果只用一张表，在界面展示分类树时，需要先查出所有分类，再在程序里按parent_id组装成树形结构。这个逻辑本身不复杂，但新手容易在数据封装上卡住。

推荐做法是：初始化一个List<CategoryVO>，先把所有一级分类放进去，然后遍历全部分类，把parent_id匹配一级分类id的塞进对应一级分类的children列表里。注意用mapping的方式按id分组一次遍历搞定，不要双重for循环，数据量大会慢。MyBatis里可以直接查出所有分类，然后在Service层做组装，不需要写复杂的XML嵌套查询。

前端渲染分类导航时，如果用的是JSP，可以在Controller里把分类树set到Model中，用<c:forEach>嵌套遍历。如果做前后端分离，返回JSON树结构前端用v-for或JS的map处理即可。

4.2 并发场景下库存如何不超卖

并发超卖是电商系统的经典问题，也是研究生复试、求职面试的高频题。毕设里如果老师追问"你的商品库存100件，100个人同时下单怎么办"，你要能答出这个方案：用数据库的乐观锁或条件更新来处理。

上面提到的UPDATE t_goods SET stock = stock - #{quantity} WHERE id = #{goodsId} AND stock >= #{quantity}，就是在数据库层面利用行锁保证库存扣减安全。当多个请求同时执行这条UPDATE时，数据库会串行化这些操作，后面的请求会因为stock不满足条件而更新0行，代码里判断影响行数为0就说明库存不足。

在ServiceImpl中这样写：

int updated = goodsMapper.reduceStock(goodsId, quantity); if (updated == 0) { throw new BizException("库存不足，商品ID：" + goodsId); }

这样就不用先查库存再减库存，既简单又不容易超卖。如果商品行数据被并发更新，你还能在表里加一个version字段，用UPDATE t_goods SET stock = stock - #{quantity}, version = version + 1 WHERE id = #{goodsId} AND version = #{version}，实现乐观锁方案。两者选一个写进项目即可，答辩能讲清楚原理就够了。

4.3 MyBatis的坑：字段映射和动态SQL

我辅导过不少学生，他们在写项目的第一个星期，几乎都被一个极其低级的MySQL问题卡住过：MySQL数据库的字段名是order_no，实体类属性是orderNo，结果查出来字段值全部为null。原因在于MyBatis的自动映射规则是区分大小写的Java属性与列名匹配，如果没开启mapUnderscoreToCamelCase配置，下划线和驼峰并不能自动转换。

解决办法很直接，在mybatis-config.xml里开启：

<settings> <setting name="mapUnderscoreToCamelCase" value="true"/> </settings>

开启后，order_no自动映射到orderNo，基本告别手写ResultMap。注意，开启这个配置后，如果字段匹配不上了，大概率是你的实体类属性名字写错了，而不是配置问题。

动态SQL是MyBatis的灵魂。很多新手写多条件商品查询时，把所有可能条件一次性写在WHERE后面，结果某个字段没传值就导致语法错误或查不到数据。正确写法是用<if>标签拼接条件，比如：

<select id="searchGoods" resultType="com.example.petstore.entity.Goods"> SELECT * FROM t_goods <where> <if test="keyword != null and keyword != ''"> AND name LIKE CONCAT('%', #{keyword}, '%') </if> <if test="categoryId != null"> AND category_id = #{categoryId} </if> </where> ORDER BY create_time DESC </select>

<where>标签会自动去掉第一个多余的AND，非常实用。另外如果一个商品被逻辑删除字段标识了deleted = 1，每次查询记得拼上AND deleted = 0，不然你"删除"的商品还出现在用户面前，那场面很尴尬。

5. 常见问题与排查技巧实录

5.1 高频报错与解决方案速查表

实际开发中报错不可怕，可怕的是不知道去哪里找问题。我把这个商城系统开发过程中最高频的报错整理成表格，你遇到问题直接查这个表，至少能解决80%的日常卡壳。

5.2 排查思路：从页面到数据库的链路追踪

遇到"前端页面报错"的情况，先别急着看前端代码，盲人摸象是最浪费时间的。整理一套标准的排查链路，效率会高很多。

第一步：看浏览器F12的Network面板，确定请求是否发出，接口返回的HTTP状态码是200还是500。如果状态码是500，直接去IDEA看控制台异常堆栈，定位在哪一行代码爆的。如果状态码是404，检查浏览器请求路径和Controller里的@RequestMapping是否一致，是不是少了项目上下文路径。

第二步：如果状态码200但页面显示不对，比如列表为空，多半是后端返回的数据结构不对或前端渲染逻辑出错。在浏览器里直接访问接口URL，看返回的JSON数据是否符合预期。如果JSON里没有数据，去数据库手动执行一遍MyBatis生成的SQL，看是否能查出数据。如果SQL查不出数据，那就是SQL条件和数据本身不匹配。

第三步：如果是事务相关的问题，比如下单库存不减，检查Service方法的@Transactional是否生效。Spring事务代理有一个经典陷阱，就是同类内部方法调用时，事务不会生效。确保Controller调用的是ServiceImpl的公开方法，而不是内部私有方法。

5.3 答辩中的高频追问和应对思路

这部分也许比写代码本身更关键。很多同学项目做完了，但一进答辩教室就语无伦次。提前把这几个问题准备好，基本能稳住大局。

第一问：为什么选择SSM框架而不是Spring Boot？你可以回答，选题要求使用SSM，其核心目的是深入理解Spring IOC、Spring MVC的请求流程和MyBatis的数据库交互原理，这些底层能力是后续学习Spring Boot的基础。同时通过对Spring配置文件的手动编写，反而比自动配置更能掌握系统是如何组合的。

第二问：购物车数据为什么存在数据库而不是Session？这是个好题。存Session的优点是简单、无需访问数据库，但缺点是无法跨设备同步，用户换个电脑购物车就没了。存数据库的优点是持久化、可在多个设备保持同步，同时便于后期做推送营销和数据分析。你只要逻辑自洽，回答哪个都可以，关键是说清楚你选它的理由。

第三问：订单超时未支付怎么办？毕设可以不实现自动取消，但你可以回答一个思路：定时任务每天扫描订单表中状态为待付款、且创建时间超过30分钟的订单，自动将其状态改为已取消并恢复库存。引入Spring的@Scheduled注解，几行就能做到，这个扩展点建议真加到项目里，别光说。

第四问：权限控制怎么做的？简单明了的回答是：项目中有两个拦截器，分别拦截用户端需要登录的请求和管理端所有请求。管理端拦截器会额外判断当前Session中的用户角色是否为管理员，否则拒绝访问。同时数据库的user表里有role字段区分用户和管理员。

6. 项目扩展方向与提升建议

6.1 给项目加分的小功能

如果你时间充裕，强烈建议给项目加以下任何一项，都能让答辩的含金量上一个台阶。

第一个是Redis缓存热点商品。当商品详情被频繁访问时，用Redis缓存商品信息，减少数据库压力。实现上，在查询商品详情前先查Redis，命中直接返回，未命中查数据库并写入Redis，同时设置过期时间。虽然毕设这个项目规模用不上缓存，但这是大型系统真实在用的方案，面试里讲出来比单纯说增删改查强得多。

第二个是RabbitMQ消息队列做异步订单通知。用户下单成功后，向MQ发送一条消息，后台消费者监听队列，完成后续的积分赠送或者短信通知。这个在毕设里有点重，但如果你简历上写"了解MQ应用"，最好真在某个环节用过。

第三个是支付回调的签名校验逻辑。虽然是模拟支付，但你可以设计一个签名规则，比如MD5加密订单号和金额等参数，支付完成后回调时重新计算签名并比对，防止伪造回调。这个小功能专门用于回应老师"你怎么防止支付回调被恶意刷"的追问。

6.2 从毕设到面试项目的包装思路

很多人的毕设做完就扔了，非常可惜。只要稍加整理，完全可以变成简历上的项目亮点。整理时要注意三点。

第一，把项目的技术栈描述清楚，不要只写"SSM电商系统"，要写"基于Spring、SpringMVC、MyBatis的分层宠物用品电商平台，涵盖用户认证、商品管理、订单事务处理等核心业务模块"。这样既让人快速理解项目内容，又突出了技术深度。

第二，把亮点提炼成三四条，分别对应一个技术点。比如："通过AOP和自定义注解实现登录鉴权，管理端接口独立权限隔离"、"基于事务注解实现库存与订单的一致性控制，防止并发超卖"、"采用Redis缓存热点商品详情，降低数据库压力"、"通过数据统计模块按日/周/月展示销售趋势"。这四条每条都能引出面试官感兴趣的子话题。

第三，准备一个"如何在生产环境部署"的说明。比如Maven打包成war包、上传到服务器的Tomcat、MySQL数据库初始化脚本、外部图片存储路径配置等。不用真的部署到云服务器，但流程讲清楚，面试官会觉得你是认真做过完整项目的，而不只是写完代码交差。

7. 写在最后的一点个人体会

做这类商城系统，我最大的体会是：技术本身不是难点，难点在于你能否把一个完整的业务闭环跑通。很多同学卡住的地方不在写代码，而在"不知道下一步该做什么"。所以拿到题目以后，别急着敲键盘，先花半天画一画页面流转图，理一理每个按钮背后要调哪个接口、改哪张表的数据。理清楚了，后面写代码就是照图施工。

还有一个很实际的经验：严格按数据库表设计来建实体类，不到万不得已不要临时改表结构。表结构一旦改动，涉及的实体类、MapperXML、Service层、页面，以及所有相关联的查询，全都要跟着改。改到最后你会觉得到处都是雷。

最后想说的是，答辩的评分标准里，代码能不能跑通只占一部分，更关键的是你对系统整体设计的理解程度。你能不能在老师的追问下，从容地讲清楚为什么这么建表、为什么这样控制事务、为什么用拦截器而不是在每个Controller里写判断，这才是拉开差距的地方。把这篇文章里涉及的设计思路消化成自己的语言，相信你答辩的时候就有底气了。