上一个接单季帮人跑过几个类似的物业管理系统说实话这类项目的核心不在功能多全而在“报修闭环”和“车位预约并发”这两块能不能讲清楚。今天拿这套“Spring Boot Java 小区物业管理系统”做个完整复盘从模块设计、技术选型到部署答辩一条线捋下来。你要是准备毕设答辩、或者打算把这类项目写进简历这篇能帮你省不少时间。先说给谁看用这套题目做毕业设计的学生、正在整理Java项目经验的初级开发还有想在培训作业里拿个高分的同学。系统本身不复杂就是业主端报修、物业端派单、停车位在线预约这三条主线加一个后台管理壳子。但它覆盖了Java后端开发最常见的几个考核点CRUD、状态机流转、权限控制、并发防超卖这些恰好是面试官最爱追问的细节。1. 项目整体设计与核心模块拆解1.1 为什么是 Spring Boot 而不是 SSH、SSM 老古董2025年了还在用SSHStruts Spring Hibernate写新项目答辩老师大概率会问一句“为什么不换主流框架”。Spring Boot 能在物业系统这类业务里成为事实标准核心就三点自动配置解决了一半的配置文件问题。传统SSM项目要手写web.xml、spring-mvc.xml、mybatis-config.xml光是各种bean配置就占了一大半工作量。Spring Boot把常用的配置做了封装一个application.yml搞定数据源、MyBatis、Redis、日志、线程池开箱即用开发效率直接翻倍。内置Tomcat容器让部署变得极其简单。传统项目要装独立Tomcat、手动发布war包Spring Boot一个mvn package打出来的可执行jar直接java -jar就能跑这对测试环境、演示环境特别友好。更关键的是Spring Boot的生态整合能力太强了后面要说的MyBatis-Plus、Redis、JWT等工具全部有对应的starter引入依赖加配几行配置就能生效。对课程设计、毕业设计这类场景Spring Boot加Spring MVC的分层结构也足够清晰。Controller写接口、Service写业务、Mapper写SQL三层结构一眼就能看明白答辩时也容易顺着思路讲。1.2 核心业务模块怎么划分小区物业系统的用户角色一般分成三类业主、物业管理员、系统管理员。我的建议是再拆一层“业主端和物业端”的视图划分对应的菜单、页面、接口都分开这样前端不用做复杂的权限判断后端也容易控制。功能列表拆解一下业主端在线报修填写房屋信息、上传图片、选择故障类型、报修进度查询、停车位预约/取消、我的车位、物业费缴费记录、投诉建议、个人信息管理。物业端报修工单审核与派单、维修进度回填、车位发布/下架、预约订单管理、业主信息管理、缴费账单生成。系统管理端用户管理、角色权限分配、楼栋房屋数据字典、操作日志。关键点在于“报修工单”和“车位预约”这两条业务线要有完整的状态流转不能只做增删改查。状态字段要贯穿整个流程这既是业务亮点也是答辩时的加分点。1.3 数据库设计思路数据库设计我按“围绕核心实体展开”的思路来做。核心实体包括用户表user、房屋表house、报修表repair_record、车位表parking_space、预约表parking_reservation、缴费单表payment_bill。repair_record表的结构大致是这样设计的时候注意几点status字段专门记录工单流转状态0待受理、1处理中、2待验收、3已完成、4已取消。在审计里加create_time、update_time、create_by这些字段方便后来排查问题。image_url可以存多个图片的JSON数组比如业主上传三张现场照片用一个字段存下省得再建一张子表。车位表parking_space要加status字段0空闲、1已预约、2已占用和version字段乐观锁用。预约表parking_reservation要加reservation_time和expire_time防止业主预约后长时间不进场占着车位不挪。2. 核心技术选型与实现细节2.1 技术栈清单与取舍逻辑这是我给这套系统列的技术栈组合每一层都选的是比较主流、生态比较完善的东西每一层都有替代方案但是选型背后各有逻辑。后端除Spring Boot外持久层选了MyBatis-Plus而不是Hibernate/JPA因为MP的BaseMapper直接内置了selectById、updateById等常用方法不像JPA那样需要写很多接口派生查询对业务比较直白的物业系统来说MPS可以让你用最少代码完成单表CRUD复杂SQL又可以用Select注解或者XML手写兼顾效率和灵活性。权限校验这里我推荐JWT而不推荐传统的Session Shiro。因为业主端往往用H5或小程序访问前后端分离已经是常态JWT无状态校验天然适合这种场景。只要在拦截器里解析Token把UserId放进ThreadLocalService层就能直接拿到当前操作人非常方便。2.2 分层架构与包结构包结构建议按这种方式组织重点是common放通用返回体和异常处理config放配置类security放JWT拦截器和注解模块三层分清楚com.community.property ├── controller // 接收请求参数校验 ├── service // 业务逻辑事务管理 ├── mapper // MyBatis-Plus 数据访问 ├── entity // 数据库实体 ├── dto // 前端交互对象 ├── vo // 视图返回对象 ├── common // 全局返回结果异常处理 ├── config // 配置类WebMvcConfigRedisConfig ├── security // JWT 拦截器、管理员注解 └── utils // 日期处理、文件上传等工具类实体和VO分离这事要拉出来单独强调一下。实体类尽量别直接返回给前端比如user表里存了密码的hash值如果你直接把实体类序列化返回密码就泄露了。标准做法是建UserVO只返回id、nickname、avatar、phone这些安全字段用BeanUtils.copyProperties做对象拷贝。2.3 全局异常处理处理前后端交互时最大的坑是“后端报错了一堆堆栈前端拿到的只是500看不出到底哪里错”。所以我在common包下面写了一个GlobalExceptionHandler用RestControllerAdvice统一拦截异常。业务层的类先自定义一个BusinessException包含错误码和错误消息。然后全局处理器把这些异常统一包装成Result.fail(code, msg)格式保持JSON一致。这样后端Controller就不用在每个方法里去写try-catch而是让异常规则集中处理。实际用起来前端稳定的表现就是无论成功还是失败都能收到{code:200,msg:success,data:...}这样统一的数据结构。3. 关键业务模块实操实现3.1 报修工单状态机从提交到归档报修模块的核心不光是一个INSERT语句而是一个状态机流转。这套系统的状态定义如下流转规则业主提交报修后status0等待物业受理物业接单后status1维修工处理中维修工回填处理结果后status2等待业主验收业主确认完成status3工单归档物业驳回或业主取消status4工单关闭。对应的Service方法我是这样设计的Service public class RepairService { Autowired private RepairRecordMapper repairRecordMapper; Transactional(rollbackFor Exception.class) public void acceptOrder(Long repairId, Long operatorId) { RepairRecord record repairRecordMapper.selectById(repairId); if (record null || !record.getStatus().equals(0)) { throw new BusinessException(400, 工单不存在或状态已变更); } RepairRecord update new RepairRecord(); update.setId(repairId); update.setStatus(1); update.setOperatorId(operatorId); update.setAcceptTime(LocalDateTime.now()); repairRecordMapper.updateById(update); } }加Transactional保证了select update的原子性。每步流转前都检查当前状态这是状态机落地的核心防止业主重复提交、物业跳过流程直接完成。定时超时提醒也很有用。我用Spring的Scheduled定时任务每分钟扫描一次Component public class RepairTimeoutTask { Scheduled(fixedRate 60000) public void checkTimeout() { // 查询 status0 且 create_time 超过24小时的工单 // 发送短信或站内信提醒物业管理员 } }还有一个小技巧上传现场照片用的本地存储路径我建议按日期分目录存储upload/2025/03/12/uuid.jpg。这样一年的图片不会堆在同一文件下也方便倒查。如果条件允许把文件存到OSS或MinIO上答辩时能顺便说一句“我考虑了生产环境的存储方案”。3.2 停车位预约并发防超卖车位预约是这套系统里最有技术含量也最容易被面试官追问的一个模块。场景很简单某小区有一个车位早上9点开放预约9:00:00那一刻有5个人同时点击预约系统只允许一个人成功其他4个人要么排队要么提示已被预约。这背后就是一个典型的并发防超卖问题。先看初版写法// 错误示范先查再insert并发下会造成超卖 ParkingSpace space parkingSpaceMapper.selectById(spaceId); if (space.getStatus() ! 0) throw new BusinessException(400, 车位已被预约); ParkingReservation reservation buildReservation(userId, spaceId); reservationMapper.insert(reservation); ParkingSpace update new ParkingSpace(); update.setId(spaceId); update.setStatus(1); parkingSpaceMapper.updateById(update);这种“先查询再判断再更新”的方式在并发场景下会有竞态条件。两个请求同时读到status0同时往下执行INSERT最终的结果是两个业主都预约成功车位却只有一个。解决办法是把“判断 更新”做成原子操作。方案一是用数据库悲观锁// 强制锁行防止并发同时读到 ParkingSpace space parkingSpaceMapper.selectByIdForUpdate(spaceId); if (space.getStatus() ! 0) throw new BusinessException(400, 车位已被预约);这里的核心是selectByIdForUpdate对应的Mapper方法写的是SELECT * FROM parking_space WHERE id #{id} FOR UPDATE。数据库的行锁会保证同一时刻只有一个事务能读到这条记录其他事务阻塞等待。事务提交后锁自动释放。代价是并发性能略受影响但对停车位预约这类低频场景来说完全足够而且逻辑最简单读代码的人一看就懂。方案二是用Redis分布式锁Autowired private StringRedisTemplate redisTemplate; public boolean tryLock(String key, String requestId, long expireTime) { return redisTemplate.opsForValue() .setIfAbsent(key, requestId, Duration.ofSeconds(expireTime)); }预约时先抢锁String lockKey parking:lock: spaceId; String requestId userId.toString(); boolean locked tryLock(lockKey, requestId, 30); if (!locked) { throw new BusinessException(400, 当前车位预约人数较多请重试); }用Redis做分布式锁的好处是性能高、支持多实例部署。但要注意锁的过期时间跟业务执行时间的关系业务没执行完锁就过期了会造成锁失效所以要给锁设置合理过期时间比如30秒并且执行完业务后要释放锁。整体来说单机部署场景用悲观锁就够了答辩时如果主动把“为什么不用乐观锁”讲出来反而更显思考深度。我给一个乐观锁的示例作为对比// 乐观锁CAS version ParkingSpace space parkingSpaceMapper.selectById(spaceId); ParkingSpace update new ParkingSpace(); update.setId(spaceId); update.setStatus(1); update.setVersion(space.getVersion() 1); int rows parkingSpaceMapper.updateByVersion(spaceId, space.getVersion(), update); if (rows 0) { throw new BusinessException(400, 预约冲突请刷新重试); }乐观锁是“失败重试”的思路适合读多写少、冲突低的情况。对于车位预约这种刚开始放号就10个人抢同一车位的场景冲突高用乐观锁会导致大量请求失败重试反而不如悲观锁或分布式锁直接排队等待。3.3 前端联调与页面集成前端我建议采用两种方案的结合业主端用H5页面简单方便可以直接嵌入微信物业端用后台管理页面用模板引擎或者Vue都行。这套系统的标题里提到了Vue所以很有可能是“Spring Boot Vue”的组合这也是现在最主流的前后端分离方案。前端联调时跨域是绕不开的问题。在config包下加一个WebMvcConfigConfiguration public class WebMvcConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }注意allowedOriginPatterns(*)配合allowCredentials(true)使用时不能直接用allowedOrigins(*)原因在于带Cookie跨域时浏览器要求明确指定源不支持通配符。如果前后端不在同域这类配置不对会带来大量联调问题。Token校验这块我写了一个拦截器Component public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token null || !token.startsWith(Bearer )) { throw new BusinessException(401, 未登录或登录已过期); } // 解析JWT校验签名把userId放入ThreadLocal Long userId JwtUtil.parseToken(token.substring(7)); UserContext.set(userId); return true; } }对于只有管理员能操作的接口再加一个RequireAdmin注解在拦截器里判断当前用户的角色。还要注意放行登录、注册等公开接口比如/api/user/login不能拦截。我用的是白名单模式可维护程度更高。4. 部署上线与项目讲解技巧4.1 从IDEA到服务器打包与部署本地跑起来很简单三件事做好就行第一数据库初始化。提前创建好数据库然后导入sql目录下的init.sql把所有的表结构和测试数据一次性灌进去。城市级的演示数据至少要包含几套房、几个车位和几条报修记录不然前端页面光秃秃的看着没有说服力。第二改配置文件。application.yml里的数据源配置改成你本地的MySQL地址、账号密码。Redis配置如果没有特殊需求就保持默认。文件上传目录建议单独配置一个绝对路径不要放在项目内部否则Jar包重启时文件会被清掉或者不好查。第三mvn package打包。在项目根目录执行mvn clean package -DskipTests打包完成后target目录下会生成一个community-property-0.0.1-SNAPSHOT.jar。直接运行java -jar target/community-property-0.0.1-SNAPSHOT.jar看到Started Application in xx seconds就说明启动成功了。如果部署在云服务器建议写一个start.sh启动脚本内容如下#!/bin/bash nohup java -jar /opt/property/community-property.jar \ --server.port8080 \ --spring.profiles.activeprod \ --logging.file/opt/property/logs/app.log \ /dev/null 21 做这套系统的目的是为了演示建议本地部署时直接用IDEA的Run启动调试更高效。演示视频录制的时候要把“业主提交报修 → 物业处理 → 业主验收”这条链路走完这是全流程最直观的演示路径。4.2 答辩和面试怎么讲这个项目这部分的价值容易被低估。同一个项目有些人能讲出花来有些人被老师追问两句就卡壳。差别在于有没有准备“为什么”的答案。我建议按下面这套逻辑准备自我介绍稿先说背景给小区物业开发一套在线管理系统解决业主报修靠打电话、车位靠物业手工登记信息不透明、效率低的痛点。这句话交代了项目的背景和意义。再说架构基于Spring Boot MyBatis-Plus Vue MySQL前后端分离采用三层架构和RESTful API设计。这句话交代了技术栈和组织方式。然后抛亮点第一报修工单实现了全状态机流转每一步操作都有状态校验并支持定时任务做超时提醒第二停车位预约模块用数据库悲观锁/Redis分布式锁解决并发防超卖问题支持同一时刻多人抢车位第三JWT无状态认证适配前后端分离场景管理员接口有独立权限校验。这三点是面试官最关心的技术含量所在。最后说优化后续可以引入RabbitMQ做消息推送在微信端集成模板消息把小区公告、报修进度推给业主引入ECharts做数据分析看板。这句话展示你对项目有扩展思考。答辩时大概率会被问到“为什么用悲观锁不用乐观锁”“MyBatis-Plus和MyBatis有什么区别”“JWT和Session怎么选”上面的技术选型讲解就是现成的答案。自己先写一遍再用自己的话讲出来比临时背稿顺很多。5. 常见问题排查与避坑实录光看代码别人都会写但真实跑起来新手最容易在这些地方翻车。我整理了实操中高频率出现的六个问题。5.1 MySQL 8.0 驱动和时区问题报错信息往往是Access denied for user rootlocalhost或者The server time zone value Öйú±ê׼ʱ¼ä is unrecognized。处理方法是在JDBC连接串里强制指定时间区域spring: datasource: url: jdbc:mysql://localhost:3306/community?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai如果是Access denied先确认密码是否正确再排查MySQL 8.0的默认认证插件是否为caching_sha2_passwordSpring Boot连接时建议改成mysql_native_password或者换用8.0的驱动版本并保持兼容。5.2 端口占用和跨域异常Spring Boot默认端口8080经常被其他项目占用报错是Port 8080 was already in use。快速解决办法要么netstat -ano | findstr 8080查进程杀掉要么改server.portserver: port: 8088跨域异常一般是浏览器控制台报Access-Control-Allow-Origin之类的错误。排查思路先看后端addCorsMappings有没有配置好再看请求路径是否真的打到了后端很多人用前端代理时忘了配代理最后检查是不是因为带了Authorization头而触发了预检请求。5.3 登录后接口仍然401或403这个问题十有八九是拦截器放行路径没配好或者Token传的位置不对。后端验证Token时会去请求头拿Authorization: Bearer token前端如果只传了token、没加Bearer前缀后端解析会失败。还有一种情况是前端每次请求都用一个新Token刷新后旧的直接失效但前端没有处理好刷新逻辑也会看到401。排查建议用Postman先测接口手动把Token加对一次性通过后再去前端查代码。这样能把前端问题跟后端问题隔离开少走很多弯路。5.4 MyBatis-Plus 自动填充时间不生效我在实体类里有create_time和update_time字段如果只在数据库表里设置了默认值代码层不处理插入数据时Java对象里这两个字段为null就不能回显到前端。MyBatis-Plus标准做法是TableField(fill FieldFill.INSERT) private LocalDateTime createTime; TableField(fill FieldFill.INSERT_UPDATE) private LocalDateTime updateTime;配置类里定义MetaObjectHandlerComponent public class MyMetaObjectHandler implements MetaObjectHandler { Override public void insertFill(MetaObject metaObject) { this.strictInsertFill(metaObject, createTime, LocalDateTime.class, LocalDateTime.now()); this.strictInsertFill(metaObject, updateTime, LocalDateTime.class, LocalDateTime.now()); } Override public void updateFill(MetaObject metaObject) { this.strictUpdateFill(metaObject, updateTime, LocalDateTime.class, LocalDateTime.now()); } }5.5 定时任务在集群环境下重复执行如果项目只部署单机Scheduled完全够用。但如果部署了两台服务器做负载均衡定时任务会在两台机器上同时跑导致重复发短信、重复检测。凌晨跑一下扫描工单的定时任务两台机器同时扫到超时工单各发一条短信业主会收到两条一模一样的提醒。解决这个问题的思路有几种一是加一个Redis分布式锁抢到锁的实例才允许执行二是改用ShedLock开源库专门处理定时任务互斥三是把定时任务独立成一个Job服务只部署一份。对于学生项目我建议在任务方法里加一个Redis锁简单可控讲起来也不复杂。5.6 打包后前端页面无法访问如果采用前后端分离前端是独立的Vue项目打包后是dist目录需要放在Nginx或部署到服务器上不能直接扔进Spring Boot的jar包里。如果为了方便演示想搞成一个包可以把前端dist目录放到Spring Boot的src/main/resources/static下再配合WebMvc的视图跳转。但这么做会导致前端要跟后端一起打包、一起发版开发和部署会麻烦一些不是特别推荐。这里提供一个参照单机演示用“前端打包到静态资源目录 后端打包成jar”的方式最省事真正的生产环境用“前端Nginx静态托管 后端接口服务”的方式各跑各的资源互相不干扰。最后分享几个实际操作的小技巧这系统我在帮人调试的过程中前后跑了不下十遍踩了不少坑最后留几个通用的小心得。启动脚本里最好加上log文件输出不要只用nohup把日志丢在黑洞里。线上跑的时候/logs/app.log里的信息就是排查问题的第一现场有时候数据库连不上、端口冲突这类问题看日志一眼就能定位。没有日志问题定位全靠猜。录制运行视频时准备一份足够饱满的演示数据效果差异非常明显。比如停车位预约先预置一个空闲车位预约时故意不输入车牌号让校验器报错一次然后再输入正确的车牌号预约成功这就把“参数校验”和“业务流程”两个点都展示了视频比单纯演示主流程要丰富得多。项目文档里强烈建议画一张MySQL的ER图把表关系标清楚用户和房屋是一对一房屋和报修是一对多车位和预约是一对多。答辩现场老师最喜欢对着ER图问表结构设计有了这张图不仅能避免现场空讲还显得思路完整。如果做分布式锁演示记得先本地把Redis装好再录视频。Spring Boot连不上Redis会直接启动报错这个坑在演示前最容易翻车。本地没有Redis的优先用数据库悲观锁方案至少不会因为环境问题丢分。 
长河君 · 2026/10/10 7:01:26 · 阅读 1.2k Spring Boot小区物业管理系统：报修与车位并发实战
上一个接单季帮人跑过几个类似的物业管理系统说实话这类项目的核心不在功能多全而在“报修闭环”和“车位预约并发”这两块能不能讲清楚。今天拿这套“Spring Boot Java 小区物业管理系统”做个完整复盘从模块设计、技术选型到部署答辩一条线捋下来。你要是准备毕设答辩、或者打算把这类项目写进简历这篇能帮你省不少时间。先说给谁看用这套题目做毕业设计的学生、正在整理Java项目经验的初级开发还有想在培训作业里拿个高分的同学。系统本身不复杂就是业主端报修、物业端派单、停车位在线预约这三条主线加一个后台管理壳子。但它覆盖了Java后端开发最常见的几个考核点CRUD、状态机流转、权限控制、并发防超卖这些恰好是面试官最爱追问的细节。1. 项目整体设计与核心模块拆解1.1 为什么是 Spring Boot 而不是 SSH、SSM 老古董2025年了还在用SSHStruts Spring Hibernate写新项目答辩老师大概率会问一句“为什么不换主流框架”。Spring Boot 能在物业系统这类业务里成为事实标准核心就三点自动配置解决了一半的配置文件问题。传统SSM项目要手写web.xml、spring-mvc.xml、mybatis-config.xml光是各种bean配置就占了一大半工作量。Spring Boot把常用的配置做了封装一个application.yml搞定数据源、MyBatis、Redis、日志、线程池开箱即用开发效率直接翻倍。内置Tomcat容器让部署变得极其简单。传统项目要装独立Tomcat、手动发布war包Spring Boot一个mvn package打出来的可执行jar直接java -jar就能跑这对测试环境、演示环境特别友好。更关键的是Spring Boot的生态整合能力太强了后面要说的MyBatis-Plus、Redis、JWT等工具全部有对应的starter引入依赖加配几行配置就能生效。对课程设计、毕业设计这类场景Spring Boot加Spring MVC的分层结构也足够清晰。Controller写接口、Service写业务、Mapper写SQL三层结构一眼就能看明白答辩时也容易顺着思路讲。1.2 核心业务模块怎么划分小区物业系统的用户角色一般分成三类业主、物业管理员、系统管理员。我的建议是再拆一层“业主端和物业端”的视图划分对应的菜单、页面、接口都分开这样前端不用做复杂的权限判断后端也容易控制。功能列表拆解一下业主端在线报修填写房屋信息、上传图片、选择故障类型、报修进度查询、停车位预约/取消、我的车位、物业费缴费记录、投诉建议、个人信息管理。物业端报修工单审核与派单、维修进度回填、车位发布/下架、预约订单管理、业主信息管理、缴费账单生成。系统管理端用户管理、角色权限分配、楼栋房屋数据字典、操作日志。关键点在于“报修工单”和“车位预约”这两条业务线要有完整的状态流转不能只做增删改查。状态字段要贯穿整个流程这既是业务亮点也是答辩时的加分点。1.3 数据库设计思路数据库设计我按“围绕核心实体展开”的思路来做。核心实体包括用户表user、房屋表house、报修表repair_record、车位表parking_space、预约表parking_reservation、缴费单表payment_bill。repair_record表的结构大致是这样设计的时候注意几点status字段专门记录工单流转状态0待受理、1处理中、2待验收、3已完成、4已取消。在审计里加create_time、update_time、create_by这些字段方便后来排查问题。image_url可以存多个图片的JSON数组比如业主上传三张现场照片用一个字段存下省得再建一张子表。车位表parking_space要加status字段0空闲、1已预约、2已占用和version字段乐观锁用。预约表parking_reservation要加reservation_time和expire_time防止业主预约后长时间不进场占着车位不挪。2. 核心技术选型与实现细节2.1 技术栈清单与取舍逻辑这是我给这套系统列的技术栈组合每一层都选的是比较主流、生态比较完善的东西每一层都有替代方案但是选型背后各有逻辑。后端除Spring Boot外持久层选了MyBatis-Plus而不是Hibernate/JPA因为MP的BaseMapper直接内置了selectById、updateById等常用方法不像JPA那样需要写很多接口派生查询对业务比较直白的物业系统来说MPS可以让你用最少代码完成单表CRUD复杂SQL又可以用Select注解或者XML手写兼顾效率和灵活性。权限校验这里我推荐JWT而不推荐传统的Session Shiro。因为业主端往往用H5或小程序访问前后端分离已经是常态JWT无状态校验天然适合这种场景。只要在拦截器里解析Token把UserId放进ThreadLocalService层就能直接拿到当前操作人非常方便。2.2 分层架构与包结构包结构建议按这种方式组织重点是common放通用返回体和异常处理config放配置类security放JWT拦截器和注解模块三层分清楚com.community.property ├── controller // 接收请求参数校验 ├── service // 业务逻辑事务管理 ├── mapper // MyBatis-Plus 数据访问 ├── entity // 数据库实体 ├── dto // 前端交互对象 ├── vo // 视图返回对象 ├── common // 全局返回结果异常处理 ├── config // 配置类WebMvcConfigRedisConfig ├── security // JWT 拦截器、管理员注解 └── utils // 日期处理、文件上传等工具类实体和VO分离这事要拉出来单独强调一下。实体类尽量别直接返回给前端比如user表里存了密码的hash值如果你直接把实体类序列化返回密码就泄露了。标准做法是建UserVO只返回id、nickname、avatar、phone这些安全字段用BeanUtils.copyProperties做对象拷贝。2.3 全局异常处理处理前后端交互时最大的坑是“后端报错了一堆堆栈前端拿到的只是500看不出到底哪里错”。所以我在common包下面写了一个GlobalExceptionHandler用RestControllerAdvice统一拦截异常。业务层的类先自定义一个BusinessException包含错误码和错误消息。然后全局处理器把这些异常统一包装成Result.fail(code, msg)格式保持JSON一致。这样后端Controller就不用在每个方法里去写try-catch而是让异常规则集中处理。实际用起来前端稳定的表现就是无论成功还是失败都能收到{code:200,msg:success,data:...}这样统一的数据结构。3. 关键业务模块实操实现3.1 报修工单状态机从提交到归档报修模块的核心不光是一个INSERT语句而是一个状态机流转。这套系统的状态定义如下流转规则业主提交报修后status0等待物业受理物业接单后status1维修工处理中维修工回填处理结果后status2等待业主验收业主确认完成status3工单归档物业驳回或业主取消status4工单关闭。对应的Service方法我是这样设计的Service public class RepairService { Autowired private RepairRecordMapper repairRecordMapper; Transactional(rollbackFor Exception.class) public void acceptOrder(Long repairId, Long operatorId) { RepairRecord record repairRecordMapper.selectById(repairId); if (record null || !record.getStatus().equals(0)) { throw new BusinessException(400, 工单不存在或状态已变更); } RepairRecord update new RepairRecord(); update.setId(repairId); update.setStatus(1); update.setOperatorId(operatorId); update.setAcceptTime(LocalDateTime.now()); repairRecordMapper.updateById(update); } }加Transactional保证了select update的原子性。每步流转前都检查当前状态这是状态机落地的核心防止业主重复提交、物业跳过流程直接完成。定时超时提醒也很有用。我用Spring的Scheduled定时任务每分钟扫描一次Component public class RepairTimeoutTask { Scheduled(fixedRate 60000) public void checkTimeout() { // 查询 status0 且 create_time 超过24小时的工单 // 发送短信或站内信提醒物业管理员 } }还有一个小技巧上传现场照片用的本地存储路径我建议按日期分目录存储upload/2025/03/12/uuid.jpg。这样一年的图片不会堆在同一文件下也方便倒查。如果条件允许把文件存到OSS或MinIO上答辩时能顺便说一句“我考虑了生产环境的存储方案”。3.2 停车位预约并发防超卖车位预约是这套系统里最有技术含量也最容易被面试官追问的一个模块。场景很简单某小区有一个车位早上9点开放预约9:00:00那一刻有5个人同时点击预约系统只允许一个人成功其他4个人要么排队要么提示已被预约。这背后就是一个典型的并发防超卖问题。先看初版写法// 错误示范先查再insert并发下会造成超卖 ParkingSpace space parkingSpaceMapper.selectById(spaceId); if (space.getStatus() ! 0) throw new BusinessException(400, 车位已被预约); ParkingReservation reservation buildReservation(userId, spaceId); reservationMapper.insert(reservation); ParkingSpace update new ParkingSpace(); update.setId(spaceId); update.setStatus(1); parkingSpaceMapper.updateById(update);这种“先查询再判断再更新”的方式在并发场景下会有竞态条件。两个请求同时读到status0同时往下执行INSERT最终的结果是两个业主都预约成功车位却只有一个。解决办法是把“判断 更新”做成原子操作。方案一是用数据库悲观锁// 强制锁行防止并发同时读到 ParkingSpace space parkingSpaceMapper.selectByIdForUpdate(spaceId); if (space.getStatus() ! 0) throw new BusinessException(400, 车位已被预约);这里的核心是selectByIdForUpdate对应的Mapper方法写的是SELECT * FROM parking_space WHERE id #{id} FOR UPDATE。数据库的行锁会保证同一时刻只有一个事务能读到这条记录其他事务阻塞等待。事务提交后锁自动释放。代价是并发性能略受影响但对停车位预约这类低频场景来说完全足够而且逻辑最简单读代码的人一看就懂。方案二是用Redis分布式锁Autowired private StringRedisTemplate redisTemplate; public boolean tryLock(String key, String requestId, long expireTime) { return redisTemplate.opsForValue() .setIfAbsent(key, requestId, Duration.ofSeconds(expireTime)); }预约时先抢锁String lockKey parking:lock: spaceId; String requestId userId.toString(); boolean locked tryLock(lockKey, requestId, 30); if (!locked) { throw new BusinessException(400, 当前车位预约人数较多请重试); }用Redis做分布式锁的好处是性能高、支持多实例部署。但要注意锁的过期时间跟业务执行时间的关系业务没执行完锁就过期了会造成锁失效所以要给锁设置合理过期时间比如30秒并且执行完业务后要释放锁。整体来说单机部署场景用悲观锁就够了答辩时如果主动把“为什么不用乐观锁”讲出来反而更显思考深度。我给一个乐观锁的示例作为对比// 乐观锁CAS version ParkingSpace space parkingSpaceMapper.selectById(spaceId); ParkingSpace update new ParkingSpace(); update.setId(spaceId); update.setStatus(1); update.setVersion(space.getVersion() 1); int rows parkingSpaceMapper.updateByVersion(spaceId, space.getVersion(), update); if (rows 0) { throw new BusinessException(400, 预约冲突请刷新重试); }乐观锁是“失败重试”的思路适合读多写少、冲突低的情况。对于车位预约这种刚开始放号就10个人抢同一车位的场景冲突高用乐观锁会导致大量请求失败重试反而不如悲观锁或分布式锁直接排队等待。3.3 前端联调与页面集成前端我建议采用两种方案的结合业主端用H5页面简单方便可以直接嵌入微信物业端用后台管理页面用模板引擎或者Vue都行。这套系统的标题里提到了Vue所以很有可能是“Spring Boot Vue”的组合这也是现在最主流的前后端分离方案。前端联调时跨域是绕不开的问题。在config包下加一个WebMvcConfigConfiguration public class WebMvcConfig implements WebMvcConfigurer { Override public void addCorsMappings(CorsRegistry registry) { registry.addMapping(/**) .allowedOriginPatterns(*) .allowedMethods(GET, POST, PUT, DELETE) .allowedHeaders(*) .allowCredentials(true) .maxAge(3600); } }注意allowedOriginPatterns(*)配合allowCredentials(true)使用时不能直接用allowedOrigins(*)原因在于带Cookie跨域时浏览器要求明确指定源不支持通配符。如果前后端不在同域这类配置不对会带来大量联调问题。Token校验这块我写了一个拦截器Component public class JwtInterceptor implements HandlerInterceptor { Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { String token request.getHeader(Authorization); if (token null || !token.startsWith(Bearer )) { throw new BusinessException(401, 未登录或登录已过期); } // 解析JWT校验签名把userId放入ThreadLocal Long userId JwtUtil.parseToken(token.substring(7)); UserContext.set(userId); return true; } }对于只有管理员能操作的接口再加一个RequireAdmin注解在拦截器里判断当前用户的角色。还要注意放行登录、注册等公开接口比如/api/user/login不能拦截。我用的是白名单模式可维护程度更高。4. 部署上线与项目讲解技巧4.1 从IDEA到服务器打包与部署本地跑起来很简单三件事做好就行第一数据库初始化。提前创建好数据库然后导入sql目录下的init.sql把所有的表结构和测试数据一次性灌进去。城市级的演示数据至少要包含几套房、几个车位和几条报修记录不然前端页面光秃秃的看着没有说服力。第二改配置文件。application.yml里的数据源配置改成你本地的MySQL地址、账号密码。Redis配置如果没有特殊需求就保持默认。文件上传目录建议单独配置一个绝对路径不要放在项目内部否则Jar包重启时文件会被清掉或者不好查。第三mvn package打包。在项目根目录执行mvn clean package -DskipTests打包完成后target目录下会生成一个community-property-0.0.1-SNAPSHOT.jar。直接运行java -jar target/community-property-0.0.1-SNAPSHOT.jar看到Started Application in xx seconds就说明启动成功了。如果部署在云服务器建议写一个start.sh启动脚本内容如下#!/bin/bash nohup java -jar /opt/property/community-property.jar \ --server.port8080 \ --spring.profiles.activeprod \ --logging.file/opt/property/logs/app.log \ /dev/null 21 做这套系统的目的是为了演示建议本地部署时直接用IDEA的Run启动调试更高效。演示视频录制的时候要把“业主提交报修 → 物业处理 → 业主验收”这条链路走完这是全流程最直观的演示路径。4.2 答辩和面试怎么讲这个项目这部分的价值容易被低估。同一个项目有些人能讲出花来有些人被老师追问两句就卡壳。差别在于有没有准备“为什么”的答案。我建议按下面这套逻辑准备自我介绍稿先说背景给小区物业开发一套在线管理系统解决业主报修靠打电话、车位靠物业手工登记信息不透明、效率低的痛点。这句话交代了项目的背景和意义。再说架构基于Spring Boot MyBatis-Plus Vue MySQL前后端分离采用三层架构和RESTful API设计。这句话交代了技术栈和组织方式。然后抛亮点第一报修工单实现了全状态机流转每一步操作都有状态校验并支持定时任务做超时提醒第二停车位预约模块用数据库悲观锁/Redis分布式锁解决并发防超卖问题支持同一时刻多人抢车位第三JWT无状态认证适配前后端分离场景管理员接口有独立权限校验。这三点是面试官最关心的技术含量所在。最后说优化后续可以引入RabbitMQ做消息推送在微信端集成模板消息把小区公告、报修进度推给业主引入ECharts做数据分析看板。这句话展示你对项目有扩展思考。答辩时大概率会被问到“为什么用悲观锁不用乐观锁”“MyBatis-Plus和MyBatis有什么区别”“JWT和Session怎么选”上面的技术选型讲解就是现成的答案。自己先写一遍再用自己的话讲出来比临时背稿顺很多。5. 常见问题排查与避坑实录光看代码别人都会写但真实跑起来新手最容易在这些地方翻车。我整理了实操中高频率出现的六个问题。5.1 MySQL 8.0 驱动和时区问题报错信息往往是Access denied for user rootlocalhost或者The server time zone value Öйú±ê׼ʱ¼ä is unrecognized。处理方法是在JDBC连接串里强制指定时间区域spring: datasource: url: jdbc:mysql://localhost:3306/community?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/Shanghai如果是Access denied先确认密码是否正确再排查MySQL 8.0的默认认证插件是否为caching_sha2_passwordSpring Boot连接时建议改成mysql_native_password或者换用8.0的驱动版本并保持兼容。5.2 端口占用和跨域异常Spring Boot默认端口8080经常被其他项目占用报错是Port 8080 was already in use。快速解决办法要么netstat -ano | findstr 8080查进程杀掉要么改server.portserver: port: 8088跨域异常一般是浏览器控制台报Access-Control-Allow-Origin之类的错误。排查思路先看后端addCorsMappings有没有配置好再看请求路径是否真的打到了后端很多人用前端代理时忘了配代理最后检查是不是因为带了Authorization头而触发了预检请求。5.3 登录后接口仍然401或403这个问题十有八九是拦截器放行路径没配好或者Token传的位置不对。后端验证Token时会去请求头拿Authorization: Bearer token前端如果只传了token、没加Bearer前缀后端解析会失败。还有一种情况是前端每次请求都用一个新Token刷新后旧的直接失效但前端没有处理好刷新逻辑也会看到401。排查建议用Postman先测接口手动把Token加对一次性通过后再去前端查代码。这样能把前端问题跟后端问题隔离开少走很多弯路。5.4 MyBatis-Plus 自动填充时间不生效我在实体类里有create_time和update_time字段如果只在数据库表里设置了默认值代码层不处理插入数据时Java对象里这两个字段为null就不能回显到前端。MyBatis-Plus标准做法是TableField(fill FieldFill.INSERT) private LocalDateTime createTime; TableField(fill FieldFill.INSERT_UPDATE) private LocalDateTime updateTime;配置类里定义MetaObjectHandlerComponent public class MyMetaObjectHandler implements MetaObjectHandler { Override public void insertFill(MetaObject metaObject) { this.strictInsertFill(metaObject, createTime, LocalDateTime.class, LocalDateTime.now()); this.strictInsertFill(metaObject, updateTime, LocalDateTime.class, LocalDateTime.now()); } Override public void updateFill(MetaObject metaObject) { this.strictUpdateFill(metaObject, updateTime, LocalDateTime.class, LocalDateTime.now()); } }5.5 定时任务在集群环境下重复执行如果项目只部署单机Scheduled完全够用。但如果部署了两台服务器做负载均衡定时任务会在两台机器上同时跑导致重复发短信、重复检测。凌晨跑一下扫描工单的定时任务两台机器同时扫到超时工单各发一条短信业主会收到两条一模一样的提醒。解决这个问题的思路有几种一是加一个Redis分布式锁抢到锁的实例才允许执行二是改用ShedLock开源库专门处理定时任务互斥三是把定时任务独立成一个Job服务只部署一份。对于学生项目我建议在任务方法里加一个Redis锁简单可控讲起来也不复杂。5.6 打包后前端页面无法访问如果采用前后端分离前端是独立的Vue项目打包后是dist目录需要放在Nginx或部署到服务器上不能直接扔进Spring Boot的jar包里。如果为了方便演示想搞成一个包可以把前端dist目录放到Spring Boot的src/main/resources/static下再配合WebMvc的视图跳转。但这么做会导致前端要跟后端一起打包、一起发版开发和部署会麻烦一些不是特别推荐。这里提供一个参照单机演示用“前端打包到静态资源目录 后端打包成jar”的方式最省事真正的生产环境用“前端Nginx静态托管 后端接口服务”的方式各跑各的资源互相不干扰。最后分享几个实际操作的小技巧这系统我在帮人调试的过程中前后跑了不下十遍踩了不少坑最后留几个通用的小心得。启动脚本里最好加上log文件输出不要只用nohup把日志丢在黑洞里。线上跑的时候/logs/app.log里的信息就是排查问题的第一现场有时候数据库连不上、端口冲突这类问题看日志一眼就能定位。没有日志问题定位全靠猜。录制运行视频时准备一份足够饱满的演示数据效果差异非常明显。比如停车位预约先预置一个空闲车位预约时故意不输入车牌号让校验器报错一次然后再输入正确的车牌号预约成功这就把“参数校验”和“业务流程”两个点都展示了视频比单纯演示主流程要丰富得多。项目文档里强烈建议画一张MySQL的ER图把表关系标清楚用户和房屋是一对一房屋和报修是一对多车位和预约是一对多。答辩现场老师最喜欢对着ER图问表结构设计有了这张图不仅能避免现场空讲还显得思路完整。如果做分布式锁演示记得先本地把Redis装好再录视频。Spring Boot连不上Redis会直接启动报错这个坑在演示前最容易翻车。本地没有Redis的优先用数据库悲观锁方案至少不会因为环境问题丢分。