Spring Boot实战：从零构建物业管理系统，解析状态机与幂等设计

最近把一个小区物业管理系统从零到一完整搭了出来，代号lsm73，技术栈以Spring Boot为主，覆盖物业报修、缴费、车位管理三大核心业务模块。整套系统做下来，踩了不少坑，也积累了一些比较实在的经验。这篇文章就把整个项目的设计思路、模块落地方式和实战中遇到的高频问题完整梳理一遍，给准备做同类管理系统，或者正在用Spring Boot做业务系统的人一个可参考的样本。

这套系统面向的是中小型物业公司，核心痛点很典型：报修靠电话和纸质工单，跟进靠催；缴费靠人工登记，对账靠Excel；车位信息分散在多个表格里，租赁和到期状态经常对不上。lsm73就是把这三件事全部线上化，从报修提交、派单处理、完工验收，到账单生成、线上支付、销账对账，再到车位绑定、租期管理、到期提醒，形成完整的业务闭环。

适合来看这篇文章的人有两类。一类是准备做类似物业、后勤、园区管理系统的开发者，另一类是刚接触Spring Boot项目、想了解一个真实业务系统怎么从设计到落地的初学者。文章里的代码片段、表结构、配置和排查思路，都是可以直接拿来改一改就用的。

1. 项目整体设计与技术选型

1.1 业务需求拆解：管理系统不只是CRUD

做任何系统之前，先别急着写代码。lsm73的需求拆解阶段花了整整两天，把物业公司的实际工作流程全部捋了一遍，最后归纳成三个核心角色和一条主链路。

三个角色分别是：业主端（小程序/H5提交报修、查账单、缴费用、看车位）、物业端（Web后台，接单派单、生成账单、管理车位）、管理员端（系统配置、角色权限、数据统计）。这是典型的前后端分离结构，也是现在Spring Boot项目最常见的形态。

主链路是：业主提交报修 → 系统通知物业客服 → 客服派单给维修工 → 维修工上门处理并回填结果 → 业主验收确认 → 工单归档。缴费链路相对独立：系统按周期生成账单 → 业主收到待缴通知 → 在线支付 → 支付回调更新订单状态 → 财务对账。车位链路是：车位信息维护 → 业主申请租赁/续费 → 账单联动 → 到期自动释放。

这个拆解过程看起来常规，但价值在于：它决定了后面所有表结构的边界。比如报修状态机，一开始只设计了“待处理、处理中、已完成”三个状态，后来实际调研发现维修工上门后可能发现不在家需要改约，业主可能对维修结果不满意需要返工，最终扩展成了“待接单、处理中、待验收、已完成、已关闭、待返工”六态流转。如果一开始不把状态机设计清楚，后期再加状态，涉及的代码改动量会翻好几倍。

1.2 技术选型：Spring Boot版本、ORM、缓存、前端脚手架

技术栈的选择是这个项目里值得重点讲的部分。Spring Boot版本我选的是2.7.18，而不是最新的3.x。原因很实际：项目目前的生产环境JDK是1.8，Spring Boot 3.x强制要求JDK 17及以上，升级JDK意味着所有运维脚本、监控组件、中间件客户端都要一起验证，成本远大于收益。Spring Boot 2.7还在社区维护期内，要用的组件都兼容，够稳。

这里给个通用建议：新项目如果JDK版本可以自由决定，可以从Spring Boot 3.x开始；但如果生产环境还是JDK 8，别硬上。热搜里那么多“springboot版本太高”相关的问题，大多数都是因为版本和JDK、第三方组件不匹配导致的。

ORM层面用的是MyBatis-Plus，而不是JPA或原生MyBatis。原因有两个：一是物业管理系统里有大量复杂查询，比如多表关联查车位缴费记录、报表统计，MyBatis对SQL的掌控力更强；二是这类型项目业务字段变动频繁，生成IService、ServiceImpl这类BaseCRUD能省掉大量重复的增删改查代码。

缓存用了Redis，在三个位置发挥作用：验证码存储、缴费账单热点数据、车位状态实时查询。这个后面专门讲。

前端是Vue 3 + Element Plus，没有用重型低代码平台，因为物业公司会后期不断提需求，前端代码自己掌控更灵活。前后端通过JWT做身份认证，接口统一走/api前缀。

2. 数据库设计与核心模块落地

2.1 表结构设计：几张大表的核心字段规划

数据库设计是整个项目的地基，直接用示例说话。以下是几张核心表的关键字段，有实际参考价值。

业主表大概长这样：

sql复制CREATE TABLE `owner_info` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `owner_name` varchar(50) NOT NULL COMMENT '业主姓名',
  `phone` varchar(20) NOT NULL COMMENT '手机号',
  `building` varchar(20) DEFAULT NULL COMMENT '楼栋号',
  `unit` varchar(20) DEFAULT NULL COMMENT '单元号',
  `room` varchar(20) DEFAULT NULL COMMENT '房号',
  `id_card` varchar(18) DEFAULT NULL COMMENT '身份证号(加密存储)',
  `status` tinyint(4) DEFAULT '1' COMMENT '1正常 0冻结',
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `idx_phone` (`phone`),
  KEY `idx_room` (`building`,`unit`,`room`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

报修单表的核心不只是字段，而是状态机的设计：

sql复制CREATE TABLE `repair_order` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `order_no` varchar(32) NOT NULL COMMENT '报修单号',
  `owner_id` bigint(20) NOT NULL COMMENT '业主ID',
  `repair_type` tinyint(4) DEFAULT NULL COMMENT '1水电 2门窗 3管道 4家电 5其他',
  `description` varchar(500) DEFAULT NULL COMMENT '问题描述',
  `image_urls` text COMMENT '图片地址,逗号分隔',
  `status` tinyint(4) DEFAULT '1' COMMENT '1待接单 2处理中 3待验收 4已完成 5已关闭 6待返工',
  `assignee_id` bigint(20) DEFAULT NULL COMMENT '维修工ID',
  `appoint_time` datetime DEFAULT NULL COMMENT '预约时间',
  `finish_time` datetime DEFAULT NULL COMMENT '完工时间',
  `evaluate_score` tinyint(4) DEFAULT NULL COMMENT '评价分数',
  `create_time` datetime DEFAULT CURRENT_TIMESTAMP,
  `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`id`),
  KEY `idx_owner_id` (`owner_id`),
  KEY `idx_status` (`status`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这类表设计有三个关键点。

第一，状态字段一定要用int或tinyint，不要用字符串。字符串状态在后端枚举和前端下拉框的映射上非常痛苦，而且到处散落的魔法值一定会在某个角落因为大小写不一致导致bug。项目里所有状态都对应一个Java枚举，前后端传值统一用数字。

第二，订单号要单独设计。不要用数据库自增ID直接展示给用户，既暴露业务量，也容易被遍历。订单号格式是类型前缀+年月日+流水号，例如BX20250101001，通过Redis的INCR实现日内自增。

第三，所有金额字段用decimal(10,2)，不要用float/double。浮点计算在金额场景下一定会出精度问题，这个是底线级的规则。

2.2 报修模块：从提交到归档的完整状态闭环

报修模块是整个系统里逻辑最复杂的部分，因为它的状态流转不是单线，而是有分支的。

以“业主报修灯具损坏”为例，完整流程是这样的：业主在小程序填写描述、上传照片，系统生成order_no，状态置为待接单。物业客服在后台看到新工单，根据维修类型分派给对应维修工，状态变更为处理中，同时给维修工推送通知。维修工点击“上门维修”，需要先查看预约时间，如果和业主时间冲突，可以操作“改约”，此时状态不变化，但会记录改约时间和原因，通知业主重新确认。维修完成后维修工填写维修结果，上传完工照片，状态变更为待验收。业主收到通知后确认无误，点击验收，状态变为已完成，同时可以打分和评论。如果业主对维修结果不满意，选择驳回，状态变为待返工，系统自动重新分配给原维修工。超过48小时未处理且无人接单的工单，系统通过定时任务自动提醒客服。

这个状态机的实现，核心是定义一个枚举类，把每种状态能执行的操作和能跳转到的状态都显式声明出来：

java复制public enum RepairStatus {
    PENDING(1, "待接单"),
    PROCESSING(2, "处理中"),
    PENDING_ACCEPTANCE(3, "待验收"),
    COMPLETED(4, "已完成"),
    CLOSED(5, "已关闭"),
    REWORK(6, "待返工"),
    // 校验当前状态能否执行指定操作
    public boolean canTransitTo(RepairStatus target) {
        // 状态跳转合法性判断
    }
}

这样做的好处在于：所有状态跳转的合法性判断集中在枚举里，服务层调用时只需要一行canTransitTo，不会出现状态满天飞的情况。我见过太多项目把状态判断散落在各个if-else里，后面维护的人根本不敢动。

2.3 缴费模块：账单生成、支付对接与对账幂等

缴费模块的核心难点在两点：一是账单怎么生成，二是支付回调怎么保证幂等。

账单生成用Spring Boot内置的@Scheduled定时任务，每月1日凌晨2点批量生成当月物业费账单。这里的SQL不是简单的全表插入，而是用INSERT...SELECT一条语句搞定：

sql复制INSERT INTO payment_bill (owner_id, bill_type, amount, period, status, create_time)
SELECT id, 1, calculate_amount(o.id), DATE_FORMAT(NOW(), '%Y-%m'), 1, NOW()
FROM owner_info o
WHERE o.status = 1;

用户一次性预缴全年的话，amount会有折扣，这个折扣规则用策略模式实现，把“按月计费”“按年折扣”“临时公摊”分不同策略类，避免大段的if-else堆积在service里。

在线支付对接的是微信支付Native支付。这里有一个特别容易被忽略的细节：支付回调接口的幂等性处理。微信支付成功后回调通知，网络可能会重发多次，如果不做幂等处理，会导致同一张账单被重复标记为已支付。

幂等处理的正确姿势是这样：

java复制@Transactional
public void handlePayCallback(String orderNo, String transactionId) {
    PaymentBill bill = paymentBillMapper.selectByOrderNo(orderNo);
    // 关键检查：已经支付过的账单直接返回，不重复更新
    if (bill != null && bill.getStatus() == 2) {
        return;
    }
    // 更新账单状态为已支付
    // 同时更新关联的车位租期或报修单状态
}

这个方法里必须有事务，并且要先查再更。如果在并发场景下，还需要配合数据库的唯一索引或分布式锁做兜底。这样一个简单的“查再更”设计，实际上杜绝了回调重发导致的重复入账、重复销账问题。

2.4 车位管理：租赁时长、费用联动与到期自动释放

车位管理的业务逻辑看起来简单，但真正做起来比想象中繁琐。业务规则是这样的：每个车位绑定一个业主，租期按月计算，到期前7天系统自动给业主发提醒，到期后如果没有续费，车位自动释放回可租状态。车位有固定车位和临时车位两种，固定车位按月收租金，临时车位按小时收。

这里最容易翻车的地方是“费用联动”。业主续租车位后，系统要自动生成一张车位租金账单，连到缴费模块；而业主缴完费后，车位租期要自动延长。这个过程是跨模块的，靠什么保证一致性？

方案是：续租操作只做一件事——记录租期变更记录，状态置为待支付。真正延长租期的动作放在支付回调里。意思就是，业主申请续租后，租期不会立刻变，等支付成功回调触发后，才真正把expire_time往后延。这样的好处是：如果业主申请了但没付钱，车位状态不会乱。

车位到期自动释放用定时任务扫描：

java复制@Scheduled(cron = "0 10 0 * * ?")
public void releaseExpiredParking() {
    // 扫描所有租期到期且未续费的车位
    // 状态改为可租，清理绑定关系
    // 同时记录一条日志
}

这套设计跑下来，最深的感触是：业务状态不应该单独存储，而应该通过“动作”来驱动。只要把每一个动作对应的状态变更想清楚了，很多所谓的并发问题、数据不一致问题自然而然就消失了。

3. 工程化实践与Spring Boot核心机制

3.1 统一响应、全局异常与参数校验

写Spring Boot项目，如果不在一开始就做好统一响应和全局异常处理，后面接口会乱到没法看。lsm73从一开始就定了规范：所有接口返回统一包装类。

java复制@Data
public class Result<T> {
    private Integer code;
    private String message;
    private T data;
    
    public static <T> Result<T> success(T data) {
        Result<T> result = new Result<>();
        result.setCode(200);
        result.setMessage("success");
        result.setData(data);
        return result;
    }
    
    public static <T> Result<T> error(String message) {
        Result<T> result = new Result<>();
        result.setCode(500);
        result.setMessage(message);
        return result;
    }
}

配合@RestControllerAdvice做全局异常捕获。业务异常、参数校验异常、系统异常分开处理，避免把堆栈信息直接返回给前端。这里有个小细节是：不要把系统内部异常信息直接暴露出去。全局异常处理器捕获Exception后，返回给前端的信息是“系统繁忙，请稍后重试”，但完整堆栈记录在日志里。这样既保护了系统细节，也方便排查问题。

参数校验用javax.validation的@Validated注解配合@NotBlank、@Size这些约束注解。比如报修提交接口：

java复制@PostMapping("/repair")
public Result<Long> submitRepair(@RequestBody @Validated RepairSubmitDTO dto) {
    // 业务逻辑
}

这样的写法，参数校验失败会由全局异常处理器统一返回400和具体错误信息，不用在业务代码里写一堆if判断。这类工程化规范，是项目上线后最值得投入的部分，能省后续大量的联调和排错时间。

3.2 Spring Boot自动装配原理在项目里的实际应用

这个项目里有一个自己写的组件，就是自动上报服务健康状态到运维平台的模块。当时想的就是把这个能力做成一个Spring Boot Starter风格的组件，以后其他项目也能直接引用。

Sprng Boot的自动装配核心是@EnableAutoConfiguration注解，它通过SpringFactoriesLoader机制加载META-INF/spring.factories或org.springframework.boot.autoconfigure.AutoConfiguration.imports文件里配置的自动配置类。

在这个项目里，我写了一个HealthReportAutoConfiguration，通过@ConditionalOnProperty注解控制开关，配置了report.enabled=true才生效。组件内部自动注入RestTemplate，定期上报JVM内存、线程数、接口QPS到监控平台。整个过程用户只引入一个依赖、加一行配置，就能拿到完整能力，不需要写任何业务代码。

这部分用到的Spring Boot核心注解大概有这些。

• @SpringBootApplication：组合了@SpringBootConfiguration、@EnableAutoConfiguration、@ComponentScan三个注解。
• @ConditionalOnClass / @ConditionalOnMissingBean：条件装配，某个类存在或缺失时才生效。
• @ConfigurationProperties：把配置文件里的属性绑定到Java对象。

如果一个项目的配置项超过5个，建议直接做成@ConfigurationProperties类，不要用@Value一个个注入。在idea里配置application.yml不提示的问题，通常就是因为没有引入对应的configuration-processor依赖或者没有使用@ConfigurationProperties。

3.3 事务失效场景与循环依赖的实际排查记录

项目联调阶段遇到过一个特别隐蔽的问题：缴费成功回调里更新账单和延长车位租期，有时候车位租期没更新但账单变成已支付了，而且只有特定条件才会复现。查了半天，最后定位是事务失效问题。

java复制@Service
public class PaymentService {

    @Transactional
    public void paySuccess(String orderNo) {
        updateBill(orderNo);
        // 在这里调用了同类中的另一个方法
        this.extendParkingLease(orderNo);
    }

    @Transactional
    public void extendParkingLease(String orderNo) {
        // 更新车位租期
    }
}

问题就在这里。Spring的@Transactional基于AOP代理，通过代理对象调用方法时才会套上事务。同类内部直接this.extendParkingLease()调用的是原始对象的方法，并没有经过代理，所以extendParkingLease上的@Transactional没有生效。当第二个方法异常时，第一个方法因为已经提交，账单已支付，但车位租期回滚了，数据就不一致了。

解决办法有两种：一是把extendParkingLease拆到另一个Service里，通过注入的代理对象调用；二是自己注入自身代理，例如@Autowired private PaymentService paymentService;然后通过paymentService.extendParkingLease()调用。推荐第一种，拆分Service更符合单一职责，也更容易测试。

循环依赖问题也碰到过一次。最早代码里用户Service和权限Service互相注入，启动时提示The dependencies of some of the beans in the application context form a cycle。Spring Boot 2.6之后默认禁止循环依赖，这个是好事。解决办法是重新梳理依赖方向，把公共逻辑下沉到一个独立的Service里，两个Service只依赖这个公共Service，循环自然而然就没了。

这两个问题在Spring Boot面试题里都是高频考点，但真正在项目里遇到时才知道它们的破坏力有多大。

4. 缓存、权限与性能优化实战

4.1 Redis在项目里的三个核心应用场景

Redis在这个项目里不是点缀，是实实在在解决业务问题的。

第一个场景是验证码存储。登录和业主注册时候的短信验证码，用Redis存储，key格式是captcha:{phone}，有效期5分钟，验证后立即删除。这个比直接存数据库快，也天然支持过期自动失效。

第二个场景是缴费账单的查询。业主查询缴费记录的时候，如果每次都查MySQL，随着数据量增大和并发上涨，数据库压力会很大。这里用了Redis缓存，设计思路是：业主最近一个月的账单列表放缓存，key格式是pay:list:{ownerId}，有效期30分钟；业主的账单详情数据放缓存，key格式是pay:detail:{orderNo}，有效期15分钟。MySQL中账单状态更新后，通过先更新数据库再删除缓存的方式来保证一致性。虽然删缓存也有极端情况下的并发问题，但在这个业务场景下完全够用。

第三个场景是车位状态的实时查询。小区车位可能有几百个，每个月固定车位、临时车位、空闲车位数量是物业管理大屏上最常看的数据。这里把车位统计分析结果缓存起来，key格式是park:stats，有效期10分钟。这样即使用户频繁刷新大屏，也不会打到MySQL。

还有一个细节是Redis的key统一加业务前缀，使用冒号分隔。这个习惯可以避免不同业务之间的key冲突，也方便通过Redis Desktop Manager按前缀模式批量查找定位数据。

4.2 登录鉴权与菜单角色管理的设计

权限管理用的是典型的RBAC模型，五张表：用户表、角色表、菜单表、用户角色关联表、角色菜单关联表。不同于之前的业主端（业主用手机号登录），管理端的用户是物业公司内部员工，权限要求更严格。

登录鉴权的方案是JWT + Spring拦截器。用户登录成功返回一个token，前端每次请求把token放在Authorization头里，后端通过拦截器统一校验。

java复制@Component
public class JwtInterceptor implements HandlerInterceptor {

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        String token = request.getHeader("Authorization");
        // 解析token，校验合法性
        // 从token中取出userId和角色信息，存入ThreadLocal
        // 校验通过返回true，否则返回401
    }
}

关键点是：拦截器只做认证，权限判断用注解。后端在每个Controller接口上标注@RequiresPermission("repair:handle")这样的注解，通过AOP切面判断当前用户是否拥有对应权限。这样权限粒度可以控制到按钮级别，比如物业客服能“分派”报修单但没有“关闭”报修单的权限。热词里“springboot菜单角色管理”这个搜索需求对应的就是这个模块，核心就是要做动态菜单，前端登录后根据后端返回的菜单树动态渲染路由，用户没权限的功能在界面上根本不显示。

4.3 报表统计场景的SQL优化

物业系统做了两个统计报表：月度缴费率统计、维修工工单量排行。最初版本报表查询响应慢，数据量几万行的时候就要好几秒。

排查后发现，问题时SQL里对账单表的查询用了status = 2 AND period = ?，但复合索引只有(status)单独一个字段，导致这个查询走了全表扫描。

优化方案很简单，创建一个复合索引idx_period_status(period, status)，在where条件中同时使用这两个字段时，MySQL可以命中这个索引范围扫描，响应时间从秒级降到毫秒级。

另外一点的优化是，月度统计没必要实时查明细表。项目里加了一个monthly_bill_stat统计表，每月账单生成完跑一次统计任务，把每栋楼、每个月的应收金额和已收金额预聚合。前端报表直接查统计表即可。这是一种典型的用空间换时间的思路，非常适合报表这类读多写少、聚合计算有规律可循的场景。

5. 部署上线与常见问题排查

5.1 Docker部署Spring Boot项目的完整流程

项目部署用的是Docker，整体流程不复杂，但有几个细节值得记录。

首先要准备Dockerfile。Spring Boot项目打包成jar后，用多阶段构建来减小镜像体积：

dockerfile复制FROM maven:3.8-jdk-8 AS builder
WORKDIR /app
COPY pom.xml .
RUN mvn dependency:resolve
COPY src ./src
RUN mvn clean package -DskipTests

FROM openjdk:8-jre-alpine
WORKDIR /app
COPY --from=builder /app/target/lsm73.jar ./app.jar
EXPOSE 8080
ENTRYPOINT ["java", "-jar", "app.jar"]

第二步是处理配置文件。不要把application.yml打包进镜像，而是挂载外部配置文件。Docker运行的时候用-v /config:/app/config把宿主机配置文件挂载进去，然后通过--spring.config.location=/app/config/指定。这样修改配置不需要重新构建镜像，回滚也方便。

有一个在JDK 1.8打包到Docker Desktop时经常踩的坑：Docker构建环境里用maven:3.8-jdk-8，Maven会默认去中央仓库下载依赖，网络差的时候非常慢。解决办法是配置阿里云镜像仓库，并且在Dockerfile里先COPY pom.xml再执行mvn dependency:resolve，这样依赖层会被Docker缓存，之后改代码重新构建，不会重下依赖，速度能提升非常多。

5.2 线上环境容易踩的坑和排查清单

项目上线之后，自己也整理了几个高频问题的排查速查记录，分享出来。

第一个问题是IDEA中application.yml不提示。原因一般是缺少配置处理器依赖。在pom.xml加下面这个依赖，重启IDEA后就能正常提示了。

xml复制<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-configuration-processor</artifactId>
    <optional>true</optional>
</dependency>

第二个问题是Spring Boot连接MySQL时报时区错误。连接URL里必须加serverTimezone=Asia/Shanghai，同时JDBC驱动版本要和MySQL版本匹配。MySQL 8.0要用com.mysql.cj.jdbc.Driver，而不是老的com.mysql.jdbc.Driver。

第三个问题是第三方接口调用超时。项目中对接了微信支付、短信服务商等多个外部接口，RestTemplate如果不设置连接超时和读取超时，网络抖动时整个请求线程可能挂几分钟。正确的做法是通过Bean配置明确超时时间：

java复制@Bean
public RestTemplate restTemplate() {
    SimpleClientHttpRequestFactory factory = new SimpleClientHttpRequestFactory();
    factory.setConnectTimeout(3000);
    factory.setReadTimeout(10000);
    return new RestTemplate(factory);
}

第四个问题是资源映射。物业系统后台需要上传小区公告图片、报修图片等文件，文件上传后要能通过URL访问。这个通过自定义静态资源映射解决，把本地上传目录映射到/files/**路径。

java复制@Configuration
public class WebConfig implements WebMvcConfigurer {
    @Override
    public void addResourceHandlers(ResourceHandlerRegistry registry) {
        registry.addResourceHandler("/files/**")
                .addResourceLocations("file:" + fileUploadPath);
    }
}

这里要特别注意file:前缀不能丢，否则Spring会把它当成classpath路径解析。

5.3 单元测试的落地实践

项目里单元测试早期几乎是空白，后面才开始补。这个也值得单独说一嘴。Spring Boot项目里，单元测试最佳实践不是把整个Spring容器拉起来测，而是用@WebMvcTest、@DataJpaTest这种切片测试，只加载需要的层，跑起来快，也更聚焦。

本项目Controller层的测试用MockMvc配合Mockito，直接mock掉Service层，测试接口的入参校验、状态码和返回结构。Service层的核心业务逻辑测试重点覆盖状态机流转和幂等逻辑，比如同一笔支付回调连续调用两次，第二次必须直接返回不重复更新。

这里有个经验：单元测试代码的价值不只在验证正确性，更是强制你写出可测试的代码。如果发现某段逻辑很难写测试，那通常说明代码结构有问题，比如类职责太重、方法耦合太多，应该考虑拆分而不是硬着头皮把测试绕过。

6. 最后分享几个项目中的个人心得

整个lsm73项目从设计到上线，最有价值的东西反而不是Spring Boot本身的API用法，而是如何把业务规则准确地翻译成代码结构。状态机枚举、跨模块一致性设计、幂等处理，这些才是决定系统稳定性的关键。

我个人在实际操作中的体会是，这类管理系统的开发节奏，从来没有一步到位的完美设计，只能通过不断交付和迭代让模型越来越贴合真实业务。如果你也在做一个类似的系统，建议先把状态流转和费用联动两张图理顺，明确每一个操作会改变哪些数据，再动手写代码。方向对了，写代码就是一路顺水推舟的事。

最后再分享一个小技巧：项目里所有枚举状态字段，建议在数据库加一个注释，在Java枚举里也加注释，同时提供文本说明的JSON接口，方便前端直接拉取下拉选项。这样前后端的沟通成本能降一大截，也避免前后端对状态含义理解不一致导致的各种莫名其妙的问题。