企业官网建设流程全解析

看到这个标题，估计不少正在选题的同学眼睛会一亮。社区住户信息管理系统，准确说应该是 SpringBoot 社区住户信息管理系统，这个题目在计算机毕业设计里属于典型的 JavaWeb 方向，热度一直很高。它不只是做一个简单的增删改查，而是要把一个小区的住户档案、房屋台账、车位信息、物业缴费、报修工单这些业务串起来，形成一个能演示、能答辩、能讲清楚业务逻辑的完整系统。

这个项目适合谁？如果你正在准备 Java 方向的毕业设计，或者刚学完 SpringBoot 想做点完整的项目练手，又或者你想把简历上的“熟悉 JavaWeb 开发”变成“做过一个能跑通的项目”，那这个题目确实值得认真做一遍。它能让你把 SpringBoot、MyBatis、MySQL 这些技术串成一条线，还能让你理解真实业务系统是怎么从需求变成代码的。这篇文章我会把整个项目从需求拆解到表结构设计、从核心代码到避坑经验完整过一遍，讲清楚每一步为什么这么做。

1. 项目定位与需求分析：先想清楚做的是什么

很多同学拿到题目就开始建表写代码，结果写到一半发现业务关系理不清，又回头改表结构。我见过太多这样的翻车现场。所以第一步，别急着敲代码，先把这个系统到底要解决什么问题想明白。

1.1 社区住户管理场景的真实痛点

你可以想象一个普通的中型社区，有十几栋楼、上千户住户。在没有数字化系统的时候，物业管家靠什么管理？Excel 表格、纸质台账、微信群。住户搬进来了登记一下，搬走了再划掉；交物业费了在本子上打个勾；报修了用纸条记一下派给师傅。听起来好像也能转，但一遇到实际问题就露馅了：查一个住户的缴费记录要翻半天、房屋转让后新旧住户信息对不上、月底统计欠费名单全靠人工核对。

这个项目要做的就是把这些散落的、靠人工维护的信息统一收拢到一个系统里。住户档案、房屋信息、车位信息、缴费账单、报修工单，全部数字化、结构化存进数据库，提供查询、统计、状态流转的能力。换句话说，这不是一个好看的空壳，而是要把物业日常运营的流程跑通。

1.2 系统用户角色与核心需求拆解

从使用者的角度来看，这个系统里实际有三类人，他们的需求完全不同：

• 系统管理员：负责系统的最高配置，比如管理物业账号、查看所有数据、配置系统参数。这类用户看的是全局，权限最大。
• 物业工作人员：日常操作的核心角色。他们要维护住户档案、登记房屋信息、录入缴费账单、受理和派发报修工单。这类用户的操作频率最高，系统的每个核心模块都围绕他们展开。
• 住户（可选角色）：登录后查看自己的房屋信息、缴费账单、提交报修申请、查看公告。这个角色属于加分项，很多毕设会做成网页版住户端或者在小程序里实现，把它纳入进来能明显提高项目的完整度。

1.3 功能模块清单：一张表说清楚

我在做类似项目时习惯先画一个功能模块清单，确认范围，避免做到后面越来越膨胀。下面这个清单可以直接抄作业，覆盖了答辩时最常被问到的模块：

一个完整的毕设项目做到这个功能量级已经足够扎实了。答辩的时候不要贪多，把上面的模块讲深讲透，比做十个没有逻辑关联的页面更有说服力。

2. 技术选型与核心原理：为什么是这套组合

确定好功能范围之后，就要开始选择技术方案。很多同学在这一步容易犯选择困难症，到处问别人该用什么框架。我把这套方案的选型逻辑和背后的原理讲清楚，你就不会再纠结了。

2.1 SpringBoot + MyBatis Plus + Vue 还是 Thymeleaf

后端框架选择 SpringBoot，理由很直接：它解决了传统 Spring 项目配置繁琐的问题。以前做 SSM（Spring + SpringMVC + MyBatis）项目，要手写一堆 XML 配置：数据源配置、事务配置、组件扫描配置、MyBatis 的 Mapper 扫描配置，每一处都是潜在的坑。SpringBoot 用自动配置和 Starter 机制把这些常见的配置全部内置了，你只需要在 application.yml 里写数据源地址、账号密码这类真正有差异的东西，剩下的框架帮你搞定。这对毕业设计来说，最大的价值是把时间从“折腾配置”释放到了“写业务代码”。

ORM 层面，MyBatis 和 MyBatis Plus 的选择也值得说一句。MyBatis 本身是一个很优秀的持久层框架，问题在于哪怕你只做单表的 CRUD，也至少要写一个 XML 文件定义 SQL、写 DAO 接口、写实现，代码量很大。而 MyBatis Plus 把单表的增删改查、分页查询、条件构造器都做了内置实现，连 SQL 都不用手写，一个 BaseMapper 接口直接继承就全有了。这对快速开发毕设项目是非常友好的，同时它并不妨碍你在复杂查询中手写 SQL。换句话说，MP 帮你省掉的是重复劳动，复杂业务你依然可以完全掌控。

前端层有两个选择：一个是 Thymeleaf + Bootstrap，服务端渲染，简单直接；另一个是前后端分离，用 Vue 3 + Element Plus + Axios。我的建议是：如果你时间紧张、想要快速出完整效果，用 Thymeleaf 就够了，部署也方便，打成一个 jar 包就能跑；如果你想把项目做得更有层次感、或者你已经在学 Vue，那就做前后端分离，接口全部走 JSON，前端独立起一个工程。两种方案在答辩时都有对应的讲法，关键是你自己能讲清楚数据是怎么流转的。

2.2 数据库表结构设计：这些表缺一张都不行

表结构是这个项目真正的地基。很多同学在建表时随手敲了几张表就开写代码，结果后面被迫不断改表，血泪教训。我按业务域把核心表列出来，你直接对着做就行：

• 用户表（sys_user）：存储系统登录账号。关键字段包括用户名、密码密文、真实姓名、联系电话、角色标识（管理员/物业/住户）、账号状态。
• 小区信息表（t_community）：存小区名称、地址、建成年份等基础信息。如果只做一个小区，这张表可以简化为一条固定数据，但保留它可以体现你数据建模的思路。
• 楼栋表（t_building）：关联小区，存楼栋编号、楼层数、单元数。
• 房屋表（t_house）：关联楼栋，存房号、建筑面积、户型、当前状态（自住/出租/空置）。
• 住户表（t_resident）：核心表。存住户姓名、身份证号（脱敏存储）、手机号、户籍信息、入住时间、迁出时间、状态。一个房屋可以对应多个住户（家人），一个住户理论上也可以拥有多套房产。
• 住户房屋关联表（t_resident_house）：解决多对多关系，存住户 ID 和房屋 ID 的绑定关系、入住时间、是否当前有效。
• 车位表（t_parking）：存车位编号、位置、类型（产权/租赁）、绑定状态。
• 车辆表（t_vehicle）：存车牌号、品牌、颜色等，与住户或房屋关联。
• 缴费账单表（t_bill）：核心业务表。存账单编号、房屋 ID、缴费项目（物业费/停车费/水费）、计费周期、金额、状态（待支付/已支付/已退款）、支付时间、支付方式。
• 报修工单表（t_repair）：存报修人、联系电话、房屋信息、报修类型、故障描述、附件图片路径、受理时间、处理人、处理结果、状态。
• 公告表（t_notice）：存公告标题、正文、发布人、发布时间、置顶标识。

这个表清单基本覆盖了前面功能模块的所有核心数据。有一个设计细节我特别想提一下：住户和房屋的关系一定要做成单独的关联表，而不是在房屋表里直接存一个住户 ID。原因是现实中同一套房可能有夫妻、老人、孩子等多名住户，如果做成单字段引用，整个模型就崩了。这也是答辩时老师最喜欢深挖的一个考察点，做成关联表这一层你的数据建模能力就体现出来了。

2.3 关键字段类型选择：细节决定成败

建表时字段类型不要随手选，有经验的开发者在这些细节上很较真。举几个最典型的例子：

• 手机号千万别用 int 或 bigint 存。手机号有 11 位，int 最大 21 亿，直接溢出；用 bigint 虽然存得下，但后续如果要处理归属地、号码段可能会麻烦。最省心的方案是 varchar(11)。
• 身份证号用 varchar(18) 存，不要用数值类型。身份证是字符串，不是数字，还可能存在末尾 X。
• 金额字段用 decimal(10,2)，不要用 float 和 double。二进制浮点数存在精度误差，算物业费这种反复加减乘除的场景容易出现 0.01 的差异。decimal 是精确小数，代价是计算稍慢，但账目场景精度第一。
• 状态字段推荐用 tinyint 存数字，不要直接存中文。比如账单状态 0 待支付、1 已支付、2 已退款，业务上的含义由代码来约定。这样数据库存储更紧凑，也便于以后扩展状态机。
• 创建时间和更新时间这类审计字段，统一用 datetime 类型。MyBatis Plus 支持自动填充，一次配置以后所有表都能自动维护，别手动在每个插入语句里写时间。

这些看起来都是小问题，但一个表结构是否专业，从字段类型就能看出来。答辩时老师很可能翻开你的建表 SQL 检查，这一关过了整体印象分会高不少。

3. 核心功能模块设计与实现要点

技术选型和建表工作完成后，就进入核心业务代码阶段。这一章我挑几个最关键的功能模块，讲讲它们的设计思路和实现细节，这些都是你在开发时最容易卡住或者做得不够深的地方。

3.1 住户档案管理：最基础的 CRUD 也要注意条件组合查询

住户档案是整个系统的数据基础，也是功能最直观的模块。常规的增删改查谁都会写，真正拉开差距的地方是列表查询页面的设计。

实际业务中，物业人员找一个住户时往往是带着条件的：只知道姓氏、只知道住在哪栋楼、只想查当前在住的住户。所以这个查询接口必须是“条件组合 + 分页”，支持按姓名模糊查询、按楼栋筛选、按入住状态筛选，还可以加一个“只显示有效住户”的开关（用来排除迁出记录）。

用 MyBatis Plus 的 LambdaQueryWrapper 实现条件组合查询非常顺手：

public Page<ResidentVO> getResidentPage(ResidentQuery query) { LambdaQueryWrapper<Resident> wrapper = new LambdaQueryWrapper<>(); // 姓名模糊查询 if (StrUtil.isNotBlank(query.getName())) { wrapper.like(Resident::getName, query.getName()); } // 手机号精确匹配 if (StrUtil.isNotBlank(query.getPhone())) { wrapper.eq(Resident::getPhone, query.getPhone()); } // 按楼栋过滤：先查出房屋ID集合，再关联查询住户 if (query.getBuildingId() != null) { List<Long> houseIds = houseService.getIdsByBuildingId(query.getBuildingId()); wrapper.in(Resident::getHouseId, houseIds); } // 只看在住状态 if (Boolean.TRUE.equals(query.getOnlyActive())) { wrapper.eq(Resident::getStatus, 1); } wrapper.orderByDesc(Resident::getCreateTime); Page<Resident> page = residentMapper.selectPage( new Page<>(query.getPageNum(), query.getPageSize()), wrapper); return convertToVO(page); }

这里的状态枚举、条件判断、排序都要做到清晰。很多新手会忽略的空值问题，在上面这个写法里都做了处理。页面上的搜索框、状态下拉、楼栋下拉全部映射到这些条件里，用户不用背任何记忆就能找到想要的记录。

3.2 房屋与住户的绑定关系：用中间表解决多对多

前面提过住户和房屋是多对多的关系，这个设计真正落到代码上的时候，难点会出现在“当前房屋”和“历史房屋”的区分上。

我的做法是在关联表里加一个 current_flag 字段，标识这条关联关系当前是否有效。当住户迁入一套新房时，把旧的 current_flag 置为 0，新的置为 1。这样既可以方便地查“某人现在的住址”，也可以保留完整的“某人住过哪些房屋”的历史轨迹。

@Transactional(rollbackFor = Exception.class) public void bindResidentToHouse(Long residentId, Long houseId) { // 1. 将旧绑定关系标记为失效 LambdaUpdateWrapper<ResidentHouse> updateWrapper = new LambdaUpdateWrapper<>(); updateWrapper.eq(ResidentHouse::getResidentId, residentId) .eq(ResidentHouse::getCurrentFlag, 1) .set(ResidentHouse::getCurrentFlag, 0) .set(ResidentHouse::getEndTime, LocalDateTime.now()); residentHouseMapper.update(null, updateWrapper); // 2. 创建新的绑定关系 ResidentHouse relation = new ResidentHouse(); relation.setResidentId(residentId); relation.setHouseId(houseId); relation.setCurrentFlag(1); relation.setStartTime(LocalDateTime.now()); residentHouseMapper.insert(relation); }

注意我在这个绑定操作上加了 @Transactional，因为这里包含了“修改旧数据”和“新增新数据”两步，任何一步失败都必须全部回滚，否则就会出现一个住户同时有两条有效房屋关系的脏数据。

3.3 物业缴费模块：账单状态机的流转设计

缴费模块是这个项目最有业务深度的部分。一个完整的账单生命周期至少包含这些状态：

• 待支付：账单生成后未进入支付流程。物业可以手动创建账单，也可以按周期批量生成整栋楼的物业费账单。
• 已支付：住户完成支付或物业线下收款后录入系统。这时要记录支付时间、支付方式、操作人。
• 已退款：如果住户退房或者多缴错缴，需要走退款流程，账单状态变为已退款，这笔金额不能再被统计为收入。

状态之间不是随意跳转的，比如“已支付”的账单不能直接删除或者退回“待支付”，只能走退款流程。这个约束在代码层面是这样保证的：

public void payBill(Long billId, PayMethod payMethod) { Bill bill = billMapper.selectById(billId); // 校验当前状态：只有待支付才能支付 if (bill == null || bill.getStatus() != BillStatus.WAITING_PAY) { throw new BizException("当前账单状态不可支付"); } // 更新账单状态和支付信息 bill.setStatus(BillStatus.PAID); bill.setPayTime(LocalDateTime.now()); bill.setPayMethod(payMethod); bill.setOperator(SecurityUtil.getCurrentUserId()); billMapper.updateById(bill); }

状态没有封装成一个独立的动作方法，而是散落在不同的 Service 方法里，这样每个状态入口的后置检查、日志、审计操作都会集中在对应的方法里，逻辑更好管。这种“状态机+状态入口校验”的设计思路，不仅适用于账单，也适用于报修工单。

另外，缴费模块往往还会有一个“欠费统计”的功能需求。这里需要用 SQL 聚合统计，按房屋分组算出每个房屋当前未支付账单的总金额：

public List<ArrearsVO> getHouseArrears() { QueryWrapper<Bill> wrapper = new QueryWrapper<>(); wrapper.eq("status", 0) .select("house_id", "SUM(amount) as total_amount", "COUNT(*) as bill_count") .groupBy("house_id"); return billMapper.selectMaps(wrapper).stream().map(map -> { ArrearsVO vo = new ArrearsVO(); vo.setHouseId(Long.valueOf(map.get("house_id").toString())); vo.setTotalAmount(new BigDecimal(map.get("total_amount").toString())); vo.setBillCount(Integer.valueOf(map.get("bill_count").toString())); return vo; }).toList(); }

这个统计在答辩时是一个很好的展示点，因为它展示了你对聚合查询和结果映射的掌握。

3.4 报修工单模块：用状态机管好一条任务链

报修工单是社区系统里少有的“多人协同”业务，涉及报修人、客服受理人员、维修技师三方角色。它的核心是工单状态的流转，我给这个模块设计的状态链路一般是：

提交报修 -> 客服受理 -> 派单给维修人员 -> 维修完成 -> 住户确认 -> 关闭工单

每一环都对应一次数据库状态更新，并且每一环都要记录操作人和操作时间。我的设计中专门在旁边加了一张“操作日志表”，结构是工单 ID、操作人、操作内容、操作时间。这样做的价值是任何时候你点开工单详情，都能清清楚楚看到这条工单从哪来到哪去、谁在什么时候做了什么。别小看这个设计，真实业务系统里这叫“流程审计”，放毕业设计里就是明显的加分项。

有一个很典型的易错点：工单状态更新时，必须做前置校验。比如“待受理”的工单不能直接变成“已完成”，否则整个流程就乱了。我在代码里把每一个状态变迁都写成独立的方法，并且在状态迁移的最前面做严格的状态比对，不满足条件直接抛出业务异常。

3.5 登录鉴权与权限控制：不是简单地存个 session

登录模块是另一个容易被轻视的部分。很多毕设的做法是登录成功把用户 ID 放进 session 就完事，但稍微有一点规模的项目都不会这么做。我的建议是引入 JWT（JSON Web Token）来做无状态登录，把用户 ID、角色标识签名后返回给前端，前端在请求头里带回来，后端用一个拦截器统一解析、统一校验。

权限控制建议走最精简的路子：自定义一个 @RequireRole 注解放在 Controller 方法上，拦截器里读取当前用户的角色做判断。这样的实现代码量不大，但架构逻辑清晰，答辩时一讲就能说明白。

后端拦截器里的核心逻辑：

public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) { // 放行登录接口和静态资源 if (request.getRequestURI().contains("/auth/login")) { return true; } // 从请求头获取 token String token = request.getHeader("Authorization"); if (StrUtil.isBlank(token)) { // 未登录，返回统一的 401 响应 returnJson(response, Result.fail("未登录或登录已过期")); return false; } try { // 解析 token，把用户信息放进当前请求上下文中 LoginUser loginUser = JwtUtil.parseToken(token); request.setAttribute("loginUser", loginUser); return true; } catch (JwtException e) { returnJson(response, Result.fail("登录凭证无效")); return false; } }

无论后端用不用 SpringSecurity，核心思想都在这里：每个受保护接口在进入 Controller 之前，先确认请求者是谁、有没有权限。我对所有实操项目的建议都是：一开始就把这个拦截器写好，后续写任何接口都不用再操心鉴权的问题。

4. 实操过程：从零搭建一个可运行的 SpringBoot 社区系统

讲完了设计和核心模块，这一章我把整个项目的实际操作过程走一遍。从环境准备到工程初始化，从关键代码到联调演示，每一步都有直接可用的配置和代码，照着做就能跑起来。

4.1 环境准备与工程初始化

我在做这类项目时用的标准环境是：

初始化工程不用去网页上手动生成，idea 里新建 Spring Initializr 工程，直接勾选 Web、MySQL Driver、MyBatis Framework，然后在 pom.xml 里手动加上 MyBatis Plus 和 Lombok 依赖就行。MyBatis Plus 有专门的 starter，引入后需要自己配置分页插件，这个下一步会写到。

核心的 pom 依赖大致如下：

<dependency> <groupId>com.baomidou</groupId> <artifactId>mybatis-plus-boot-starter</artifactId> <version>3.5.3.1</version> </dependency> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <optional>true</optional> </dependency> <dependency> <groupId>com.auth0</groupId> <artifactId>java-jwt</artifactId> <version>4.4.0</version> </dependency>

4.2 application.yml 配置与 MyBatis Plus 分页插件

配置文件的写法非常关键，很多初学者在运行报错后才发现问题出在配置。我给一份我常用的配置参考：

server: port: 8080 spring: datasource: driver-class-name: com.mysql.cj.jdbc.Driver url: jdbc:mysql://localhost:3306/community_db?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai username: root password: your_password jackson: date-format: yyyy-MM-dd HH:mm:ss time-zone: GMT+8 mybatis-plus: configuration: map-underscore-to-camel-case: true log-impl: org.apache.ibatis.logging.stdout.StdOutImpl global-config: db-config: logic-delete-field: deleted logic-delete-value: 1 logic-not-delete-value: 0

几个容易踩的坑我直接给你标出来：

• MySQL 8 驱动必须写 com.mysql.cj.jdbc.Driver，和 MySQL 5 的写法不一样。如果 driver 路径写错，启动会直接报 ClassNotFound 或自动探测失败。
• url 里的 serverTimezone=Asia/Shanghai 一定要写。不写的话高版本的连接器默认 UTC 时区，你在数据库里看到的时间和 Java 里看到的时间会差 8 小时，排查起来非常痛苦。
• jackson 的 date-format 加上的原因同理，不然接口返回的日期会是时间戳格式，前端解析很别扭。

MyBatis Plus 的分页插件需要在配置类里显式声明，不声明的话分页不生效，这是新手非常容易踩的坑：

@Configuration public class MybatisPlusConfig { @Bean public MybatisPlusInterceptor mybatisPlusInterceptor() { MybatisPlusInterceptor interceptor = new MybatisPlusInterceptor(); interceptor.addInnerInterceptor(new PaginationInnerInterceptor(DbType.MYSQL)); return interceptor; } }

4.3 核心代码：统一返回结构与住户分页查询

写接口前，先定一个统一返回结果的类，避免每个接口返回格式都不一致。前端拿到这个结构后，只需要在拦截器里统一处理 data、message、code 即可，维护成本会低很多。

@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.code = 200; result.message = "success"; result.data = data; return result; } public static <T> Result<T> success() { return success(null); } public static <T> Result<T> fail(String message) { Result<T> result = new Result<>(); result.code = 500; result.message = message; return result; } }

住户分页查询的 Service 实现在上一章已经给过一段关键代码，这里从完整链路再走一遍。Controller 接收查询条件，Service 组装 MyBatis Plus 的 Wrapper，Mapper 通过继承 BaseMapper 直接执行分页查询，最终结果统一包装成 Result 结构返回给前端。这一步打通后，后面的房屋、账单、工单模块其实就是同样的套路复制扩展，你对这个项目的掌控力会明显提升。

4.4 前端页面与接口联调

如果你选择前后端分离方案，前端用 Vue3 + Vite + Element Plus 搭建起来也很顺畅。接口调用的封装核心就一个：在 axios 实例里配置好 baseURL 和请求拦截器，请求拦截器负责把 token 塞进请求头，响应拦截器统一处理 code 不为 200 的情况。

const request = axios.create({ baseURL: 'http://localhost:8080/api', timeout: 10000 }) request.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = token } return config }) request.interceptors.response.use(response => { const res = response.data if (res.code !== 200) { ElMessage.error(res.message) return Promise.reject(new Error(res.message)) } return res.data }, error => { ElMessage.error('网络异常或服务不可用') return Promise.reject(error) })

页面上的表格展示用 Element Plus 的 el-table 配合 el-pagination 分页组件，搜索区放输入框和下拉框。开发阶段可以使用 Vite 的代理把 /api 前缀转发到后端 8080 端口，避免跨域问题。

4.5 演示数据准备与答辩话术

系统跑通之后，别急着把这当成结束了。毕业设计更关键的一步是准备演示数据。一个空空如也的系统在演示时毫无说服力，你要提前造一批看起来真实的数据：至少 3 个小区或 3 个楼栋、20 个以上的住户、每一户配好房屋和车位、生成两个月的物业费账单、其中一部分设置为已支付另一部分是欠费状态、还有几条处于不同状态的报修工单。

这些数据可以先手工 SQL 插入，也可以做一个 DataInitializer 组件在项目启动时自动插入，后者的好处是任何时候数据库被清空重启项目都能自动恢复演示数据。演示的时候，从这些数据里讲出一个连续的运营故事：“某住户 3 月搬入，系统给他建档并绑定房屋，他家的物业费账单一键生成，住户线上报修后物业受理派单、维修完成、流程结束。”一个有业务逻辑串联的演示，比零散地点几个按钮要加分得多。

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

这个项目我前后看不少人做过，也亲手帮人排查过大量的报错。我把出现频率最高的问题汇总成一份速查表，每一个都附上原因分析和解决方案，你在开发时遇到的八成问题都能在这里找到答案。

5.1 数据库表设计阶段的六个高频问题

5.2 接口开发阶段最容易踩的四个坑

第一个是分页不生效。现象是传入 pageNum 和 pageSize 后数据还是全部返回。原因基本只有一个：忘了配置 MyBatis Plus 的 PaginationInnerInterceptor 插件。这个不显式配置，MyBatis Plus 的分页功能是失效的，只用内存里的 count 做一个假分页。解决方案就是像文章里那样加一个配置类，声明好拦截器。

第二个是 Long 型 ID 传到前端后精度丢失。这是前后端分离模式下很经典的问题。Java 的 Long 可以精确表示 19 位数字，但 JS 的 Number 只能安全表示到 2 的 53 次方，超过之后末位数字会变成 0。如果你的表主键是雪花 ID 生成的 19 位数字，从接口返回去，前端拿到的主键就和数据库里不一样了，点操作时就会报“数据不存在”。解决方案有两个方向：主键改用数据库自增 ID，或者在后端把 Long 字段序列化为 String。我做了很多系统的经验是，用 String 序列化更稳妥，不管换不换主键策略都不会出问题。

第三个是日期格式化问题。接口返回的日期显示成一大串数字。原因是 Jackson 默认把 Date 序列化成时间戳，而不是字符串。解决办法是在 application.yml 里配置 jackson.date-format 和 time-zone，前面已经给过配置了，照着写即可。

第四个是跨域问题。前后端分离开发时，前端跑在 5173 端口，后端跑在 8080 端口，浏览器默认会拦截跨域请求。最简单的开发期解法是配置 Vite 的 proxy 代理，让前端请求 /api 时自动转发到后端。如果后端也需要支持跨域，可以加一个全局 CORS 配置类，但生产上放太宽的跨域会有安全隐患。

5.3 答辩前后必看的自查清单

临近答辩，把系统完整跑一遍，按这个清单逐项自查，能救你于水火：

• 管理员、物业、住户三种角色是否能正常切换演示？每种角色能看到什么、不能看到什么，要讲得出逻辑。
• 演示数据的完整度是否足够？有没有每个模块都准备了 2-3 条不同状态的数据？
• 如果答辩现场没有网络，前端资源是否已经打包进 jar 包？能否只启动一个 jar 在离线环境演示？
• 数据库脚本是否已经导出为 .sql 文件？是否在全新环境验证过导入后系统能正常启动？
• 项目里有没有残留的个人信息或无关代码？比如调试的 system.out、测试接口、写死的密钥和密码。
• 能否清楚回答“表之间如何关联”“某条数据是怎么从页面走到数据库的”这一类问题？建议自己对着演示流程预先过两遍问答。

最后再分享一点我的体会

做完这个 SpringBoot 社区住户信息管理系统，我最大的感受是：你真正学到的不是怎么写 CRUD 接口，而是“一个稍微像样的业务系统，是怎么从需求变成模型的”。你在建模阶段对住户和房屋的多对多关系的思考、对账单状态机的设计、对工单流转的审计需求的理解，这些观念上的收获，在后续学分布式、学微服务、接触真实企业项目时依然会反复用到，因为底层的建模思维是一致的。

最后送大家一个小技巧：在项目里加一个“操作日志模块”，记录每个用户的关键操作。这个功能在答辩时非常加分，因为很多人的系统根本没有这个意识，而它会直接体现出你对系统安全性和可追溯性的理解。哪怕日志只是存一张简单的表，也不要省掉它。

祝你的项目顺利跑通，答辩时有一个精彩的表现。