基于SSM的连锁咖啡店后台管理系统：Java毕业设计完整拆解

简介：一份基于Java开发的连锁咖啡店后台管理系统毕业设计源码，面向计算机相关专业在校学生、老师及行业从业者。系统采用SSM框架整合，包含完整的前后台代码、Maven配置及JSP页面，覆盖门店、商品、订单、会员等典型连锁咖啡业务模块，可作为毕业设计、课程设计或项目立项演示的现成方案。资源包共25个文件，以13个Java源文件为主，辅以9个XML配置文件、1个properties配置、1个JSP页面及1个IDE项目文件，整体仅19KB，结构精简却五脏俱全，适合直接导入IDE运行学习。代码已经过运行测试，功能正常可放心下载。项目既适合小白进阶，也支持有基础的开发者在此基础上二次开发，扩展新功能。压缩包内包含Maven工程文件pom.xml及crm-coffee-ssm.iml项目描述文件，方便快速搭建环境。目前已有112人下载学习，适合需要快速搭建后台管理系统或完成毕业设计的学生使用。

1. 连锁咖啡店后台管理系统：一个 Java 毕业设计项目的完整拆解

连锁咖啡店后台管理系统，这个 Java 毕业设计要解决的问题比想象中更具体：门店一多，各家用 Excel 记账，总部要等店长下班发报表才能看到当日销售；一家店断货了其他门店还在接单；会员积分各店各算，换个店等于清零。

这套基于 SSM 框架的连锁咖啡店后台管理系统，把混乱收拢成可运行的业务闭环，覆盖门店、商品、订单、库存、员工、会员六大模块。

适合正在做毕业设计或课程设计的同学直接参考，也适合想快速上手 SSM 后台管理项目的开发者——框架整合、模块划分、数据库建模、部署避坑，一条线讲清楚。

2. 需求分析与总体架构设计：SSM 三层结构与六个核心模块

2.1 用户角色与核心业务流程

先想清楚谁在用这个系统，这是做后台管理系统时最容易跳过又最容易翻车的一步。这个项目里我把用户分成三类：总部管理员、店长、收银员。总部管理员看全部门店的数据，负责商品统一上下架、门店档案维护、销售汇总查看；店长只管自己门店的库存、员工排班和日报；收银员只负责前台下单、会员充值和积分查询，权限最小。三类人的操作范围不同，登录之后用 session 里存的角色字段做区分，菜单也按角色渲染，这个设计在答辩时是很好的切入点。

业务流程上，核心链路是「门店营业 → 顾客点单 → 收银员下单 → 系统扣减该门店库存 → 订单入库 → 总部看到销售汇总 → 库存低于阈值触发补货」。这条链路决定了模块之间怎么协作：订单模块要反向更新库存表，商品模块要给订单模块提供价格和名称，会员模块要在下单时计算折扣和积分。如果一开始就把各个模块当成独立的增删改查页面来做，最后拼起来一定对不上。

补货流程也需要明确：门店库存低于阈值，店长发起补货申请，总部审核后生成采购单，货物入库后更新库存数。这个项目把采购单简化成了「库存预警 + 人工入库」两步，没有单独建采购模块，演示时反而更容易讲清楚闭环。库存预警的阈值放在 Inventory 表里，每个门店每个商品都可以单独配置，比写死在代码里灵活得多。

2.2 技术选型与系统分层架构

技术栈选的是经典的 SSM：Spring 管对象和事务，SpringMVC 管请求分发和参数绑定，MyBatis 管数据库访问，前端用 JSP + jQuery，构建工具用 Maven，数据库用 MySQL，部署在 Tomcat 8。这个组合在毕业设计里非常常见，原因是它把「框架整合」这件事本身变成了可展示的技术点：Spring 容器、SpringMVC 的 DispatcherServlet、MyBatis 的 SqlSessionFactory 三者如何融合，每一步配置都能在答辩时讲出理由。项目根目录下的 pom.xml、crm-coffee-ssm.iml、src/main 结构，都是标准 Maven Web 项目的骨架。

分层结构按经典三层走：表现层用 Controller 接收请求并做参数校验，返回页面或 JSON；业务层用 Service 接口加实现类承载业务规则，比如下单时校验库存、计算实付金额；持久层用 Mapper 接口加 XML 文件，一个方法对应一条 SQL。除此之外还有几个横切组件：拦截器做登录校验，全局异常处理器兜底，DTO 负责层与层之间的数据传输。pojo 目录下放实体类，与数据库表一一对应，字段命名统一驼峰，配合 MyBatis 的 mapUnderscoreToCamelCase 配置，查询结果能自动映射。

这里说一条我的血泪经验：不要让 Controller 里出现业务逻辑，也不要让 Service 之间互相乱调。比如商品查询，Controller 只接收 pageNum、pageSize、productName 这些参数，Service 里拼好查询条件再调 Mapper，这样后期加索引、改 SQL 都不影响上层。项目代码里的 package 结构是 com.crm.coffee.controller / service / mapper / pojo，照着这个分包写，答辩时讲「职责单一」就有落脚点，评阅老师翻代码也舒服。

2.3 六个核心功能模块的职责划分

系统按业务拆成六个模块。门店管理模块维护门店档案，包括名称、地址、电话、营业状态，总部管理员可以新增和停用门店，店长只能查看自己所在门店；商品与分类模块做两级分类，咖啡、烘焙、周边等挂在父分类下，商品再挂到子分类下，字段包含售价、成本价、单位、图片地址；订单管理模块是核心，收银员选择门店、勾选商品、计算金额、选择支付方式，提交后同时生成订单主表和明细表；库存管理模块记录每个门店每个商品的库存量，商品上架、订单提交、入库操作都会动这张表；员工管理模块管理员工档案、所属门店和职位，与系统登录账号关联；会员管理模块管会员档案、积分和余额，下单时按会员等级打折并累计积分。

六个模块之间不是并列关系，而是订单为主线、库存为约束的关系。演示的时候我会推荐这个顺序：先建门店，再建员工并分配登录账号，给门店初始化库存，上架商品，然后模拟一次完整下单，最后去库存列表里看到扣减结果。这套顺序本身就是一张天然的验收脚本，后面第四章的实现和第六章的验收都会复用这个思路。

3. 数据库设计：九张核心表与订单库存联动的关键约束

3.1 实体关系梳理与表清单

数据库设计是整个项目里最不能省的一步，很多同学代码写得很快，最后栽在表结构上。这个系统的实体关系其实不复杂：门店和商品之间是多对多，所以中间必须有 inventory 表记录「某门店某商品有多少库存」；订单和明细是一对多，一张订单多条明细；员工、会员、系统账号各自独立，通过外键和门店关联。整理下来一共九张表：

关系的核心是 inventory 表的主键设计：它用 store_id 和 product_id 做联合唯一索引，而不是单独的主键加两个普通外键。这样设计有两个好处，一是天然防止同一个门店对同一个商品出现两条库存记录，二是在做库存扣减时可以用条件更新直接命中一行，不用先查再改。

3.2 核心业务表结构设计

product 表是商品档案的基础，注意价格字段必须用 decimal，不能用 double 或 float，金额精度问题是这个项目里评测很容易抓的点。

CREATE TABLE `product` ( `id` bigint(20) NOT NULL AUTO_INCREMENT COMMENT '商品ID', `product_name` varchar(64) NOT NULL COMMENT '商品名称', `category_id` bigint(20) NOT NULL COMMENT '所属分类ID', `price` decimal(10,2) NOT NULL COMMENT '销售价', `cost_price` decimal(10,2) NOT NULL COMMENT '成本价，用于毛利统计', `unit` varchar(10) DEFAULT '杯' COMMENT '销售单位', `sale_status` tinyint(4) DEFAULT '1' COMMENT '1上架 0下架', `create_time` datetime DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', PRIMARY KEY (`id`), KEY `idx_category` (`category_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='商品表';

orders 表是业务核心，order_no 设置唯一索引，每次下单用时间加随机数生成，避免订单号冲突；store_id 和 create_time 建联合索引，因为总部报表最常做的查询就是「某个时间段内某个门店的销售额汇总」。

CREATE TABLE `orders` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL COMMENT '订单编号', `store_id` bigint(20) NOT NULL COMMENT '门店ID', `member_id` bigint(20) DEFAULT NULL COMMENT '会员ID，可空', `cashier_id` bigint(20) NOT NULL COMMENT '收银员ID', `total_amount` decimal(10,2) NOT NULL COMMENT '订单原价合计', `discount_amount` decimal(10,2) DEFAULT '0.00' COMMENT '优惠金额', `pay_amount` decimal(10,2) NOT NULL COMMENT '实付金额', `pay_type` tinyint(4) NOT NULL COMMENT '1微信 2支付宝 3现金 4会员余额', `status` tinyint(4) NOT NULL DEFAULT '1' COMMENT '1已支付 2已退款', `create_time` datetime DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_store_time` (`store_id`, `create_time`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单主表';

order_item 明细表里有一个容易被忽略的设计：product_name 和 price 这两个字段必须冗余存储，不能下单时去关联 product 表实时查。因为商品后续会改价、会下架，如果明细表只存 product_id，历史订单的价格和名称就会被改得对不上。冗余快照是订单系统的常规做法，答辩时能主动讲出这一点，会明显加分。

CREATE TABLE `order_item` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `order_id` bigint(20) NOT NULL COMMENT '订单ID', `product_id` bigint(20) NOT NULL COMMENT '商品ID', `product_name` varchar(64) NOT NULL COMMENT '下单时商品名称快照', `price` decimal(10,2) NOT NULL COMMENT '下单时单价快照', `quantity` int(11) NOT NULL COMMENT '数量', `amount` decimal(10,2) NOT NULL COMMENT '小计金额', PRIMARY KEY (`id`), KEY `idx_order` (`order_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单明细表';

inventory 表的扣减是后面章节的重点，这里先看表结构：stock_quantity 存当前库存，warn_threshold 存预警阈值，联合唯一索引保证门店和商品的组合唯一。表里没有外键约束，目的是减少不必要的锁和级联操作，外键逻辑由 Service 层保证，这也是实际项目中更常见的取舍。

CREATE TABLE `inventory` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `store_id` bigint(20) NOT NULL COMMENT '门店ID', `product_id` bigint(20) NOT NULL COMMENT '商品ID', `stock_quantity` int(11) NOT NULL DEFAULT '0' COMMENT '当前库存数量', `warn_threshold` int(11) DEFAULT '10' COMMENT '预警阈值', `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_store_product` (`store_id`, `product_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='门店库存表';

3.3 订单与库存的联动约束与索引设计

订单扣库存是这个系统里最关键的业务约束。常规的「先查库存，判断够不够，再 update」写法存在并发问题：两个收银员同时下单，都查到了库存剩余 3 件，各下了 2 件，最终库存变成负数。正确的做法是把判断放进 update 语句里，让数据库行锁来保证原子性：

UPDATE inventory SET stock_quantity = stock_quantity - #{quantity}, update_time = NOW() WHERE store_id = #{storeId} AND product_id = #{productId} AND stock_quantity >= #{quantity}

这条 SQL 的巧妙之处在于，where 条件里的 stock_quantity >= 参数既承担了库存校验，又承担了并发控制。affected rows 返回 0 说明库存不足，Service 层直接抛异常回滚事务，订单不会生成。这种写法避免了先查后改的窗口期，是实际项目中解决超卖最朴素也最可靠的手段。

索引方面，除了每张表的主键，orders 表有 order_no 唯一索引和 store_id + create_time 联合索引，order_item 有 order_id 索引，inventory 有 store_id + product_id 联合唯一索引，product 有 category_id 索引。九张表加起来索引数量不多，但每个索引都有明确的查询场景支撑，不存在为了建而建的冗余索引。

4. 关键功能模块实现：登录鉴权、动态查询与事务下单

4.1 登录鉴权：基于 SpringMVC 拦截器的会话控制

登录模块没有引入 Shiro 这类重量级安全框架，而是用 SpringMVC 拦截器加 session 实现，原因是系统规模小，角色只有三类，拦截器方案足够且更容易讲清楚。登录接口先验证用户名密码，成功后把用户对象放进 session，角色字段决定了后续跳转到总部首页还是门店首页：

@Controller public class LoginController { @Autowired private SysUserService sysUserService; @RequestMapping("/login") public String login(String username, String password, HttpSession session) { SysUser user = sysUserService.login(username, password); if (user == null) { // 用重定向避免表单重复提交，同时带回错误标识 return "redirect:/loginPage?error=1"; } session.setAttribute("loginUser", user); // 角色1是总部管理员，其他角色跳转门店首页 if (user.getRoleId() == 1) { return "redirect:/admin/index"; } return "redirect:/store/index"; } }

拦截器负责拦截所有请求，检查 session 里有没有登录用户，没有就重定向到登录页。要注意的是静态资源路径必须排除，否则 css、js 也会被拦，页面样式加载不出来：

public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { SysUser user = (SysUser) request.getSession().getAttribute("loginUser"); if (user != null) { return true; } response.sendRedirect(request.getContextPath() + "/loginPage"); return false; } }

拦截器注册放在 SpringMVC 的配置文件中，路径用双星匹配所有请求，再逐个 exclude 掉登录页、登录接口和静态资源目录：

<mvc:interceptors> <mvc:interceptor> <mvc:mapping path="/**"/> <mvc:exclude-mapping path="/login"/> <mvc:exclude-mapping path="/loginPage"/> <mvc:exclude-mapping path="/css/**"/> <mvc:exclude-mapping path="/js/**"/> <mvc:exclude-mapping path="/images/**"/> <bean class="com.crm.coffee.interceptor.LoginInterceptor"/> </mvc:interceptor> </mvc:interceptors>

这段配置里最容易漏的是 exclude-mapping 顺序问题：SpringMVC 会按声明顺序逐个匹配，exclude 匹配优先于 interceptor 匹配，所以排除项放在 interceptor 前面是正确的。如果发现登录后页面样式全乱，第一反应就应该是检查静态资源有没有被拦截器拦掉。

4.2 商品管理：MyBatis 动态 SQL 实现多条件分页查询

商品管理是典型的后台 CRUD，但查询场景要支持按商品名称模糊搜索、按分类筛选、按上下架状态筛选三个条件自由组合，而且商品量大了之后必须分页。MyBatis 动态 SQL 就是为这种场景设计的，Mapper 接口定义方法，XML 里用 where 加 if 标签拼条件：

<select id="selectProductList" parameterType="map" resultType="com.crm.coffee.pojo.Product"> SELECT id, product_name, category_id, price, cost_price, unit, sale_status, create_time FROM product <where> <if test="productName != null and productName != ''"> AND product_name LIKE CONCAT('%', #{productName}, '%') </if> <if test="categoryId != null and categoryId != 0"> AND category_id = #{categoryId} </if> <if test="saleStatus != null"> AND sale_status = #{saleStatus} </if> </where> ORDER BY id DESC LIMIT #{offset}, #{pageSize} </select>

使用 where 标签而不是手写 WHERE 1=1，好处是 MyBatis 会自动处理多余的 AND 前缀：当前面所有条件都不成立时，where 标签输出空，SQL 变成 SELECT ... FROM product ORDER BY id DESC，不会产生语法错误。参数用 map 传递，offset 和 pageSize 由 Service 层计算，前端传页码和每页条数，Service 层统一换算：

public PageResult<Product> queryProduct(int pageNum, int pageSize, String productName, Long categoryId, Integer saleStatus) { Map<String, Object> params = new HashMap<>(); params.put("offset", (pageNum - 1) * pageSize); params.put("pageSize", pageSize); params.put("productName", productName); params.put("categoryId", categoryId); params.put("saleStatus", saleStatus); List<Product> list = productMapper.selectProductList(params); int total = productMapper.countProductList(params); return new PageResult<>(list, total); }

这里要注意 MyBatis 的 mapUnderscoreToCamelCase 配置必须开启，否则数据库的 product_name 字段映射不到 Java 的 productName 属性，查询结果里名称会是 null。聚合查询 countProductList 里的参数和条件必须与 selectProductList 保持一致，最稳妥的做法是抽一个公共的查询条件对象，避免两套 SQL 条件不同步。

4.3 下单与库存扣减：事务保证的业务闭环

下单是整个系统最核心的业务方法，它同时涉及订单主表插入、订单明细插入、库存扣减三步，任何一步失败都不能留下脏数据，所以必须用 Spring 声明式事务包起来。核心实现如下：

@Service public class OrderServiceImpl implements OrderService { @Autowired private OrderMapper orderMapper; @Autowired private OrderItemMapper orderItemMapper; @Autowired private InventoryMapper inventoryMapper; @Override @Transactional(rollbackFor = Exception.class) public void createOrder(OrderDTO dto) { // 1. 生成订单主记录，状态置为已支付 Orders order = buildOrder(dto); orderMapper.insert(order); // 2. 逐条处理订单明细并扣减门店库存 for (OrderItemDTO item : dto.getItems()) { int rows = inventoryMapper.deductStock( dto.getStoreId(), item.getProductId(), item.getQuantity()); if (rows == 0) { // 库存不足时抛异常，整个事务回滚 throw new RuntimeException("商品库存不足: " + item.getProductId()); } orderItemMapper.insert(buildOrderItem(order.getId(), item)); } } private Orders buildOrder(OrderDTO dto) { Orders order = new Orders(); order.setOrderNo(generateOrderNo()); order.setStoreId(dto.getStoreId()); order.setMemberId(dto.getMemberId()); order.setCashierId(dto.getCashierId()); order.setTotalAmount(dto.getTotalAmount()); order.setDiscountAmount(dto.getDiscountAmount()); order.setPayAmount(dto.getPayAmount()); order.setPayType(dto.getPayType()); return order; } private String generateOrderNo() { SimpleDateFormat sdf = new SimpleDateFormat("yyyyMMddHHmmss"); return sdf.format(new Date()) + String.format("%04d", new Random().nextInt(10000)); } }

几个关键点需要说明。一是 @Transactional 必须加 rollbackFor = Exception.class，因为 Spring 默认只在遇到 RuntimeException 时才回滚，如果业务中抛的是受检异常，不加这个参数事务不会回滚，这是最常见的坑。二是订单编号用时间戳加四位随机数生成，同一秒内并发下单时随机数避免冲突，配合数据库的唯一索引兜底。三是库存不足抛的是 RuntimeException，触发了事务回滚，订单主表和之前已经插入的明细全部回滚，不会出现「订单生成了但库存没扣」的脏数据。

金额计算方面，OrderDTO 里的 totalAmount、discountAmount、payAmount 在 Controller 层用 BigDecimal 计算，前端只传商品 ID 和数量，价格一律以数据库里的商品表为准，绝对不信任前端传过来的价格。这样设计既防止了篡改价格的风险，也保证了订单金额和库存、会员折扣逻辑一致。

提示：在演示库存不足场景时，先把某个商品的库存改成 1，再下单 2 件，系统应提示库存不足且订单不生成。这个演示是答辩时的经典加分项，一定要提前准备。

5. 开发部署常见问题排查：五类最容易翻车的坑

5.1 Maven 依赖冲突导致 Tomcat 启动失败

现象：Tomcat 启动时报 NoSuchMethodError、ClassNotFoundException，或者 Spring 容器初始化时抛 BeanCreationException，控制台里的报错堆栈指向 spring-web 或 mybatis-spring 相关类。

原因：pom.xml 里多个依赖传递引入了不同版本的 Spring 或 MyBatis，比如 spring-core 是 5.2，spring-webmvc 却是 5.1，类加载时找到的不是预期版本。毕业设计项目最常见的翻车点是把 spring-web、spring-webmvc、spring-jdbc 等模块的版本号各写各的。

解决：在 pom.xml 的 properties 里统一定义一个版本号，所有 spring 模块引用同一个变量，并在 dependencyManagement 里锁版本。排查时用mvn dependency:tree -Dincludes=org.springframework看依赖树，找到重复的 jar 包和版本，再用 exclude 排除掉传递依赖中多余的版本。建议这个项目因为是 SSM 整合，Spring 统一用 5.2.x，mybatis-spring 用 2.0.x，两者兼容性经过大量项目验证，是最稳的组合。

5.2 数据库连接与时区配置报错

现象：项目启动后访问任何页面都报 Cannot create PoolableConnectionFactory，或者是 Communications link failure，再往下一行能看到 serverTimezone 相关的提示。

原因：新版 MySQL 驱动对连接 URL 的参数要求更严格。如果用 MySQL 8，驱动类要写 com.mysql.cj.jdbc.Driver，旧驱动类 com.mysql.jdbc.Driver 虽然还能用但会告警；同时 URL 里必须指定 serverTimezone，否则驱动不知道用哪个时区解析时间类型，直接拒绝连接。

解决：jdbc.properties 里统一按下面这套配：

jdbc.driver=com.mysql.cj.jdbc.Driver jdbc.url=jdbc:mysql://localhost:3306/crm_coffee?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai&allowPublicKeyRetrieval=true jdbc.username=root jdbc.password=你的密码

allowPublicKeyRetrieval=true 是给 MySQL 8 的 caching_sha2_password 认证用的，不加在某些连接池配置下会报 Public Key Retrieval is not allowed。如果本地用的是 MySQL 5.7，驱动类可以切回 com.mysql.jdbc.Driver，URL 里的 serverTimezone 也可以去掉，但要保证 jar 包版本和数据库版本匹配，不要拿 8.0 的驱动连 5.7 的库还带着一堆高版本参数。

5.3 中文乱码：跨越多层的编码链路

现象：页面上中文显示成 ??，或者数据库里查出来的中文是乱码，控制台打印日志时中文也是乱的。

原因：乱码问题至少要排查三个环节：JSP 页面本身的编码、请求参数从浏览器到服务器的编码、数据库连接传输的编码。只改其中一个环节，乱码依然会出现，这也是乱码被称为「玄学」问题的原因——它本质上是一条链路，断任何一环都会出问题。

解决：三层一起改。第一层在 web.xml 里配置 Spring 的 CharacterEncodingFilter，强制请求和响应统一 UTF-8，注意 forceEncoding 要设成 true，否则只对请求生效；

<filter> <filter-name>encodingFilter</filter-name> <filter-class>org.springframework.web.filter.CharacterEncodingFilter</filter-class> <init-param> <param-name>encoding</param-name> <param-value>UTF-8</param-value> </init-param> <init-param> <param-name>forceEncoding</param-name> <param-value>true</param-value> </init-param> </filter> <filter-mapping> <filter-name>encodingFilter</filter-name> <url-pattern>/*</url-pattern> </filter-mapping>

第二层保证 JSP 文件头是 pageEncoding="UTF-8"，第三层保证 jdbc.url 里有 characterEncoding=utf8，三管齐下乱码基本绝迹。排查时按请求参数乱码、数据库读出来乱码、页面显示乱码三个方向逐个定位，不要上来就改代码。

5.4 MyBatis Mapper 扫描路径不匹配

现象：项目启动正常，但一调用某个查询就报 Invalid bound statement (not found)，或者 Mapper 接口的方法找不到对应的实现。

原因：Mapper 接口的全限定名和 XML 文件的 namespace 不一致，或者 MapperScannerConfigurer 配置的 basePackage 没有扫到接口所在的包。很多同学把 XML 放在 java 目录下和接口同一级，但没有在 pom.xml 或构建配置里把 XML 作为资源打包，导致编译后 classes 目录里只有接口没有 XML。

解决：检查三处。第一，XML 文件的 namespace 必须等于接口的全限定名，比如接口是 com.crm.coffee.mapper.ProductMapper，namespace 就写 com.crm.coffee.mapper.ProductMapper；第二，Spring 配置里 MapperScannerConfigurer 的 basePackage 写 com.crm.coffee.mapper，确保扫描到所有接口；第三，XML 文件如果放在 src/main/java 下，必须在 pom.xml 的 build/resources 或 main/resources 里补配 xml 文件的资源路径，或者直接把 XML 统一放到 src/main/resources/mapper 目录下，这是最省心的做法。

5.5 Webapp 资源未打包导致页面 404

现象：在 IDEA 里用 Tomcat 插件运行一切正常，但把项目打成 war 包部署到独立 Tomcat 后，访问首页 404，或者页面能打开但 CSS、JS 全丢。

原因：IDEA 运行时用的是编译输出目录，开发模式下资源能实时同步；打 war 时如果 pom.xml 里的 maven-war-plugin 配置不对，或者 JSP、静态资源没有被包含进 war 包，部署上去就缺文件。另一个常见原因是 webapp 目录位置没配对，Maven 默认认 src/main/webapp，如果项目结构里 webapp 设成了其他名字，打包就会漏。

解决：pom.xml 里显式配置 maven-war-plugin，并检查 warSourceDirectory 指向 src/main/webapp，同时确认 finalName 和 Tomcat 的部署路径对应。打完包后，用解压工具打开 war 检查 WEB-INF/classes 下有没有 mapper 的 XML、jdbc.properties，以及根目录下有没有 css、js 目录。养成「打完包先看文件清单」的习惯，可以避免大量部署阶段的冤枉时间。

6. 验收与答辩：从功能演示到问题应答的完整准备

6.1 验收清单怎么列

验收不能等到答辩前一夜才开始，我一般会提前三天按功能闭环跑一遍清单。下面是这套系统最核心的验收表和推荐演示顺序：

6.2 答辩高频问题与应答思路

答辩时老师最常问的不是「代码怎么写的」，而是「为什么这么设计」。几个高频问题提前准备：为什么选 SSM 不选 Spring Boot，答「SSM 的整合过程能把框架底层原理展示出来，Spring Boot 自动配置太多，体现不了对配置的理解」；库存并发怎么防止超卖，答「用 update 语句的条件原子更新，where 里带 stock_quantity >= 参数，影响行数为 0 即失败，靠数据库行锁保证」；金额为什么不用 double，答「二进制浮点数有精度误差，金额用 BigDecimal 并保持两位小数」；订单明细为什么要冗余字段，答「商品改价后历史订单不能被影响，快照保证可追溯」。每个问题的核心都是回到表设计和代码实现上，而不是背概念。

演示时我习惯把数据库先初始化好一套完整数据：三家门店、二十个商品、两个会员、若干订单，让老师能看到真实的统计效果。临场演示最怕的账号密码错误、端口被占用这类低级问题，验收清单里步就已经覆盖了。从那以后我每次做管理系统，都会强制自己先把角色和流程走一遍再写代码，这个顺序帮我避过了大量返工——先想清「谁在什么场景下做什么」，数据库表才不会建歪。希望帮到你。

本文还有配套的精品资源，点击获取