SpringBoot+微信小程序物业管理系统：从报修工单到智慧社区

1. 选题拆解与整体技术方案

1.1 医院家属小区和普通小区到底差在哪

我接手这个选题的时候，第一反应是“这不就是个物业管理系统吗”。真去现场看过才明白，医院家属小区和外面的普通商业小区，在物业管理上完全是两套逻辑。

首先，医院家属院通常不是完全开放式的围墙小区，就是半封闭的职工生活区，进出人员以医院职工、家属、退休老专家为主。白天医生护士要倒班，访客、快递、外卖、护工进出频繁，但小区安保力量又很薄弱。其次是住户特征，这里的业主群体里老年人比例特别高，很多是医院退休职工，子女白天都在上班，物业公告贴在一楼大厅，真正能看到的人少得可怜。报修、缴费、访客登记这些琐事，如果都靠楼下值班室一本台账登记，效率低不说，遇到交接班漏记是常有的事。

所以这套系统的核心价值，不是做一个“漂亮的管理后台”，而是要把以前靠电话、靠纸质登记的物业流程，全部搬到线上，让医生护士在手术间隙能用手机快速报修，让退休老职工在家点两下就能找人通下水道，让门卫在值班室扫一眼二维码就能放行来访人员。

从毕业设计角度来说，这个选题也非常“稳”。物业管理系统包含业主绑定、报修工单、缴费账单、访客登记、公告通知几条核心业务线，每个模块都有明确的状态流转，拿来练SpringBoot和小程序开发再合适不过，后期答辩也能把业务逻辑讲得很清楚。

1.2 为什么是SpringBoot加微信小程序这套组合

技术选型上，SpringBoot加微信小程序已经是当前Java毕业设计里最主流的搭配之一，理由很实在。

服务端用SpringBoot，是因为它在Java生态里已经把配置简化到了极致。早期SSH、SSM那套要写一大堆XML配置的时代已经过去，SpringBoot通过自动装配让项目开箱即用。到Spring Boot 2.7这个版本，按需引入web、mybatis、redis等starter就能跑起来，适合大部分高校课题和学生团队。

小程序端选微信小程序，核心原因是“免安装”。对业主来说，为小区单独装一个App完全不现实，但微信是人人都在用的，扫码即用，用完即走。对医院家属院这种场景来说，目标用户很多是退休老人，小程序的门槛比任何原生App都低得多。而且微信小程序自带登录体系和订阅消息能力，后端不需要自己搞短信平台就能做通知推送，这对开发成本是极大节省。

管理端方面，我的建议是别一上来就搞Vue前后端分离。虽然热词里不少人搜“springboot vue前后端分离”，但作为毕设，如果时间不够，管理端直接用Spring Boot的Thymeleaf模板引擎做几个页面就够用了。真有富余时间再上Vue，把业主管理、房屋管理、工单处理、账单生成这些页面独立出来，前后端通过JSON接口交互，也是一条很顺的路。

1.3 整体模块划分与项目结构

系统严格来说分三个端：业主使用的小程序端、物业人员使用的管理端、提供接口和业务逻辑的SpringBoot后端。

• 小程序端：首页（公告轮播、快捷入口、天气问候）、报修大厅、缴费中心、访客邀请、我的（个人信息、房屋绑定、工单记录、账单历史）；
• 管理端：系统登录、小区楼栋管理、房屋管理、业主审核、报修工单派单与处理、缴费账单生成与催缴、访客记录查询、公告发布；
• 后端公共模块：用户身份认证（微信登录）、权限拦截、统一返回结构、全局异常处理、定时任务、文件上传。

后端项目包结构我建议按模块分工，大概长这样：

com.hospital.property ├── config // 配置类：Redis、拦截器、WebMvc ├── controller // 接口层 ├── service // 业务层 ├── mapper // MyBatis的Mapper层 ├── entity // 数据库实体类 ├── dto // 前端传参对象 ├── vo // 后端返回对象 ├── common // 通用返回体、常量、异常处理 ├── utils // 工具类：JWT、二维码生成、日期处理 └── task // 定时任务：账单生成、访客码过期清理

我用的是这种最常规的分层结构，好处是代码一眼就能看懂，不花哨，而且写毕业论文的时候“分层架构”部分特别好描述。

2. 数据库设计与核心建模

2.1 用户身份与房屋关系建模

物业系统的第一个核心问题是“怎么把人和房子绑定起来”。这套系统的用户分为业主、家属住户、物业管理员、维修工几个角色，但小程序端其实不需要做太复杂的角色区分，重点是把“登录用户”和“房屋”绑定上。

我设计了四张基础表：用户表、楼栋表、房屋表、业主房屋绑定表。

用户表主要字段：

房屋绑定表上，我专门加了audit_status字段，业主第一次绑定房屋后需要物业在后台审核通过才能使用缴费、报修功能。这里多加一个审核机制完全值得，避免随便一个人输入房号就绑定了别人的房子，这是最容易出问题的环节。

2.2 报修工单表的状态流转设计

报修是整个小程序里用户使用频率最高的功能，它的状态设计直接决定项目质量。我见过很多同学报修表只放一个status，然后前端根据status显示“处理中”“已完成”，太粗糙了，答辩时很容易被追问细节。

建议至少保留这几个状态：

整套流程里最容易被忽略的是“待确认”这个状态。很多毕设里报修单修完就结束了，但实际上维修工做完活需要住户确认才行，否则修没修好没有闭环。这个状态加进去之后，接口逻辑、前端页面都要对应处理，虽然多写了一部分代码，但对项目的完整性提升很大。工单表里还要记录报修描述、现场图片（多图）、预约时间段、联系手机号、维修工姓名、完成时间、用户评价星级。

2.3 缴费账单设计

缴费模块我用的方案是“后台生成账单，小程序端查询和在线记录缴费”。不是真的接入微信支付，而是生成账单后引导业主在物业处缴费或模拟支付，毕设完全够用。如果是本科毕设，不建议碰微信支付，申请商户号、证书、回调验签这些能弄掉你半个月时间。

缴费表字段：账单编号、绑定关系ID（哪户）、费用类型（物业费、水费、电费、停车费）、金额、计费周期、生成时间、缴费截止时间、状态（0未缴 1已缴 2已逾期）、缴费时间、缴费方式。

其中有一个容易踩坑的点是“逾期状态”怎么算。我的做法是写一个定时任务，每天凌晨三点跑一次，把截止时间小于当前时间且status为0的账单扫出来更新为已逾期。这种需求不要在前端算时间差，后端统一处理才是正规做法，也方便在答辩时讲定时任务的场景。

2.4 访客登记与公告

访客模块做的是“业主生成访客邀请码，门卫扫码放行”。核心是一张访客记录表，包含业主ID、访客姓名、访客手机、车牌号、来访事由、预计到达时间、有效期、随机码。随机码可以直接用UUID截取，比如8位数字字母组合，生成二维码时把ID和随机码拼接成一个字符串让门卫扫码。

公告通知表简单，title、content、type（通知、活动、停水停电）、publisher、create_time就够了。小程序首页用列表拉取最新的公告，后端可以做分页或者“只取最近20条”。

数据库设计做完，建议把所有建表SQL保存成一份init.sql，项目初始化的时候一键执行。我自己的做法是每次都把mysql建库、建用户、授权、导入表结构这几步写成脚本，换机器、交毕设演示的时候都省心。

3. 后端核心功能实现与关键代码

3.1 微信登录与code换token机制

小程序端用户首次打开会调用wx.login()获取一个临时的code，这个code的有效期只有5分钟，而且只能用一次。后端拿到这个code后，调微信的接口jscode2session，换取到这个用户在小程序生态里的唯一标识openid。

这里呼应一下网上常见的“微信小程序用code换token”的说法。真正生产环境里，后端拿到openid后不会直接把这个openid返回给前端，因为openid本身就是敏感信息，只要泄露了，别人就可以伪装成这个用户。正确做法是：后端生成一个自定义的token（比如用UUID或者JWT），然后把这个token和openid的映射关系存到Redis里，设置7天或30天过期时间，token返回给小程序端，小程序端后续所有请求都在请求头里带这个token。

代码核心流程：

@PostMapping("/login") public R login(@RequestBody LoginDTO dto) { // 1. 调微信接口换取openid String url = "https://api.weixin.qq.com/sns/jscode2session?appid=" + appid + "&secret=" + secret + "&js_code=" + dto.getCode() + "&grant_type=authorization_code"; String result = restTemplate.getForObject(url, String.class); JSONObject obj = JSON.parseObject(result); String openid = obj.getString("openid"); // 2. 根据openid查用户表，不存在则自动注册 User user = userMapper.selectByOpenid(openid); if (user == null) { user = new User(); user.setOpenid(openid); user.setCreateTime(new Date()); userMapper.insert(user); } // 3. 生成token存redis，设置过期时间 String token = UUID.randomUUID().toString().replace("-", ""); redisTemplate.opsForValue().set("login:token:" + token, String.valueOf(user.getId()), 7, TimeUnit.DAYS); return R.ok().put("token", token).put("userId", user.getId()); }

这里再提醒一句，微信小程序的secret是敏感信息，一定不要写在小程序前端，只能存在后端。很多初学者会把appid和secret放在小程序代码里，这是极其严重的错误，审核不一定查得出来，但只要是公开代码，就等于把账号的钥匙交出去了。

后端还需要加一个登录拦截器，处理所有需要登录的接口。拦截器从请求头取到token，查Redis，查到就放行并把userId放到ThreadLocal里，后面业务代码直接取。查不到就返回401，让小程序端重新登录。

3.2 报修工单的后端状态机

报修模块的后端接口不多，核心是提交报修、物业端接单/派单、用户端确认完成/取消、查询详情这几个。但状态流转逻辑要写严谨。

提交报修的时候，前端上传图片会先请求一个上传接口，后端把图片保存到本地或OSS，返回URL后再随报修单一起提交。这里需要注意文件大小限制和格式校验，我在配置里限制了单张图片最大5MB，只允许jpg、png格式。不懂这个小细节的话，真机调试时传一张手机拍的大图就直接报错了。

后端接单和派单，我建议写成一个接口完成。物业人员在管理端点了“接单”之后，后端立刻把维修工默认指派为当前登录的管理员，同时把状态从0改成2。这样设计的逻辑是：小物业公司维修工往往就是管理员本人，没必要把接单和派单拆成两步。

用户确认完成的接口最好加上一个校验：只有这个工单的绑定人才能操作，不能让别人点了确认。实现方式也不复杂，就是从数据库里查工单，看它的house_bind_id对应用户ID是否等于当前登录用户ID。

3.3 账单生成与定时任务

账单生成是管理端的一个核心操作。我的设计是：物业人员在后台选择某个楼栋、选择费用类型、输入单价，点击生成，后端遍历该楼栋下所有绑定过且审核通过的房屋，为每户生成一张当月账单。这里有个细节，如果是按面积收物业费，房屋表里要有area字段，单价乘以面积得到金额，然后写入账单表。

定时任务这块我用的是Spring的@Scheduled注解，在启动类上加@EnableScheduling。主要有两个任务：每天凌晨扫描逾期账单；每天凌晨清理过期访客记录。如果后面想扩展，还可以加一个“每周给欠费业主推送订阅消息”的任务。

@Component public class BillTask { @Scheduled(cron = "0 0 3 * * ?") public void updateOverdueBills() { // 更新所有截止时间 < now 且 status=0 的账单为2逾期 billMapper.updateOverdue(); } }

定时任务在生产里会有很多讲究，但毕设里能把这个场景写出来，说明你对SpringBoot的生命周期和异步调度有一定的认识，答辩时是一个加分项。

3.4 Redis在项目里的具体用法

热词里有人搜“redis在springboot中的使用”，这个项目里Redis至少有三个场景可以用到。

第一个是登录token存储，前面已经说了。第二个是验证码场景，如果做“手机号绑定”功能，发送短信验证码需要把验证码存Redis，设置5分钟过期。但做毕设一般不接真实短信SDK，可以在控制台打印验证码，或者加个开关，测试环境固定验证码。千万不要把验证码存MySQL，这种“一次性凭证”天然适合Redis。

第三个是缓存场景。比如首页公告列表，可以用Redis缓存10分钟，减少数据库压力。但说实话，毕设这种量级，数据库不缓存也完全没压力，纯属锦上添花。我建议把登录token和验证码这两个场景用起来就够了，答辩时能解释清楚为什么用Redis而不用数据库就行：数据库的读取是磁盘IO，Redis是内存操作，速度差一个数量级，而且可以设置键自动过期。

4. 小程序端关键页面与交互细节

4.1 小程序页面规划与底部导航

小程序端我规划了4个主Tab：首页、报修、访客、我的。缴费功能不单独占一个Tab，而是放在首页的功能入口里和“我的”页面里。原因很简单：底部Tab超过5个就不合适了，而缴费和报修相比，报修是更高频的操作，访客邀请也是一个相对独立的功能，值得单独一个Tab。

底部导航在app.json里配置：

{ "pages": [ "pages/index/index", "pages/repair/index", "pages/visitor/index", "pages/mine/index" ], "tabBar": { "list": [ { "pagePath": "pages/index/index", "text": "首页" }, { "pagePath": "pages/repair/index", "text": "报修" }, { "pagePath": "pages/visitor/index", "text": "访客" }, { "pagePath": "pages/mine/index", "text": "我的" } ] } }

tabBar的图标需要准备png图片，iconPath和selectedIconPath两个都要配，尺寸是81px*81px，不支持网络图片，必须放到项目本地。

4.2 登录流程与用户信息获取

小程序的登录在onLaunch里做：先检查本地缓存有没有token，没有再调用wx.login获取code，然后请求后端登录接口，拿到token后存储到storage。一定不要写成每次打开小程序都立刻弹出授权框，那种体验很差。首次登录返回的user为null时，后端自动注册，前端拿到userId后跳转到“完善资料”或“绑定房屋”页面。

用户授权头像昵称，现在微信已经改了规则，wx.getUserProfile在基础库版本比较新的环境下只能获取到“微信用户”这个默认昵称。现实中更常见的做法是：在小程序里让用户自己填写昵称、上传头像，或者直接用微信的“头像昵称填写能力”（button组件的open-type="chooseAvatar"）。这里给个提醒，做毕设如果经常出现头像昵称获取不到，不一定是代码问题，是微信平台策略调整，别在这里死磕太多时间。

4.3 表单填写与图片上传

报修页面是小程序端技术含量最高的页面，因为涉及表单校验和多图上传。用户填写描述、选预约时间、上传图片，整个页面的交互要处理好。上传接口用wx.uploadFile，这个是单独走HTTP的multipart请求，和普通的wx.request不一样，不能混着用。

图片上传的痛点在于：用户可能传了3张图，但传到第2张时网络断了。前端要做好状态管理，我的做法是上传中显示进度，上传成功后把返回的URL存到数组，全部传完后再提交报修数据。有人为了省事，选完图片就立刻提交，结果接口慢、失败率高，这种体验在答辩演示现场特别容易翻车。

4.4 小程序端组件踩坑实录

热词里有个很典型的报错：“component "pages/index/index" does not have a method "navigatorcl...”。这个我曾经也碰到过，通常是把bindtap写成了bind:tap或者事件名拼错，再或者是事件名和data里的字段重名了。排查思路很固定：打开页面的js文件，确认methods或Page对象里有没有对应方法；没有就补上，方法名前别加冒号，事件绑定要写bindtap="方法名"；如果是从自定义组件里跳转的，也要检查组件里是否定义了该方法。

另外一个经常踩的坑是scroll-view内部放uni-datetime-picker这类弹层组件，在iOS上会被滚动容器裁切。这属于微信小程序的渲染机制问题，热词里也有人搜。解决办法是：不要在scroll-view里直接放弹窗类组件，弹层挂到页面根部，或者用position: fixed配合合适的层级，避免被裁剪。

5. 管理端设计、部署与上线要点

5.1 管理端用模板引擎还是前后端分离

管理端我在前面已经给出了建议，时间不够就走Thymeleaf模板引擎加Bootstrap的方案。这套方案的好处是不需要单独启动前端项目，SpringBoot打包成一个jar，管理页面由后端直接渲染，部署特别省心。

如果已经掌握Vue，时间也充裕，那就用SpringBoot+Vue前后端分离，页面放在Vue项目里，通过Nginx转发请求到后端；打包时也可以直接把Vue的dist目录拷贝到SpringBoot的static目录下，一个jar包搞定。两种方案都合法，关键是别到最后两周才纠结这个，早做决定早动手。

5.2 房屋数据初始化与业主审核

小区楼栋信息不可能靠物业人员手动一条条在页面上添加，我写了一个Excel导入功能：管理端先下载模板，填写楼栋号、单元号、房号、面积，然后上传，后端用EasyExcel解析批量插入楼栋表和房屋表。这一块特别适合写进论文里的“系统实现”部分，是一个很完整的业务场景。

业主审核列表要做得清晰一点，表格字段包括：申请人微信昵称、姓名、手机号、绑定房屋、审核状态、申请时间。管理员点击“通过”后，状态更新为1，同时在记录里写个审核人ID。审核通过后，小程序端业主刷新“我的”页面就会发现房屋状态从“待审核”变成“已绑定”。这里的实时刷新不需要用WebSocket，只要用户进页面时重新调接口就行了，毕设没必要上实时推送。

5.3 服务器环境部署配置

后端部署时要装JDK、MySQL（或MariaDB）、Redis、Nginx。以最省事的打包方式为例，本地执行mvn clean package -DskipTests，生成target目录下的jar包，上传到服务器的/opt/property目录，然后用nohup后台启动：

nohup java -jar property-system.jar \ --spring.profiles.active=prod \ --server.port=8080 > app.log 2>&1 &

MySQL和Redis的连接配置要单独放在application-prod.yml里，方便切换本地环境和服务器环境。同时生产环境一定要开数据库账号密码，不要用root空密码这种危险配置。

HTTPS证书需要提到最前面讲。小程序request和uploadFile接口的合法域名必须是HTTPS，而且域名不能是IP地址。云开发环境一般自带HTTPS域名，但自建服务器的话需要申请证书。毕设阶段还有一种临时方案：在微信开发者工具的“详情-本地设置”里勾选“不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书”，这样本地开发可以直接请求http://localhost:8080。但注意，这个选项只对开发者工具和真机调试生效，真机上如果关闭了调试模式，同样会被拦。所以演示前一定要确认，要么域名和证书配好，要么一直开着真机调试模式。

6. 高频问题与排查避坑实录

6.1 SpringBoot版本太高导致的连环坑

现在网上很多教程还在讲Spring Boot 2.x的用法，但新建项目时会发现Spring Initializr默认生成的可能已经是3.x。Spring Boot 3.0以后有几个大变化一定要知道。

第一，最低要求JDK 17。如果你的电脑只装了JDK 8，直接启动都启动不了，先装JDK 17。当前环境如果项目必须用JDK 8，老老实实创建项目时把Spring Boot版本改成2.7.x。

第二，Springfox的Swagger2从2.6以上版本开始就不兼容了。以前常用的springfox-swagger2和springfox-swagger-ui，在Spring Boot 2.6以上会出现空指针异常，网上大量帖子都有提过。我在2.7.18版本上实测过，单独引入springfox依然有问题，更别说3.x。如果只是需要接口文档，直接引入springdoc-openapi-starter-webmvc-ui，然后通过/swagger-ui.html访问，这是目前兼容性最好的方案。

第三，Spring Boot 3.x里javax包全部改成了jakarta。导入依赖、写代码时要注意，import javax.annotation.Resource之类的旧代码在3.x下编译不过去，要改成import jakarta.annotation.Resource。如果项目里用了很多网上抄下来的老代码，几条解决方案里最省事的就是把版本降到2.7.18，不用改代码。

6.2 微信小程序开发工具常见报错

经历过一次演示前崩溃就明白，小程序报错排查要有一个固定思路。

报错“request:fail url not in domain list”，意思是请求的域名没有配置到小程序后台的request合法域名里。开发时在本地设置里勾选“不校验合法域名”，生产环境一定要去小程序管理后台的“开发管理-开发设置-服务器域名”里把域名加进去。

报错“TypeError: Cannot read property 'xxxx' of undefined”，绝大多数情况是后端返回的数据结构和前端预期不一致。比如后端success返回的是{code:200,data:{...}}，前端写成res.data.info，但后端压根没有info字段。这种问题不要在真机里一行行alert，先在开发者工具的Network面板里看接口返回的响应体，结构对不对一眼就能看出来。

报错“app.json: tabBar.list[3].selectedIconPath: 文件不存在”，是tabBar图标路径写错了。路径是相对于app.json文件所在目录的，不要在前面加斜杠。图标文件必须是png，其他格式不会生效。

报错“getUserProfile:fail can only be invoked by user TAP gesture”，是因为获取用户信息的接口必须在用户点击事件里调用，不能页面加载的时候自动调用。改成bindtap点击获取就行。

6.3 Redis连接失败与数据缓存问题

启动后端时报Unable to connect to Redis，排查顺序是：确认Redis服务启动了没有；确认配置文件里的host、port、password写对了没有；如果Redis在远程服务器，确认安全组或防火墙放行了6379端口没有。本地开发时密码可以留空，但配置文件里要写成spring.redis.password=，不然还是会读取到null。

还有一个小技巧，用Redis Desktop Manager或者RedisInsight连上去看一下，key是否在写，验证码是否过期，一眼就能看清楚。不用盲查日志。

6.4 中文乱码与图片路径404

中文乱码分两块。一是后端返回给前端的JSON中文乱码，大概率是接口返回时没有设置UTF-8，在SpringBoot里全局设置server.servlet.encoding.force=true，强制将请求和响应都设为UTF-8。二是前端页面JS里写的中文本身是乱码，检查文件编码是不是保存成了UTF-8，Windows下记事本默认ANSI，最容易出这个问题。统一用VS Code打开，确保右下角编码显示是“UTF-8”。

图片路径404这个问题很常见，我把上传目录配成了/upload，但静态资源映射没配，结果浏览器能访问jar包内部资源，就是访问不了上传的本地图片。需要在SpringBoot里加一个资源映射配置：

@Configuration public class WebMvcConfig implements WebMvcConfigurer { @Override public void addResourceHandlers(ResourceHandlerRegistry registry) { registry.addResourceHandler("/upload/**") .addResourceHandler("file:" + uploadPath + "/"); } }

同理，如果图片是存在服务器的/opt/property/upload目录下，直接把路径配到那儿，比存jar包内部靠谱得多，因为部署更新时不会丢文件。

6.5 初始化数据与演示环境准备

答辩前最怕什么？最怕演示的时候库里没数据。我建议把项目经理、维修工、几套房子、几条报修记录、几张账单全部提前造好，用SQL脚本一键导入。报修工单最好准备三种状态的各一条：处理中一条、待确认一条、已完成一条，这样可以现场展示状态流转。再做一条访客记录，显示已经生成二维码，方便现场扫。公告也要发两三条，首页一眼就能看到内容。

如果演示时用的是线上服务器，数据库就连线上库，提前把测试数据初始化好。如果没有服务器，本地演示也别怕，开发时后端地址配http://localhost:8080，配合工具里的“不校验合法域名”一样可以正常跑。但一定要提前演练一遍，因为很多同学的电脑在教室插了网线、连了投影之后，突然发现localhost访问不了，或者被公司代理拦截，这种体验真的很难受。

7. 项目亮点提炼与答辩经验

7.1 亮点一：业务闭环完整

这套项目最值得讲的不是用了多少新技术，而是业务闭环。报修从用户提交开始，接单、派工、完工确认、评价，一条线走完；账单从管理端生成开始，用户端查看、缴费、逾期标记，一条线收口。毕业设计答辩时，老师最喜欢问“这个功能做完之后呢”，如果你能清晰地把每个模块的状态流转、后续动作讲清楚，就已经赢了一半。

7.2 亮点二：技术点能够自圆其说

你去搜索“springboot自动装配”“springboot常用注解”“redis在springboot中的使用”，这些热词恰恰说明这是面试和答辩时的高频考点。这个项目里：自动装配体现为SpringBoot只需引入starters即可运行；常用注解体现在@RestController、@Service、@Autowired、@Configuration、@Scheduled；Redis的使用体现在token存储、验证码、缓存三个场景。把这三个点吃透，整个项目的技术深度是站得住脚的。

7.3 亮点三：面向真实场景做优化

比如访客码有效期设计，我做了“一次性+限时”双重验证，门卫扫码后立即失效，同时也设了2小时过期时间；比如报修单加“待确认”状态，用户要确认后工单才算完成；再比如房屋绑定审核机制防止房号被乱绑。这些细节单独看都不起眼，但合在一起，整个项目的业务完整性明显比普通“增删改查”系统高一个档次。答辩的时候主动把这些细节讲出来，很容易给评委留下“这个学生是真的理解业务”的印象。

8. 开发顺序与时间规划建议

如果你就是这个项目的主人，正在纠结从哪开始做，我建议按下面这条线推进。

第一周，先把数据库建好，把所有表结构和初始化SQL写完。这一步非常关键，表结构没想清楚，后面写代码会反复重来。第二周，搭SpringBoot工程，把微信登录接口、拦截器、通用返回体做完，在这个阶段用Postman把登录流程测通。第三周，写报修模块和缴费模块的核心接口，做管理端的模板页面。第四周，搭小程序工程，把首页、报修页、缴费页、我的页写出来，联调前后端接口。第五周，补访客邀请、公告、审核功能，把管理端页面充实完整。第六周，部署，造数据，写测试用例，准备答辩PPT。

这条时间线适合有一定Java基础的同学，每天能投入两三个小时。如果时间非常紧张，只能优先保住核心链路：登录绑定、报修全流程、账单查询缴费、管理端审核处理。这四个流程能跑通，项目已经能立住了。访客邀请、公告、评价这些可以往后放，作为加分项去补。

还有一点建议，项目代码的命名规范、注释一定要认真写。代码整洁程度在毕业设计评分里占的比例比想象中要高。类名、方法名、变量名做到见名知意，关键逻辑加注释，自己后面写论文、做答辩PPT都会省很多力气。Git建个仓库，每完成一个模块就提交一次，提交信息写清楚是哪个模块，这样万一改坏了还能回滚，这也是一个优秀开发者的基本素养。