简介一份基于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 技术选型与系统分层架构技术栈选的是经典的 SSMSpring 管对象和事务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 表记录「某门店某商品有多少库存」订单和明细是一对多一张订单多条明细员工、会员、系统账号各自独立通过外键和门店关联。整理下来一共九张表表名用途关键字段sys_user系统登录账号username、password、role_id、store_idstore门店档案store_name、address、manager_id、statusproduct_category商品分类category_name、parent_id、sortproduct商品档案product_name、category_id、price、cost_priceorders订单主表order_no、store_id、cashier_id、pay_amount、statusorder_item订单明细表order_id、product_id、product_name、quantity、amountinventory门店库存表store_id、product_id、stock_quantity、warn_thresholdemployee员工档案emp_no、emp_name、store_id、positionmember会员档案member_no、phone、points、balance关系的核心是 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 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) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 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?error1; } 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 classcom.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 idselectProductList parameterTypemap resultTypecom.crm.coffee.pojo.Product SELECT id, product_name, category_id, price, cost_price, unit, sale_status, create_time FROM product where if testproductName ! null and productName ! AND product_name LIKE CONCAT(%, #{productName}, %) /if if testcategoryId ! null and categoryId ! 0 AND category_id #{categoryId} /if if testsaleStatus ! null AND sale_status #{saleStatus} /if /where ORDER BY id DESC LIMIT #{offset}, #{pageSize} /select使用 where 标签而不是手写 WHERE 11好处是 MyBatis 会自动处理多余的 AND 前缀当前面所有条件都不成立时where 标签输出空SQL 变成 SELECT ... FROM product ORDER BY id DESC不会产生语法错误。参数用 map 传递offset 和 pageSize 由 Service 层计算前端传页码和每页条数Service 层统一换算public PageResultProduct queryProduct(int pageNum, int pageSize, String productName, Long categoryId, Integer saleStatus) { MapString, 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); ListProduct 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.2spring-webmvc 却是 5.1类加载时找到的不是预期版本。毕业设计项目最常见的翻车点是把 spring-web、spring-webmvc、spring-jdbc 等模块的版本号各写各的。解决在 pom.xml 的 properties 里统一定义一个版本号所有 spring 模块引用同一个变量并在 dependencyManagement 里锁版本。排查时用mvn dependency:tree -Dincludesorg.springframework看依赖树找到重复的 jar 包和版本再用 exclude 排除掉传递依赖中多余的版本。建议这个项目因为是 SSM 整合Spring 统一用 5.2.xmybatis-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.drivercom.mysql.cj.jdbc.Driver jdbc.urljdbc:mysql://localhost:3306/crm_coffee?useUnicodetruecharacterEncodingutf8useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltrue jdbc.usernameroot jdbc.password你的密码allowPublicKeyRetrievaltrue 是给 MySQL 8 的 caching_sha2_password 认证用的不加在某些连接池配置下会报 Public Key Retrieval is not allowed。如果本地用的是 MySQL 5.7驱动类可以切回 com.mysql.jdbc.DriverURL 里的 serverTimezone 也可以去掉但要保证 jar 包版本和数据库版本匹配不要拿 8.0 的驱动连 5.7 的库还带着一堆高版本参数。5.3 中文乱码跨越多层的编码链路现象页面上中文显示成 ??或者数据库里查出来的中文是乱码控制台打印日志时中文也是乱的。原因乱码问题至少要排查三个环节JSP 页面本身的编码、请求参数从浏览器到服务器的编码、数据库连接传输的编码。只改其中一个环节乱码依然会出现这也是乱码被称为「玄学」问题的原因——它本质上是一条链路断任何一环都会出问题。解决三层一起改。第一层在 web.xml 里配置 Spring 的 CharacterEncodingFilter强制请求和响应统一 UTF-8注意 forceEncoding 要设成 true否则只对请求生效filter filter-nameencodingFilter/filter-name filter-classorg.springframework.web.filter.CharacterEncodingFilter/filter-class init-param param-nameencoding/param-name param-valueUTF-8/param-value /init-param init-param param-nameforceEncoding/param-name param-valuetrue/param-value /init-param /filter filter-mapping filter-nameencodingFilter/filter-name url-pattern/*/url-pattern /filter-mapping第二层保证 JSP 文件头是 pageEncodingUTF-8第三层保证 jdbc.url 里有 characterEncodingutf8三管齐下乱码基本绝迹。排查时按请求参数乱码、数据库读出来乱码、页面显示乱码三个方向逐个定位不要上来就改代码。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.ProductMappernamespace 就写 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 验收清单怎么列验收不能等到答辩前一夜才开始我一般会提前三天按功能闭环跑一遍清单。下面是这套系统最核心的验收表和推荐演示顺序序号验收项操作方式预期结果1登录与角色权限用总部账号登录进入总部首页菜单包含门店/商品/订单/库存2门店管理新增一家门店并设置营业列表出现新门店状态为营业3员工与账号给新门店分配员工和登录账号该账号登录后只能看到本门店数据4商品上架新增分类并上架两个商品商品列表可见前台可选5下单扣库存用收银员账号下一笔两件商品的单订单金额正确库存同步减 26库存不足库存改为 1再下 2 件提示库存不足订单不生成7销售统计总部查看门店销售汇总汇总金额与订单明细一致6.2 答辩高频问题与应答思路答辩时老师最常问的不是「代码怎么写的」而是「为什么这么设计」。几个高频问题提前准备为什么选 SSM 不选 Spring Boot答「SSM 的整合过程能把框架底层原理展示出来Spring Boot 自动配置太多体现不了对配置的理解」库存并发怎么防止超卖答「用 update 语句的条件原子更新where 里带 stock_quantity 参数影响行数为 0 即失败靠数据库行锁保证」金额为什么不用 double答「二进制浮点数有精度误差金额用 BigDecimal 并保持两位小数」订单明细为什么要冗余字段答「商品改价后历史订单不能被影响快照保证可追溯」。每个问题的核心都是回到表设计和代码实现上而不是背概念。演示时我习惯把数据库先初始化好一套完整数据三家门店、二十个商品、两个会员、若干订单让老师能看到真实的统计效果。临场演示最怕的账号密码错误、端口被占用这类低级问题验收清单里步就已经覆盖了。从那以后我每次做管理系统都会强制自己先把角色和流程走一遍再写代码这个顺序帮我避过了大量返工——先想清「谁在什么场景下做什么」数据库表才不会建歪。希望帮到你。本文还有配套的精品资源点击获取