基于SpringBoot的餐饮财务管理系统实战：从架构到部署

做餐饮财务管理系统这件事，我太有发言权了。尤其当项目名落到"基于SpringBoot的餐饮财务管理系统_ui41jy6y_hxj023"这种带编号的工程上，十有八九是课程设计、毕业设计或者小团队内部要快速落地的项目。SpringBoot这个关键词，最近在 Java 圈子里的热度一直很高，网上相关的问题、热词、整合案例非常多，说明大家在做毕设或实际开发时，真的需要一个能直接开工的参考模板，而不是满屏的 XML 配置和复杂的架构理论。

这个项目本质上要解决什么问题？说白了，就是帮餐饮门店把"菜卖出去"和"钱收进来"这两件事变成系统里的数据流。从菜品管理、下单结账，到每日流水、盈亏报表，一套体系下来，老板不需要再对着 Excel 或者手写账本发愁。系统的核心价值就是：记账及时、算账准确、分析有据。

这篇文章面向两类人：一类是正在选毕设题目或者准备课设答辩的在校生，另一类是刚入职想快速上手 SpringBoot 业务系统的初级开发。我会从项目架构、数据库设计、核心技术选型到实操过程中容易踩的坑，一层层拆开讲清楚，保证你看完能照着搞出一套可运行的小系统。

1. 项目整体设计与思路拆解

1.1 为什么餐饮财务系统要选 SpringBoot 而非传统 SSM

先说个很多人纠结过的问题：这套系统用 SSM（Spring + SpringMVC + MyBatis）还是 SpringBoot？我的观点很明确：除非是学校硬性规定了某个老框架，否则选 SpringBoot，理由非常实际。

SpringBoot 最核心的价值不是"去 XML 配置"这个表象，而是它把"环境搭建"这件事的时间成本压到了极低。一个 SSM 项目，光 spring-context、spring-mvc、mybatis 这些依赖版本号互相兼容的问题就能折腾人一整天；SpringBoot 通过 starter 机制，把常用的依赖组合全都预置好了，你引入spring-boot-starter-web就等于把 Web 容器 + Spring MVC + Jackson 序列化这些基础能力全部拉齐，版本冲突的问题几乎不存在。

从团队协作角度看，SpringBoot 的自动装配机制让项目结构更统一。大家可以约定俗成地遵守"启动类放在根包、Controller 在 controller 包、Service 在 service 包"的规范，新成员接手时不用花太多时间去理解环境怎么配的，直接看业务代码就行。这个优势在课程设计这类"多人协作但实际各自为战"的场景里特别重要。

另外一个现实因素是就业。你去翻招聘网站，Java 后端岗位描述里十个有九个写着"熟悉 SpringBoot"。做这个项目的过程，本质上就是把你对 SpringBoot 自动装配、starter 机制、YAML 配置的理解，从"面试背题"变成"实际动手写过代码"。这比任何刷题都管用。

1.2 财务系统与技术选型的匹配度分析

餐饮财务管理系统不是简单的 CRUD，它有几个技术特点决定了选型方向：

第一个特点是数据一致性要求高。财务系统里，一笔订单的菜品明细、金额小计、支付状态、流水记录，这些数据必须同时成功或者同时失败。下单时前台下单成功，但后台记账失败，这种事故在财务系统里是不允许出现的。SpringBoot 天然整合了 Spring 声明式事务（@Transactional），配合 MyBatis 的数据库连接管理，可以非常方便地保证一组数据库操作的原子性。

第二个特点是报表查询场景复杂。财务系统离不开"按天统计营业额""按月结算成本""查询某段时间的流水"这类操作。SpringBoot + MyBatis 的组合下，你可以直接用 SQL 的GROUP BY、SUM、DATE_FORMAT等函数做聚合查询，把统计逻辑放在数据库层执行。对于中小型餐饮系统的数据量来说，这比引入 Hadoop、Flink 这类重计算框架高效得多，也更加符合实际情况。

第三个特点是权限需求明确。老板看报表，收银员只能点单结账，厨师可能只看菜品信息。SpringBoot 整合 Spring Security 或者 Shiro 都很方便。不过做课设的话，用拦截器（HandlerInterceptor）加一个简单的登录校验就够了，成本低、易理解，答辩时也能讲清楚。

提示：在选型时不要为了"炫技"而引入过重的组件。餐饮财务管理系统记住一条准则：能用事务解决的一致性问题不要引入分布式事务，能用 SQL 解决的统计问题不要引入流处理框架，能用一个简单的 Redis 缓存解决的热点查询不要引入独立的中间件集群。

2. 数据库设计与核心细节解析

2.1 从业务出发拆解数据模型

我见过不少人在做系统时一上来就画 ER 图、建表，结果做到一半发现缺字段、缺关联，返工成本极高。正确的做法是从业务流程出发，反推数据模型。

餐饮财务系统的核心业务流是：员工登录 -> 管理菜品 -> 客户下单 -> 结账支付 -> 生成财务流水 -> 统计报表。

围绕这个流程，至少需要这几张核心表：

• 员工表（employee）：登录账号、密码（MD5 或 BCrypt 加密存储）、角色（管理员 / 收银员 / 厨师）、手机号。
• 菜品分类表（category）：分类名称、排序、创建时间。
• 菜品表（dish）：菜品名称、分类 id、价格、菜品图片、起售状态、创建人、创建时间。
• 订单表（orders）：订单号、桌号、下单员工 id、订单状态（待支付 / 已支付 / 已退单）、下单时间、结账时间。
• 订单明细表（order_detail）：所属订单 id、菜品 id、菜品名称、菜品数量、菜品单价、小计金额。
• 流水表（payment_record）：关联订单 id、支付方式（现金 / 扫码 / 会员卡）、支付金额、支付时间、收款员工 id。
• 日报表 / 月报表（可在数据库中通过聚合查询生成，也可以单独建汇总表）。

表之间的关联关系不难，但要做对几个关键设计。

订单号一定要设计成有业务含义的唯一字符串，比如用时间戳 + 随机序列生成"20250613124500001"这种格式，方便财务核对时直接从订单号看出日期和序号。不要用数据库自增 id 当订单号暴露给用户，既不好看也不安全。

金额字段一律使用 DECIMAL，严禁使用 DOUBLE。这是个老生常谈但永远有人踩的坑。DOUBLE 是浮点数，在计算机中以二进制存储，像 0.1 这种小数无法精确表示。你在 Java 里算0.1 * 3得到的是 0.30000000000000004，虽然显示上可以通过格式化掩盖，但累加金额时误差会逐渐累积。财务系统里差一分钱都是大事。数据库用DECIMAL(10, 2)，Java 实体对应BigDecimal，这才是正确组合。

2.2 表结构设计的几个防坑细节

餐饮系统跟普通进销存系统有个显著区别：菜品的价格、名称可能会变。比如今天青椒炒肉卖 28 元，明天成本涨了，改卖 32 元。如果订单明细表的菜品名称和价格是去关联菜品表的，等到月底做财务分析时，查到订单明细的价格已经变成了菜品表里的新价格，就完全算不出"当时这单到底卖了多少钱"。

正确做法是订单明细表冗余存储下单时刻的菜品名称、菜品单价。也就是说，点菜时把当下的菜名和价格"快照"下来写进明细表。这样即使后续菜品更新，历史订单的数据依然是准确的。很多初级开发者不理解为什么表里要重复存一个"菜品名称"字段，这就是原因——不是冗余，而是业务快照。

另外建议在订单表和流水表都加上一个remark字段。餐饮场景里，客户可能会要求"少辣""不要香菜"，也可能会出现"顾客退了一道菜""老板朋友免单"这种非标操作。有个备注字段，财务对账时能少很多麻烦。

2.3 状态机设计：订单状态与流水状态的流转

很多新人在做状态字段时喜欢用随便定义的数字，1、2、3 各代表什么全凭写代码时的心情。这在财务系统里是个大忌。

我建议这样设计订单状态：

• 状态 0：待支付（下单成功，未收钱）
• 状态 1：已支付（收钱成功）
• 状态 2：已退单（整单取消）

支付流水状态：

• 状态 0：待支付（流水记录创建但未真正收款）
• 状态 1：支付成功
• 状态 2：支付失败 / 已退款

状态流转的规则必须固化：待支付只能变更为已支付或已退单，已支付不能直接变更为已退单（如果发生退款，应该走"退款流水"流程）。这些规则不宜只写在 Service 里靠 if 判断，最好在数据库层面用CHECK约束或者至少在设计文档中明确，因为多人协作时，别人改你代码很容易把状态机改乱。

3. 核心功能模块实现与实操过程

3.1 环境搭建与项目初始化

我以最常见的工程配置为例给你讲清楚：

1. 用 IntelliJ IDEA 创建 Spring Initializr 项目，Java 版本选 8 或 11 都行（如果本机是 JDK 17，SpringBoot 2.7.x 也兼容），SpringBoot 版本建议选 2.7.x 系列。为什么不是 3.x？3.x 要求 JDK 17 起跳，而且部分第三方整合（比如某些版本的金仓数据库驱动）可能还没适配完全，课设阶段没必要冒这个险。
2. 勾选依赖：Spring Web、MyBatis Framework、MySQL Driver、Lombok。如果需要做登录校验，自己加一个拦截器就够了，先不引 Spring Security，等基础功能跑通了再考虑增强。
3. 配置application.yml：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/db_restaurant_finance?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false username: root password: yourpassword jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: Asia/Shanghai mybatis: mapper-locations: classpath:mapper/*.xml type-aliases-package: com.example.restaurant.entity configuration: map-underscore-to-camel-case: true

这里有个很关键的配置：map-underscore-to-camel-case: true。它能把数据库里的create_time自动映射到 Java 实体的createTime字段，省去大量手写resultMap的麻烦。

启动类不需要改任何东西，默认的@SpringBootApplication注解就够了。

3.2 从菜品模块入手理解分层架构

很多人做项目喜欢先做登录，我反而建议先做菜单管理。原因很简单：登录模块涉及会话管理、权限控制、密码加密等一堆前置知识，而菜单模块就是一个纯粹的增删改查，用来理解项目的分层结构最合适。

以管理员新增菜品为例，请求链路是这样的：

Controller 接收参数 -> Service 处理业务 -> Mapper 操作数据库

Controller 层代码示例：

@RestController @RequestMapping("/dish") public class DishController { @Resource private DishService dishService; @PostMapping public Result<String> addDish(@RequestBody DishDTO dishDTO) { dishService.addDish(dishDTO); return Result.success("新增成功"); } }

Service 层代码示例：

@Service public class DishServiceImpl implements DishService { @Resource private DishMapper dishMapper; @Override @Transactional public void addDish(DishDTO dishDTO) { // 校验菜名是否重复 int count = dishMapper.countByName(dishDTO.getName()); if (count > 0) { throw new BusinessException("菜品名称已存在"); } Dish dish = new Dish(); BeanUtils.copyProperties(dishDTO, dish); dish.setStatus(1); dish.setCreateTime(LocalDateTime.now()); dishMapper.insert(dish); } }

很多刚接触分层的新人会有个疑问：为什么 Controller 不能直接调 Mapper？答案是：开发规范要求 Controller 只负责参数接收和结果封装，具体的业务规则（比如名称查重、状态判断）必须集中在 Service 层。这样做的好处是，如果你后面需要把 Service 对接到消息队列或者定时任务，业务逻辑可以复用，而不需要改 Controller。

注意：DTO（数据传输对象）和 Entity（实体类）一定要分开。前端传来的参数可能没有 id、创建时间这些字段，如果你直接用 Entity 接收，很容易造成类型不匹配或者脏数据写入。正确的做法是用 DTO 接收入参，然后手动或通过BeanUtils.copyProperties转换成 Entity 再落库。

3.3 下单结账：事务边界与并发控制的实战处理

下单是财务系统里最核心的交易操作，我来演示一个包含事务和并发处理的完整场景。

需求描述：收银员选择菜品（多个），系统计算总价，生成订单和订单明细，同时扣减库存（如果做了库存模块）。

Controller：

@PostMapping("/createOrder") public Result<String> createOrder(@RequestBody OrderDTO orderDTO) { // orderDTO 包含：桌号 tableNo、明细列表 detailList（菜品id + 数量） orderService.createOrder(orderDTO); return Result.success("下单成功"); }

Service：

@Override @Transactional(rollbackFor = Exception.class) public void createOrder(OrderDTO orderDTO) { // 1.生成订单主表记录 Orders order = new Orders(); order.setOrderNo(generateOrderNo()); order.setTableNo(orderDTO.getTableNo()); order.setEmployeeId(getCurrentUserId()); order.setStatus(0); // 待支付 order.setCreateTime(LocalDateTime.now()); orderMapper.insert(order); // 2.生成订单明细（这里涉及金额计算） BigDecimal totalAmount = BigDecimal.ZERO; for (OrderDetailDTO item : orderDTO.getDetailList()) { Dish dish = dishMapper.selectById(item.getDishId()); if (dish == null || dish.getStatus() == 0) { throw new BusinessException("菜品【" + item.getDishName() + "】已下架"); } OrderDetail detail = new OrderDetail(); detail.setOrderId(order.getId()); detail.setDishId(dish.getId()); detail.setDishName(dish.getName()); // 快照名称 detail.setDishPrice(dish.getPrice()); // 快照单价 detail.setNumber(item.getNumber()); detail.setAmount(dish.getPrice().multiply(BigDecimal.valueOf(item.getNumber()))); orderDetailMapper.insert(detail); // 累加总金额，注意BigDecimal不能直接用+号 totalAmount = totalAmount.add(detail.getAmount()); } // 3.更新主表总金额 order.setTotalAmount(totalAmount); orderMapper.updateById(order); }

这段代码里有两个非常值得展开的点。

第一，@Transactional(rollbackFor = Exception.class)中的 rollbackFor 为什么必须指定？Spring 的声明式事务默认只对运行时异常（RuntimeException）和 Error 回滚，对受检异常（Exception）不回滚。而在业务代码里，我们经常为了流程控制抛自定义异常，比如这里的BusinessException，如果它继承的是Exception而不是RuntimeException，默认情况下事务不会回滚，就会造成"明细插入成功了,主表更新失败了"这种数据不一致。所以这里有两条路：让自定义异常继承 RuntimeException，这是主流做法；或者明确指定 rollbackFor，做双保险。

第二，BigDecimal 计算必须使用方法调用而不是运算符。上面代码里totalAmount.add(detail.getAmount())返回的是新对象，必须重新赋值给 totalAmount，因为 BigDecimal 是不可变对象。如果你直接写totalAmount.add(detail.getAmount())而不接返回值，执行完后 totalAmount 依然是原来的值。我在代码评审里见人栽过这个跟头，而且金额算错了在测试阶段一般还发现不了，等月底对账时对不上账才追悔莫及。

关于并发控制，这部分对课设来说可能算进阶。但是我想提一个场景：同一道菜，A 收银员下单 3 份，B 收银员同时下单 2 份，如果做了库存扣减，就存在超卖风险。最简单的处理方式有两种：

• 在数据库层对这个菜品增加乐观锁版本号字段 version，更新时校验版本号。
• 更直接的方式是把库存也当成一行业务数据，在dish表里加stock字段，扣减时在 SQL 里带上条件UPDATE dish SET stock = stock - #{num} WHERE id = #{id} AND stock >= #{num}。如果受影响行数为 0，说明库存不足，抛异常回滚。

这个做法其实不用分布式锁，在单机事务里就解决了，非常推荐在中小型系统里使用。

3.4 财务统计报表：SQL聚合与时间分组

报表是财务系统最出彩的模块，做得好直接提升答辩和实际使用体验。

日营业额统计的核心 SQL：

SELECT DATE_FORMAT(pay_time, '%Y-%m-%d') AS day, SUM(pay_amount) AS total_amount, COUNT(*) AS order_count FROM payment_record WHERE pay_time BETWEEN #{startTime} AND #{endTime} GROUP BY DATE_FORMAT(pay_time, '%Y-%m-%d') ORDER BY day DESC

MyBatis Mapper 里直接写对应的 XML 映射就行。

菜品销售排行：

SELECT dish_name, SUM(number) AS total_sales, SUM(detail.amount) AS total_revenue FROM order_detail detail INNER JOIN orders o ON detail.order_id = o.id WHERE o.status = 1 -- 已支付的订单才算入营收 GROUP BY dish_name ORDER BY total_revenue DESC LIMIT 10

这里有个容易忽略的地方：统计营收时一定要关联订单状态。如果订单被退掉了（状态是已退单），它的明细流水就不应该进入统计。很多人写报表时没有这个意识，直接统计所有明细，结果老板看了报表发现"我怎么做了这么多单，钱没收到那么多"。这种低级错误在答辩时被发现是很尴尬的。

再来一个按小时统计营业额的 SQL 片段，为了让老板看出哪个时段是客流高峰：

SELECT HOUR(pay_time) AS hour_of_day, SUM(pay_amount) AS total_amount FROM payment_record WHERE DATE(pay_time) = #{targetDate} GROUP BY HOUR(pay_time)

统计模块的参数穿透建议用 Map 类型接收，因为查询条件组合多、字段不定，用一个专门的 DTO 也要写一堆字段。规整一点的建议：定义ReportQueryDTO包含 startTime、endTime、date 等，然后用@Param传入 Mapper，这样比 Map 更可读。

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

4.1 金额显示不对，数据差几分几毛

这可能是财务系统开发里最让人崩溃的 Bug。排查思路应该按以下顺序：

1. 检查数据库字段类型。如果你用的是double或float，立刻改成DECIMAL(10, 2)，这是根子上的修复。
2. 检查 Java 实体字段类型。对应的实体属性必须用BigDecimal，不能用Double。
3. 检查前端有没有做浮点数运算。如果前端把单价、数量相乘后再传给后端，可能存在精度丢失。正确的做法是前端只传菜品id + 数量，由后端统一计算金额，前端只负责展示，绝不参与金额运算。
4. 检查 JSON 序列化配置。BigDecimal序列化为 JSON 时，如果没配好可能变成科学计数法或者精度丢失。在application.yml里配好 Jackson 的big-decimal相关策略即可，或者统一用字符串传输金额。

4.2 事务不生效，插入成功但更新失败

现象是：下单时明细插入成功，但主表更新失败，数据对不上。

排查思路：

1. 检查是否有自调用。在同一个类内部this.createOrder()调用另一个@Transactional方法，Spring 的 AOP 代理失效，事务不生效。这是最常见的坑。解决办法是把事务方法放到另一个 Service 类中，或者自行注入自己的代理。
2. 检查事务方法是否被 final 修饰。Spring 默认使用 CGLIB 代理，final 方法无法被重写和增强，事务不会生效。
3. 检查异常是否被吞掉。如果你在 catch 里捕获了异常但没有继续抛出，Spring 感知不到异常发生，事务自然不回滚。
4. 检查数据库引擎。如果表用的是 MyISAM，是不支持事务的。必须用 InnoDB。这个在 MySQL 8.0 默认已经是 InnoDB，但如果是接手老库要特别注意。

4.3 日期统计差 8 小时，时区问题排查

统计报表时发现"今天的订单出现在昨天"或者"凌晨数据算到前一天"。这种问题多半是时区导致的。

MySQL 连接串里加serverTimezone=Asia/Shanghai，Jackson 配置time-zone: Asia/Shanghai，这是两个必须做的配置。另外在 Java 代码里，LocalDateTime.now()取的是系统默认时区，如果部署环境的系统时区不对，也会导致日期偏差。运维层面直接把服务器时区设为 CST（China Standard Time）能避免很多底层的诡异问题。

4.4 项目结构混乱，包名命名不规范

我见过一些大作业，Controller、Service、Mapper 全部塞在一个包下，代码动辄几千行，类名从TestController到TestController2。这其实不是技术问题，而是工程素养问题。

推荐的结构如下：

com.example.restaurant ├── controller # 接口层 ├── service # 业务层接口 ├── service.impl # 业务层实现 ├── mapper # MyBatis Mapper接口 ├── entity # 数据库实体类 ├── dto # 数据传输对象 ├── vo # 视图对象（返回给前端展示用） ├── common # 通用类（Result、异常、常量） ├── config # 配置类（拦截器、WebMvc配置） └── RestaurantApplication.java

这个分层不是拍脑袋定的，每一层都有明确的职责边界。Controller 只做接收和返回；Service 做业务规则；Mapper 做数据访问。答辩时老师问"你项目怎么分层的"，你按这个结构说，条理清晰，基本能拿高分。

4.5 SpringBoot 版本太高导致的依赖兼容问题

最近很多同学用的 IDEA 和 Spring Initializr 默认生成 SpringBoot 3.x 项目，结果整合 MyBatis 时发现mybatis-spring-boot-starter版本对不上，或者整合某些数据库驱动时缺包。我的经验是：

• 如果本地 JDK 是 17 甚至 21，用 SpringBoot 3.x 配套 MyBatismybatis-spring-boot-starter 3.0.x版本。
• 如果本地 JDK 是 8，老老实实选 SpringBoot 2.7.x。
• 遇到奇怪的依赖问题，先看 Maven 依赖树里有没有版本冲突。

4.6 打包部署后前端访问不到接口

这个坑通常是跨域问题和静态资源位置问题。

跨域方面，如果前端vue项目在开发环境跑在 5173 端口，后端 8080 端口，两边端口不一致必然触发跨域。后端的处理方式是在配置类里实现WebMvcConfigurer的addCorsMappings方法，或者加一个@CrossOrigin注解。不过要注意，如果后续引入 Spring Security，跨域配置还需要配合 Security 的 Filter 链，否则一样会被拦下来。

静态资源方面，Vue 打包后的dist目录里的index.html、static文件夹可以直接扔进 SpringBoot 项目的src/main/resources/static目录下，启动后访问http://localhost:8080/index.html就能看到页面了。这算是把前后端揉在一起部署的最土但最有效的方式，适合课设和小型项目。

5. 项目扩展与工程化细节补充

5.1 引入 Redis 缓存菜品列表

菜品列表是餐饮系统里高频访问的数据。每次点菜页面刷新都要查一次数据库，高峰期可能一两百个请求同时打过来，数据库压力虽然不至于挂掉，但响应速度会变慢。针对这种读多写少的场景，加 Redis 缓存效果立竿见影。

实现思路其实很简单：查询菜品列表时，先查 Redis，缓存没有再去数据库查，然后把结果回填到 Redis，设置过期时间（比如 30 分钟）。

@Autowired private StringRedisTemplate redisTemplate; // 缓存菜品列表 List<Dish> dishList = dishMapper.selectList(); String json = JSON.toJSONString(dishList); redisTemplate.opsForValue().set("dish:list", json, 30, TimeUnit.MINUTES);

在新增、修改、删除菜品时主动删除对应的缓存 key，保证下次查询能拿到最新数据。

redisTemplate.delete("dish:list");

这里有个注意事项：缓存数据序列化时建议用 JSON，因为字符串格式便于排查问题，不要直接用 JDK 序列化，否则在 Redis 可视化工具里看到的是一堆乱码，排查问题非常痛苦。

5.2 定时任务实现凌晨自动对账

财务系统的另一个日常操作是每天凌晨核对前一天的账单。这种重复性工作让系统自动做最合适。SpringBoot 里内置了@Scheduled定时任务注解，使用简单。

启动类加@EnableScheduling开启调度功能，然后编写定时任务：

@Component public class FinanceCheckTask { @Scheduled(cron = "0 5 0 * * ?") // 每天凌晨 0:05 执行 public void checkYesterdayFinance() { LocalDate yesterday = LocalDate.now().minusDays(1); // 统计昨日实收金额 BigDecimal actualAmount = paymentMapper.sumAmountByDate(yesterday); // 统计昨日订单金额 BigDecimal orderAmount = orderMapper.sumOrderAmountByDate(yesterday); // 比较两个金额，不一致则生成告警记录 if (actualAmount.compareTo(orderAmount) != 0) { alertMapper.insert(...); } } }

注意 Cron 表达式使用 6 位格式（秒 分 时 日 月 周），这个比较容易写错。在本地测试时可以把表达式临时改成每 10 秒执行一次（0 */10 * * * ?），验证无误后再改回正式的。

提示：定时任务的日志一定要打清楚，尤其记录"执行了没、数据对不对"。财务系统最怕的是"静默失败"，定时任务看似跑了，实际因为某条数据异常提前抛异常中断了，后续逻辑全没执行。建议在每个关键步骤后加log.info输出统计结果。

5.3 拦截器实现登录鉴权

做财务系统不做登录鉴权等于裸奔。哪怕是一个课设，老师也会关注权限设计。用 SpringBoot 的拦截器可实现一个轻量级方案：

1. 用户登录成功后，把用户id存到 Session 中。
2. 定义一个拦截器类LoginInterceptor实现HandlerInterceptor。
3. 在preHandle里检查 Session 是否有用户，没有则返回未登录 JSON。
4. 注册拦截器时，排除登录接口、静态资源路径。

@Component public class LoginInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { HttpSession session = request.getSession(); Object userId = session.getAttribute("empId"); if (userId == null) { response.setContentType("application/json;charset=utf-8"); response.getWriter().write("{\"code\":401,\"msg\":\"未登录\"}"); return false; } return true; } }

注册配置：

@Configuration public class WebConfig implements WebMvcConfigurer { @Resource private LoginInterceptor loginInterceptor; @Override public void addInterceptors(InterceptorRegistry registry) { registry.addInterceptor(loginInterceptor) .addPathPatterns("/**") .excludePathPatterns( "/employee/login", "/dish/list", "/index.html", "/static/**" ); } }

这个方案虽然简单，但不难讲清楚原理：拦截器本质上是 Spring MVC 提供的 AOP 切面机制，在 Controller 执行前进行通用逻辑处理。从这道题延伸出去，你能在面试时聊到 Spring Boot 中 AOP 的使用场景、过滤器和拦截器的区别，这就算把这个项目吃透了。

5.4 关于多数据源：如果财务系统对接第三方支付平台报表

有些餐饮门店现在不只是现金和扫码收款，还接入了美团、饿了么外卖平台的订单流水。如果你想把这个项目做得更完整、更贴近真实业务，可以引入多数据源的概念——一份数据源是本地 MySQL，另一份通过调用第三方商户平台的开放接口同步订单数据。

不过这里我要提醒一点：项目开发要按需求来，不要为了用技术而加复杂度。如果题目要求里面没有明确涉及第三方平台对接，那么把本地数据库的账算清楚已经足够拿高分。多数据源、分布式事务这些属于加分项而不是必选项，贪多嚼不烂反而会让项目中途卡住。

几点踩坑后的实在建议

最后写几句我自己的体会，送给正在做这类项目的同学。

做餐饮财务管理系统，技术难点其实不在"会不会配置 SpringBoot"，而在于你有没有把"业务流程"想清楚。我亲眼见过很多人代码写得挺熟练，但问他"订单状态怎么流转""退款怎么处理"就支支吾吾。这些业务问题才是财务系统的灵魂。

第一次做的时候，我建议你把思维重心放在这两件事上：一是把金额相关的每一个字段都较真到底，BigDecimal 用对、单位统一、JSON 序列化配置好；二是把一个核心业务（比如下单结账）的完整链路从 Controller 到 Mapper 一竿子打通。只要这两个基础稳住了，后面的报表、权限、缓存都是顺手的事。至于 SpringBoot 版本选高还是选低、要不要用 Spring Security、要不要拆分前端项目，这些永远是次要问题，最重要是先把整个闭环跑起来。

如果在实操过程中遇到代码报错、依赖冲突、数据库连接不上的问题，优先看控制台完整异常栈，自己先尝试定位，然后再去搜具体异常信息。解决完顺手记到自己的排错笔记里。项目做完，你会发现收获最大的不是那几十个文件，而是你脑子里那套能迁移到下一项目的排错直觉。