把“智汇家园管理系统”做成一个毕设课题很多人第一反应就是“这不就是一个带界面的增删改查吗”。说实话我第一次拿到这个题目时也这么想但真正动手拆解之后才发现难点根本不是某个页面怎么写而是整个课题背后那套业务关系、角色边界、前后端协作方式以及验收时怎么把“能跑”变成“能讲”。这篇文章我就以“智汇家园管理系统”为例完整梳理一条从业务建模、后端接口设计、前端工程化到本地启动联调、答辩问答的落地路径。项目使用SpringBoot做服务端、Vue做前端页面适配正在做毕设或者想快速上手全栈项目的同学也是给那些“代码能跑但讲不清楚为什么这么设计”的人补一课。1. “智汇家园”到底在管理什么先搞清楚业务模型再动手写代码很多同学拿到这个题目会先建表然后急着写接口。我建议反过来先拿一上午想明白这个系统未来的使用者是谁他们要完成什么任务系统里最高频的操作是什么。1.1 以“物”为核心的管理视角“智汇家园”这四个字听起来很宽泛但落到小区管理场景核心其实是“管物”而不是“管人”。这里的“物”指的是楼栋、房屋、车位、公共设施“人”指的是业主、住户、租客、物业人员。所有业务流转本质上都是人和物产生关联之后引发的业主缴费、住户报修、物业派单、访客登记、公告通知这些动作都可以归到某个房屋或某个设施上。所以我在设计数据库时把小区community、楼栋building、房屋house作为基础档案住户resident与房屋通过绑定关系表关联而缴费账单、报修工单、投诉建议这些业务数据全部记录所属房屋编号。这样做的好处是后续统计非常方便某个楼栋这个月的缴费率是多少某类设施报修频次高不高都能通过房屋这个核心字段快速聚合。1.2 三条核心业务流整个系统虽然表不少但逻辑上有三条主线工单流业主或住户提交报修/投诉 - 物业管理员接单 - 派发给维修人员 - 维修后回填结果 - 业主评价。这条流是系统里最复杂的一条因为涉及状态机变化。账单流物业生成水电物业账单 - 住户查看 - 缴费毕设阶段可模拟支付 - 账单状态更新 - 历史缴费统计。通知流物业发布公告 - 系统推送给绑定住户 - 住户在首页查看 - 消息已读回执。建议在开发前把这三条链路画成状态流转图每个状态对应一个后端枚举前端下拉选项和按钮显隐都依据后端返回的状态字段来控制。这样做之后前后端联调会省非常多力气至少不会出现“前端不知道这个按钮什么时候可点”的尴尬。1.3 角色权限的设计取舍家园系统天然有至少两类角色物业端和住户端。物业端里还可以细分管理员、客服、维修工但作为毕设系统我不建议一上来就把RBAC基于角色的权限控制做得特别重。一个比较务实的设计是系统内置三种固定角色即系统管理员、物业员工、业主住户权限表做成固定的关联关系而不是做成完全可配置的动态权限。我在权限上采用的是“JWT 后端拦截 前端路由守卫”三层配合。后端用一个拦截器校验JWT是否有效、是否放行前端根据登录用户的角色动态生成可访问的路由菜单。这样既体现了一定的技术工作量答辩时又能清楚讲出每一层负责什么。2. 后端设计与搭建SpringBoot项目分层、核心表与接口实现后端是整个项目的重心SpringBoot框架本身封装得很好但初学阶段很容易陷入“能跑就行、结构混乱”的状态。我建议严格按照分层的思想去建包哪怕代码量不大也要让路径结构看起来是“有设计”的。2.1 项目分层与包结构规范一个适合毕设展示的SpringBoot后端结构大致如下com.home.smart ├── controller # 接口层只做参数接收与结果返回 ├── service # 业务层处理核心逻辑 │ └── impl ├── mapper # MyBatis-Plus的Mapper接口 ├── entity # 数据库实体类 ├── dto # 前端传输对象避免直接暴露entity过多字段 ├── vo # 视图对象封装返回给前端的数据 ├── config # 配置类例如拦截器、跨域、分页插件 ├── common # 公共类统一返回体、异常处理、工具类 └── security # JWT工具、登录拦截、注解这种结构的核心思路是controller不写任何业务逻辑只负责接收请求、调用service、把结果包装成统一返回体service层处理核心规则mapper层只做数据库交互。面试官或答辩老师看到这种分层第一印象就会好很多因为这说明你不是把代码全堆在一个类里。统一返回体的设计也很关键。我封装了一个Result类包含code、message、data三个字段例如登录成功返回code200参数错误返回code400业务异常返回code500。所有接口都返回这个格式前端axios拦截器只需要判断code就能决定是正常渲染还是弹错误提示。2.2 核心表设计与接口划分下面是我最终落地的核心表清单以及每一张表的核心作用表名关键字段作用说明community小区名称、地址、物业公司顶层组织档案building楼栋编号、层数、单元数关联小区house房号、面积、户型、状态可售/已入住/空置resident姓名、手机号、身份证号、角色住户信息档案owner_house住户ID、房屋ID、关系类型住户与房屋的绑定关系bill房屋ID、费项、金额、周期、状态缴费账单repair_order房屋ID、报修内容、状态、处理时间报修工单notice标题、内容、发布人、发布时间公告通知visitor访客姓名、手机号、被访房号、时间访客登记complaint投诉内容、回复内容、状态投诉建议这些表之间的关系在答辩时大概率会被问到比如“业主和房屋是多对多还是一对多”“账单和房屋是什么关系”。实际业务中一套房子可能存在多个共同居住人所以我把住户与房屋设计成绑定关系表这样既保留了业务扩展性又不会让表结构复杂到把自己绕晕。接口设计遵循RESTful风格核心接口如下POST /api/auth/login # 登录返回JWT GET /api/community/overview # 首页统计小区楼栋数、住户数、待处理工单数 POST /api/house/page # 分页查询房屋信息 POST /api/resident/register # 业主/住户登记 GET /api/bill/list # 账单列表支持按房屋、月份筛选 POST /api/repair/create # 提交报修工单 POST /api/repair/handle # 处理工单接单、完工、回填结果 POST /api/notice/publish # 发布公告 GET /api/notice/list # 查询公告这里有个细节需要注意查询接口如果参数较复杂我推荐用POST body传参简单查询则用GET。不要所有接口都用POST答辩时容易被问“为什么不用GET”最好能说出差异。2.3 依赖选型与版本适配的实用建议依赖选型上我用了SpringBoot 2.7.18 JDK8 MyBatis-Plus 3.5.3 MySQL 8.0 JWTjjwt这套组合。为什么不追新用SpringBoot 3.x因为3.x基于JDK17并且javax.servlet迁移到了jakarta.servlet很多教材和老博客里的代码会报包不存在对于毕设交期和踩坑成本来说并不划算。如果你确实想用3.x一定要把MyBatis-Plus、PageHelper这类中间件的版本先确认好否则编译期会卡很久。MyBatis-Plus在毕设里几乎是“标配”因为它把单表CRUD省到了极致。实体类上标注TableName和TableId后继承BaseMapperT就有了一整套单表方法。分页则通过配置PaginationInnerInterceptor实现Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }使用分页时service里返回PageHouseVO即可前端传入pageNum和pageSize两个参数。MyBatis-Plus会自动拼接LIMIT语句并且total字段会同步返回前端分页组件直接使用即可。2.4 后端细节JWT登录与全局异常处理登录模块使用JWT无状态认证。用户在登录成功后后端生成一个包含用户ID和角色的token字符串返回给前端前端存在localStorage里并在每次请求的Authorization头带上。后端拦截器校验token的签名和有效期然后把解析出的用户信息放入ThreadLocal供后续业务代码使用。Python、Node里写JWT其实有各种库但Java里我推荐用jjwt 0.9.1版本使用方式比较固定String token Jwts.builder() .setSubject(String.valueOf(user.getId())) .claim(role, user.getRole()) .setExpiration(new Date(System.currentTimeMillis() 86400000)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact();解析时则通过Jwts.parser().setSigningKey(SECRET_KEY).parseClaimsJws(token).getBody()拿到Claims。全局异常处理我直接用RestControllerAdvice捕获业务异常和兜底异常统一封装成Result返回。一个常见的坑是自定义业务异常如果没有被全局捕获前端会收到默认的500错误页既无法获取message又不好定位。所以建议把BusinessException的捕获写死确保所有错误都能以前端认识的JSON形态返回。3. 前端工程搭建Vue3 Element Plus Router权限控制前端部分我采用的是Vue3 Vite Element Plus Pinia Axios的组合。相比Vue2webpack这套方案启动更快组合式API写起来也更顺手。如果学校要求必须用Vue2那语法上就要回调式的写法不过核心思路不变。3.1 前端目录结构与工程化组织Vue前端我会按下面这种方式组织目录src ├── api # 接口请求模块按业务分文件user.js, home.js, bill.js... ├── assets # 静态资源 ├── components # 公共组件 ├── router # 路由配置文件 ├── stores # Pinia状态管理 ├── views # 页面视图 └── utils # axios封装、工具函数api目录里每个文件对应一个业务模块例如bill.js里导出获取账单列表、生成账单、删除账单等方法。这样做的好处是页面里不直接写axios请求地址统一走api模块后续如果要改接口地址或加拦截逻辑只需改一处。3.2 路由与动态菜单的方案Vue Router在管理员和业主之间需要做区分。我采用的是静态路由承载登录页、404页动态路由承载业务菜单的方案。用户登录后后端返回该角色允许访问的菜单标识前端根据标识映射到对应的路由组件并动态添加到router中。路由守卫的逻辑大致是router.beforeEach(async (to, from, next) { const token localStorage.getItem(smart_token) if (!token to.path ! /login) { next(/login) } else { next() } })动态菜单生成时最省事的方式是在路由meta里声明roles字段然后通过router.addRoute按需添加。初次接触时容易遇到刷新页面后动态路由丢失的问题所以需要把菜单数据缓存到Pinia或localStorage刷新时重新拉取并addRoute。3.3 Axios请求封装与Pinia存储Axios封装是前端的一个必考知识点。我在utils/request.js里创建了一个axios实例设置baseURL为/api然后添加请求拦截器自动带token和响应拦截器统一处理code、错误提示、401跳登录。这样业务代码里不需要每次手动处理错误写起来会舒服很多。Pinia用来存储全局状态用户信息、token、菜单、已读公告。例如登录成功后把用户对象存入userStore页面显示用户名、控制按钮显隐都从这里取。相比VuexPinia的API更简洁而且天然支持组合式API的setup写法。3.4 几个页面实现的细节首页概览使用ECharts做柱状图和饼图展示各楼栋入住率、费用收缴率、维修工单状态分布。数据来源是后端聚合接口只返回统计结果图表渲染在前端做。报修工单列表状态用el-tag区分颜色待处理用danger色处理中用warning已完成用success。按钮根据状态显隐例如“派单”只在待处理状态可见。表单校验使用Element Plus的表单校验规则比如手机号、身份证号的正则校验。这里有个小坑身份证号是18位末尾可能是X正则要兼容大小写。分页组件与后端Page对象对齐监听current-change和size-change事件重新拉取数据。前端最常遇到的报错大致可以分成三类跨域报错、token过期导致的401、后端返回字段名与前端不一致。第一种通过Vite的proxy配置解决第二种在响应拦截器里统一跳转第三种则需要定期核对后端VO字段。4. 本地启动与联调从IDEA配置到dist打包并入SpringBoot很多同学卡住的往往不是写代码而是“怎么把项目跑起来”。这里我完整走一遍从IDEA配置到前后端联调、整体打包的思路。4.1 在IDEA里配置SpringBoot启动项打开IDEA后勾选Maven面板的spring-boot-maven-plugin然后找到启动类标注SpringBootApplication的类右键选择Run即可。IDEA 2026之后的版本中启动项配置入口略有变化可以在运行配置里添加Spring Boot类型的Configuration指定Main Class。端口修改有两种方式一是在application.yml中配置server.port二是在运行配置的Environment variables里设置SERVER_PORT8081。日常开发推荐用第一种清晰直观。启动遇到“Port 8080 was already in use”时改端口或者在终端用lsof -i:8080找到占用进程并结束它。很多同学在这个环节卡住觉得是代码有问题其实只是端口冲突。4.2 前端Vite代理与后端跨域前后端分离开发时前端页面地址是http://localhost:5173后端接口是http://localhost:8080浏览器的同源策略会把两者当跨域处理。解决方式首选Vite的proxy代理// vite.config.js server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }这样前端请求/api/community/overview时Vite开发服务器会转发到后端的8080端口浏览器视角不存在跨域问题。如果走独立部署那就要在后端配置CorsFilter允许指定来源或者通过Nginx做反向代理统一转发。4.3 控制台中文乱码的解决思路IDEA控制台输出中文乱码是比较常见的问题本质是编码不一致。解决方式是在IDEA的Help菜单下找到Edit Custom VM Options在文件末尾加上-Dfile.encodingUTF-8同时数据库连接URL上加上characterEncodingutf8。做完这两步再重启项目基本就能解决。4.4 前端打包并集成到SpringBoot毕设演示时最稳妥的方式是前后端独立启动浏览器开两个终端窗口。但如果答辩环境网络受限或者你想做一个单体启动的演示包可以把Vue项目打包后的dist目录复制到SpringBoot的src/main/resources/static下。执行前端npm run build后把dist里的文件拷入static重新启动后端访问http://localhost:8080即可看到完整界面。这里有一个必须注意的坑前端如果是用history路由模式直接访问某个子路径如/bill/list会返回404。解决方式有两种一是把路由模式改成hash模式URL带#二是在SpringBoot里配置一个转发规则将非接口路径全部转发到index.html。毕设阶段我建议直接使用hash模式简单不折腾。5. 实际踩过的坑与答辩高频问题这一部分我想分享几个真正影响进度的细节还包括答辩时你极大概率会被问到的几个设计问题。5.1 版本兼容性问题汇总我整理了一张表格把这些坑和对应的解决方案都列出来问题表现产生原因解决方案引入javax.servlet包报错SpringBoot 3.x改为jakarta.servlet使用SpringBoot 2.7或替换importMyBatis-Plus分页不生效缺少PaginationInnerInterceptor配置MybatisPlusInterceptorLombok注解失效Lombok版本和JDK版本不匹配JDK8用1.18.24以下JDK17用1.18.30前端访问接口报404后端接口路径是/api开头但没在映射路径上检查controller的RequestMapping保证统一前缀el-select下拉不回显v-model绑定的是对象而不是value确认绑定字段是id或对应的value值这些坑几乎每个做全栈毕设的人都会碰到提前知道能省下一两天。5.2 答辩追问数据关系、权限控制、异常处理、系统亮点答辩老师通常不打代码而是围绕项目设计逻辑提问。最容易被问到的几个点业主和房屋是什么关系。我的回答是一套房屋可以登记多位共同居住人因此用关联表维护绑定关系账单和工单都是以房屋为核心。权限控制怎么做的。我讲了JWT生成与校验、后端拦截器、前端路由守卫三层老师最想听的就是这种“有层次”的答案。系统有什么亮点。我提前准备的两个点一是首页提供小区运营总览的聚合统计二是工单状态机闭环设计让业主能追踪进度。这两个点来自真实需求不是硬凑的功能。如果并发量大了怎么办。这是一个送分题可以答加上Redis缓存热点数据、MySQL读写分离、使用消息队列解耦推送。5.3 做完系统之后还可以扩展什么这个题目做完不是终点后面扩展空间很大。比较自然的延伸方向有三个对接支付接口让账单可以在线真实支付增加预约访客功能使用小程序端让业主和物业随时随地进行操作引入告警监控模块对接门禁、水电表等IoT设备数据。无论选哪个方向都可以把“智汇家园”从管理系统升维成一个小型社区数字化平台。根据我做完这个项目的体会最深的感觉是一个毕设系统能不能拿高分关键不在于功能堆了多少而在于每个设计决定背后能不能给出合理的理由。把“房屋作为业务核心”这条线讲透把“前后端权限配合”这条链路打通再把部署联调踩过的坑提前填平这个项目不仅能过而且可以成为你简历上一个有清晰思路、有技术深度的全栈项目。最后再分享一个技巧打磨项目时把自己想象成用户一位刚入住小区的业主逐个操作一遍页面你就会发现很多设计不合理的地方改完之后系统的“完成度”会提升得非常明显。
把“智汇家园管理系统”做成一个毕设课题很多人第一反应就是“这不就是一个带界面的增删改查吗”。说实话我第一次拿到这个题目时也这么想但真正动手拆解之后才发现难点根本不是某个页面怎么写而是整个课题背后那套业务关系、角色边界、前后端协作方式以及验收时怎么把“能跑”变成“能讲”。这篇文章我就以“智汇家园管理系统”为例完整梳理一条从业务建模、后端接口设计、前端工程化到本地启动联调、答辩问答的落地路径。项目使用SpringBoot做服务端、Vue做前端页面适配正在做毕设或者想快速上手全栈项目的同学也是给那些“代码能跑但讲不清楚为什么这么设计”的人补一课。1. “智汇家园”到底在管理什么先搞清楚业务模型再动手写代码很多同学拿到这个题目会先建表然后急着写接口。我建议反过来先拿一上午想明白这个系统未来的使用者是谁他们要完成什么任务系统里最高频的操作是什么。1.1 以“物”为核心的管理视角“智汇家园”这四个字听起来很宽泛但落到小区管理场景核心其实是“管物”而不是“管人”。这里的“物”指的是楼栋、房屋、车位、公共设施“人”指的是业主、住户、租客、物业人员。所有业务流转本质上都是人和物产生关联之后引发的业主缴费、住户报修、物业派单、访客登记、公告通知这些动作都可以归到某个房屋或某个设施上。所以我在设计数据库时把小区community、楼栋building、房屋house作为基础档案住户resident与房屋通过绑定关系表关联而缴费账单、报修工单、投诉建议这些业务数据全部记录所属房屋编号。这样做的好处是后续统计非常方便某个楼栋这个月的缴费率是多少某类设施报修频次高不高都能通过房屋这个核心字段快速聚合。1.2 三条核心业务流整个系统虽然表不少但逻辑上有三条主线工单流业主或住户提交报修/投诉 - 物业管理员接单 - 派发给维修人员 - 维修后回填结果 - 业主评价。这条流是系统里最复杂的一条因为涉及状态机变化。账单流物业生成水电物业账单 - 住户查看 - 缴费毕设阶段可模拟支付 - 账单状态更新 - 历史缴费统计。通知流物业发布公告 - 系统推送给绑定住户 - 住户在首页查看 - 消息已读回执。建议在开发前把这三条链路画成状态流转图每个状态对应一个后端枚举前端下拉选项和按钮显隐都依据后端返回的状态字段来控制。这样做之后前后端联调会省非常多力气至少不会出现“前端不知道这个按钮什么时候可点”的尴尬。1.3 角色权限的设计取舍家园系统天然有至少两类角色物业端和住户端。物业端里还可以细分管理员、客服、维修工但作为毕设系统我不建议一上来就把RBAC基于角色的权限控制做得特别重。一个比较务实的设计是系统内置三种固定角色即系统管理员、物业员工、业主住户权限表做成固定的关联关系而不是做成完全可配置的动态权限。我在权限上采用的是“JWT 后端拦截 前端路由守卫”三层配合。后端用一个拦截器校验JWT是否有效、是否放行前端根据登录用户的角色动态生成可访问的路由菜单。这样既体现了一定的技术工作量答辩时又能清楚讲出每一层负责什么。2. 后端设计与搭建SpringBoot项目分层、核心表与接口实现后端是整个项目的重心SpringBoot框架本身封装得很好但初学阶段很容易陷入“能跑就行、结构混乱”的状态。我建议严格按照分层的思想去建包哪怕代码量不大也要让路径结构看起来是“有设计”的。2.1 项目分层与包结构规范一个适合毕设展示的SpringBoot后端结构大致如下com.home.smart ├── controller # 接口层只做参数接收与结果返回 ├── service # 业务层处理核心逻辑 │ └── impl ├── mapper # MyBatis-Plus的Mapper接口 ├── entity # 数据库实体类 ├── dto # 前端传输对象避免直接暴露entity过多字段 ├── vo # 视图对象封装返回给前端的数据 ├── config # 配置类例如拦截器、跨域、分页插件 ├── common # 公共类统一返回体、异常处理、工具类 └── security # JWT工具、登录拦截、注解这种结构的核心思路是controller不写任何业务逻辑只负责接收请求、调用service、把结果包装成统一返回体service层处理核心规则mapper层只做数据库交互。面试官或答辩老师看到这种分层第一印象就会好很多因为这说明你不是把代码全堆在一个类里。统一返回体的设计也很关键。我封装了一个Result类包含code、message、data三个字段例如登录成功返回code200参数错误返回code400业务异常返回code500。所有接口都返回这个格式前端axios拦截器只需要判断code就能决定是正常渲染还是弹错误提示。2.2 核心表设计与接口划分下面是我最终落地的核心表清单以及每一张表的核心作用表名关键字段作用说明community小区名称、地址、物业公司顶层组织档案building楼栋编号、层数、单元数关联小区house房号、面积、户型、状态可售/已入住/空置resident姓名、手机号、身份证号、角色住户信息档案owner_house住户ID、房屋ID、关系类型住户与房屋的绑定关系bill房屋ID、费项、金额、周期、状态缴费账单repair_order房屋ID、报修内容、状态、处理时间报修工单notice标题、内容、发布人、发布时间公告通知visitor访客姓名、手机号、被访房号、时间访客登记complaint投诉内容、回复内容、状态投诉建议这些表之间的关系在答辩时大概率会被问到比如“业主和房屋是多对多还是一对多”“账单和房屋是什么关系”。实际业务中一套房子可能存在多个共同居住人所以我把住户与房屋设计成绑定关系表这样既保留了业务扩展性又不会让表结构复杂到把自己绕晕。接口设计遵循RESTful风格核心接口如下POST /api/auth/login # 登录返回JWT GET /api/community/overview # 首页统计小区楼栋数、住户数、待处理工单数 POST /api/house/page # 分页查询房屋信息 POST /api/resident/register # 业主/住户登记 GET /api/bill/list # 账单列表支持按房屋、月份筛选 POST /api/repair/create # 提交报修工单 POST /api/repair/handle # 处理工单接单、完工、回填结果 POST /api/notice/publish # 发布公告 GET /api/notice/list # 查询公告这里有个细节需要注意查询接口如果参数较复杂我推荐用POST body传参简单查询则用GET。不要所有接口都用POST答辩时容易被问“为什么不用GET”最好能说出差异。2.3 依赖选型与版本适配的实用建议依赖选型上我用了SpringBoot 2.7.18 JDK8 MyBatis-Plus 3.5.3 MySQL 8.0 JWTjjwt这套组合。为什么不追新用SpringBoot 3.x因为3.x基于JDK17并且javax.servlet迁移到了jakarta.servlet很多教材和老博客里的代码会报包不存在对于毕设交期和踩坑成本来说并不划算。如果你确实想用3.x一定要把MyBatis-Plus、PageHelper这类中间件的版本先确认好否则编译期会卡很久。MyBatis-Plus在毕设里几乎是“标配”因为它把单表CRUD省到了极致。实体类上标注TableName和TableId后继承BaseMapperT就有了一整套单表方法。分页则通过配置PaginationInnerInterceptor实现Configuration public class MybatisPlusConfig { Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }使用分页时service里返回PageHouseVO即可前端传入pageNum和pageSize两个参数。MyBatis-Plus会自动拼接LIMIT语句并且total字段会同步返回前端分页组件直接使用即可。2.4 后端细节JWT登录与全局异常处理登录模块使用JWT无状态认证。用户在登录成功后后端生成一个包含用户ID和角色的token字符串返回给前端前端存在localStorage里并在每次请求的Authorization头带上。后端拦截器校验token的签名和有效期然后把解析出的用户信息放入ThreadLocal供后续业务代码使用。Python、Node里写JWT其实有各种库但Java里我推荐用jjwt 0.9.1版本使用方式比较固定String token Jwts.builder() .setSubject(String.valueOf(user.getId())) .claim(role, user.getRole()) .setExpiration(new Date(System.currentTimeMillis() 86400000)) .signWith(SignatureAlgorithm.HS256, SECRET_KEY) .compact();解析时则通过Jwts.parser().setSigningKey(SECRET_KEY).parseClaimsJws(token).getBody()拿到Claims。全局异常处理我直接用RestControllerAdvice捕获业务异常和兜底异常统一封装成Result返回。一个常见的坑是自定义业务异常如果没有被全局捕获前端会收到默认的500错误页既无法获取message又不好定位。所以建议把BusinessException的捕获写死确保所有错误都能以前端认识的JSON形态返回。3. 前端工程搭建Vue3 Element Plus Router权限控制前端部分我采用的是Vue3 Vite Element Plus Pinia Axios的组合。相比Vue2webpack这套方案启动更快组合式API写起来也更顺手。如果学校要求必须用Vue2那语法上就要回调式的写法不过核心思路不变。3.1 前端目录结构与工程化组织Vue前端我会按下面这种方式组织目录src ├── api # 接口请求模块按业务分文件user.js, home.js, bill.js... ├── assets # 静态资源 ├── components # 公共组件 ├── router # 路由配置文件 ├── stores # Pinia状态管理 ├── views # 页面视图 └── utils # axios封装、工具函数api目录里每个文件对应一个业务模块例如bill.js里导出获取账单列表、生成账单、删除账单等方法。这样做的好处是页面里不直接写axios请求地址统一走api模块后续如果要改接口地址或加拦截逻辑只需改一处。3.2 路由与动态菜单的方案Vue Router在管理员和业主之间需要做区分。我采用的是静态路由承载登录页、404页动态路由承载业务菜单的方案。用户登录后后端返回该角色允许访问的菜单标识前端根据标识映射到对应的路由组件并动态添加到router中。路由守卫的逻辑大致是router.beforeEach(async (to, from, next) { const token localStorage.getItem(smart_token) if (!token to.path ! /login) { next(/login) } else { next() } })动态菜单生成时最省事的方式是在路由meta里声明roles字段然后通过router.addRoute按需添加。初次接触时容易遇到刷新页面后动态路由丢失的问题所以需要把菜单数据缓存到Pinia或localStorage刷新时重新拉取并addRoute。3.3 Axios请求封装与Pinia存储Axios封装是前端的一个必考知识点。我在utils/request.js里创建了一个axios实例设置baseURL为/api然后添加请求拦截器自动带token和响应拦截器统一处理code、错误提示、401跳登录。这样业务代码里不需要每次手动处理错误写起来会舒服很多。Pinia用来存储全局状态用户信息、token、菜单、已读公告。例如登录成功后把用户对象存入userStore页面显示用户名、控制按钮显隐都从这里取。相比VuexPinia的API更简洁而且天然支持组合式API的setup写法。3.4 几个页面实现的细节首页概览使用ECharts做柱状图和饼图展示各楼栋入住率、费用收缴率、维修工单状态分布。数据来源是后端聚合接口只返回统计结果图表渲染在前端做。报修工单列表状态用el-tag区分颜色待处理用danger色处理中用warning已完成用success。按钮根据状态显隐例如“派单”只在待处理状态可见。表单校验使用Element Plus的表单校验规则比如手机号、身份证号的正则校验。这里有个小坑身份证号是18位末尾可能是X正则要兼容大小写。分页组件与后端Page对象对齐监听current-change和size-change事件重新拉取数据。前端最常遇到的报错大致可以分成三类跨域报错、token过期导致的401、后端返回字段名与前端不一致。第一种通过Vite的proxy配置解决第二种在响应拦截器里统一跳转第三种则需要定期核对后端VO字段。4. 本地启动与联调从IDEA配置到dist打包并入SpringBoot很多同学卡住的往往不是写代码而是“怎么把项目跑起来”。这里我完整走一遍从IDEA配置到前后端联调、整体打包的思路。4.1 在IDEA里配置SpringBoot启动项打开IDEA后勾选Maven面板的spring-boot-maven-plugin然后找到启动类标注SpringBootApplication的类右键选择Run即可。IDEA 2026之后的版本中启动项配置入口略有变化可以在运行配置里添加Spring Boot类型的Configuration指定Main Class。端口修改有两种方式一是在application.yml中配置server.port二是在运行配置的Environment variables里设置SERVER_PORT8081。日常开发推荐用第一种清晰直观。启动遇到“Port 8080 was already in use”时改端口或者在终端用lsof -i:8080找到占用进程并结束它。很多同学在这个环节卡住觉得是代码有问题其实只是端口冲突。4.2 前端Vite代理与后端跨域前后端分离开发时前端页面地址是http://localhost:5173后端接口是http://localhost:8080浏览器的同源策略会把两者当跨域处理。解决方式首选Vite的proxy代理// vite.config.js server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true } } }这样前端请求/api/community/overview时Vite开发服务器会转发到后端的8080端口浏览器视角不存在跨域问题。如果走独立部署那就要在后端配置CorsFilter允许指定来源或者通过Nginx做反向代理统一转发。4.3 控制台中文乱码的解决思路IDEA控制台输出中文乱码是比较常见的问题本质是编码不一致。解决方式是在IDEA的Help菜单下找到Edit Custom VM Options在文件末尾加上-Dfile.encodingUTF-8同时数据库连接URL上加上characterEncodingutf8。做完这两步再重启项目基本就能解决。4.4 前端打包并集成到SpringBoot毕设演示时最稳妥的方式是前后端独立启动浏览器开两个终端窗口。但如果答辩环境网络受限或者你想做一个单体启动的演示包可以把Vue项目打包后的dist目录复制到SpringBoot的src/main/resources/static下。执行前端npm run build后把dist里的文件拷入static重新启动后端访问http://localhost:8080即可看到完整界面。这里有一个必须注意的坑前端如果是用history路由模式直接访问某个子路径如/bill/list会返回404。解决方式有两种一是把路由模式改成hash模式URL带#二是在SpringBoot里配置一个转发规则将非接口路径全部转发到index.html。毕设阶段我建议直接使用hash模式简单不折腾。5. 实际踩过的坑与答辩高频问题这一部分我想分享几个真正影响进度的细节还包括答辩时你极大概率会被问到的几个设计问题。5.1 版本兼容性问题汇总我整理了一张表格把这些坑和对应的解决方案都列出来问题表现产生原因解决方案引入javax.servlet包报错SpringBoot 3.x改为jakarta.servlet使用SpringBoot 2.7或替换importMyBatis-Plus分页不生效缺少PaginationInnerInterceptor配置MybatisPlusInterceptorLombok注解失效Lombok版本和JDK版本不匹配JDK8用1.18.24以下JDK17用1.18.30前端访问接口报404后端接口路径是/api开头但没在映射路径上检查controller的RequestMapping保证统一前缀el-select下拉不回显v-model绑定的是对象而不是value确认绑定字段是id或对应的value值这些坑几乎每个做全栈毕设的人都会碰到提前知道能省下一两天。5.2 答辩追问数据关系、权限控制、异常处理、系统亮点答辩老师通常不打代码而是围绕项目设计逻辑提问。最容易被问到的几个点业主和房屋是什么关系。我的回答是一套房屋可以登记多位共同居住人因此用关联表维护绑定关系账单和工单都是以房屋为核心。权限控制怎么做的。我讲了JWT生成与校验、后端拦截器、前端路由守卫三层老师最想听的就是这种“有层次”的答案。系统有什么亮点。我提前准备的两个点一是首页提供小区运营总览的聚合统计二是工单状态机闭环设计让业主能追踪进度。这两个点来自真实需求不是硬凑的功能。如果并发量大了怎么办。这是一个送分题可以答加上Redis缓存热点数据、MySQL读写分离、使用消息队列解耦推送。5.3 做完系统之后还可以扩展什么这个题目做完不是终点后面扩展空间很大。比较自然的延伸方向有三个对接支付接口让账单可以在线真实支付增加预约访客功能使用小程序端让业主和物业随时随地进行操作引入告警监控模块对接门禁、水电表等IoT设备数据。无论选哪个方向都可以把“智汇家园”从管理系统升维成一个小型社区数字化平台。根据我做完这个项目的体会最深的感觉是一个毕设系统能不能拿高分关键不在于功能堆了多少而在于每个设计决定背后能不能给出合理的理由。把“房屋作为业务核心”这条线讲透把“前后端权限配合”这条链路打通再把部署联调踩过的坑提前填平这个项目不仅能过而且可以成为你简历上一个有清晰思路、有技术深度的全栈项目。最后再分享一个技巧打磨项目时把自己想象成用户一位刚入住小区的业主逐个操作一遍页面你就会发现很多设计不合理的地方改完之后系统的“完成度”会提升得非常明显。
