企业官网建设流程全解析

简介：基于Spring Boot的智慧社区管理系统毕业设计项目，面向计算机相关专业毕业生与Java开发者，是一套覆盖社区全场景的前后端分离方案。系统内置用户注册与权限分配、商品上架与库存管理、商品分类管理、动物档案与疫苗接种记录、动物分类管理、车位分配与预约、便民服务发布与预约、服务类型管理、物业费及停车费在线缴纳、房屋类型管理、房屋租售状态维护等十余个业务模块，基本覆盖社区运营的常见环节。资源包共739个文件，包含202个Java后端源文件、141个Vue前端组件、161个SVG图标，以及JS交互脚本、XML配置文件、CSS样式、SQL数据库脚本和Windows部署运行脚本，压缩后约23MB，目录结构清晰，便于按需检索与二次开发。目前已有65人学习下载，适合作为毕业设计选题参考或Spring Boot项目实战模板。配合部署教程可快速搭建环境，理解前后端交互流程，同时借助内含的数据表设计与权限分配机制，能显著缩短项目开发周期。

1. 智慧社区管理系统是什么：一个 Spring Boot 毕设为什么值得认真做完

每年这个时间点，都能在论坛和群里看到同一类求助：代码从学长那拷来了，依赖也装了，结果一启动不是红一片就是白屏，离答辩只剩三天。这个标题背后，其实是国内高校软件工程、信息管理、物联网工程专业出现频率最高的毕业设计题材之一——智慧社区管理系统。它不炫技，但五脏俱全：业主管理、房屋绑定、物业报修、缴费账单、访客登记、公告发布，一套标准的中台业务闭环。选它做毕设，意味着你用一套 Spring Boot 单体应用，就能把「数据库设计、权限控制、流程状态机、定时任务、部署上线」这些面试官最爱问的点全走一遍。这篇笔记就按我自己的做法，从选型、建表、写核心代码，到打成 jar 丢上服务器，把整个链路讲透，包括那些本地永远测不出来的坑。

2. 技术选型与项目结构：为什么 Spring Boot 3 + MyBatis Plus 是这套系统的稳妥组合

2.1 选型复盘：单体应用为什么比微服务更适合毕设和中小型项目

很多同学一上来就问要不要拆微服务、上 Redis、搞消息队列。我的回答很直接：这套系统最复杂的场景不过是「业主提交报修 → 物业派单 → 维修工完工 → 业主评价」，数据量撑死几千张表，业务耦合度没那么高。微服务那套注册中心、配置中心、链路追踪，对毕业设计是负资产——你花两周搭骨架，业务代码一行没写。

Spring Boot 单体应用恰恰是这个规模的最佳解。它自带内嵌 Tomcat，不用单独装容器；spring-boot-starter-web一个依赖就把 MVC 和 JSON 序列化全带上了；配合 MyBatis Plus，连通用 mapper 的 SQL 都不用手写。这套组合在中小型管理系统里的普及度极高，面试时聊到它，对方默认你具备实际项目经验，而不是停留在 Servlet + JDBC 的课程作业阶段。

选型时唯一要劝你克制的是版本洁癖。别一上来就追最新版 Spring Boot，尤其别用 3.x 的里程碑版本。原因后面避坑章会详细展开，这里先记住一个原则：选「当前多数教程和插件都适配的稳定版本」，比选「最新版本」能少踩一半的坑。

2.2 标准分层：controller/service/mapper 三层与前后端分离的取舍

Spring Boot 项目的结构看似自由，但从业者默认有一套「看得懂」的分层约定。常见做法是controller层只做参数接收和结果包装，service层放业务规则，mapper层管数据库交互，entity层对应表结构，dto层处理前端传参和返回视图模型。这套结构的好处是：报修工单从提交到流转，每一步改动都能定位到具体某个方法，而不是在一个三百行的 controller 里翻来翻去。

前后端是否分离，取决于你手里有没有现成的前端功底。如果不熟 Vue 或 React，我建议直接用 Thymeleaf 模板引擎，把页面放在resources/templates下，controller 直接返回视图名。这样能省掉跨域配置、token 存储、接口联调这些环节，把精力集中在业务逻辑上。如果你已经会 Vue，那就走前后端分离，后端只出 JSON 接口，前端单独部署或用后面部署章讲的方式打包进 Spring Boot。两条路都能过答辩，但别中途换，换一次等于重写一遍接口层。

2.3 核心数据表设计：业主表、房屋表、工单表、缴费单表的关系

数据表设计是这套系统的地基，也是答辩时老师最爱追问的地方。我习惯先画四张核心表，再围绕它们扩展：业主表owner、房屋表house、报修工单表repair_order、缴费单表payment_bill。业主持有房屋是一对多还是多对多，取决于一个小区是否允许一个业主名下挂多套房——现实中很常见，所以我会用关联表owner_house而不是在业主表里塞一个house_id字段。

后缀表和字典表也不要省。房屋类型、工单状态、缴费渠道这些字段，如果直接写成硬编码的字符串，后期改一个显示名就要动代码重新打包。用一张dict_item字典表统一存，前端通过接口拉字典渲染下拉框，改文案只需改数据库。下面这段建表 SQL 是我常用的骨架，去掉了冗余字段，保留了最关键的关系和状态字段：

CREATE TABLE `owner` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '业主ID', `real_name` VARCHAR(32) NOT NULL COMMENT '姓名', `phone` VARCHAR(20) DEFAULT NULL COMMENT '手机号', `id_card` VARCHAR(18) DEFAULT NULL COMMENT '身份证号', `status` TINYINT NOT NULL DEFAULT 1 COMMENT '1正常 0冻结', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='业主表'; CREATE TABLE `house` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '房屋ID', `building` VARCHAR(16) NOT NULL COMMENT '楼栋号', `unit` VARCHAR(16) NOT NULL COMMENT '单元号', `room` VARCHAR(16) NOT NULL COMMENT '房号', `area` DECIMAL(8,2) DEFAULT NULL COMMENT '面积(㎡)', UNIQUE KEY `uk_building_unit_room` (`building`, `unit`, `room`), PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='房屋表'; CREATE TABLE `owner_house` ( `id` BIGINT NOT NULL AUTO_INCREMENT, `owner_id` BIGINT NOT NULL COMMENT '业主ID', `house_id` BIGINT NOT NULL COMMENT '房屋ID', `is_primary` TINYINT NOT NULL DEFAULT 1 COMMENT '是否常用房屋', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='业主房屋关联表'; CREATE TABLE `repair_order` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '工单ID', `order_no` VARCHAR(32) NOT NULL COMMENT '工单号', `owner_id` BIGINT NOT NULL COMMENT '报修业主ID', `house_id` BIGINT NOT NULL COMMENT '房屋ID', `content` VARCHAR(500) NOT NULL COMMENT '报修内容', `status` TINYINT NOT NULL DEFAULT 1 COMMENT '1待派单 2处理中 3待评价 4已完成 5已取消', `assignee` VARCHAR(32) DEFAULT NULL COMMENT '维修工姓名', `create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `update_time` DATETIME DEFAULT NULL ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='报修工单表';

这段 SQL 里的uk_building_unit_room唯一索引很关键，它能挡住重复录入同一套房的数据问题。owner_house表用is_primary标记常用房屋，查询时优先展示这套房。工单表的状态字段我直接用 TINYINT，对应关系写进代码常量类里，比用字符串更省空间、查询更快。update_time的ON UPDATE CURRENT_TIMESTAMP是 MySQL 5.6 以后才支持的语法，如果你用的版本老，得去掉这个特性，改在 service 层手动 set。

3. 核心模块代码落地：登录鉴权、报修工单与缴费单的三个可抄作业实现

3.1 基于 JWT 的登录鉴权：拦截器 + 注解的最小实现

智慧社区系统里业主和物业管理员角色不同，权限天然分叉。用 Shiro 或 Spring Security 功能全但配置重，对毕设来说有点杀鸡用牛刀。我更推荐 JWT，无状态、前后端都能解析，配合一个拦截器加一个注解，二十行代码搞定权限控制。

先定义一个注解@RequireRole，挂在需要鉴权的 controller 方法上；再写一个AuthInterceptor，在preHandle里从请求头取Authorization: Bearer <token>，解析出用户 ID 和角色后放进ThreadLocal。代码里只留最核心的部分，数据库查询和 JWT 工具类省略，避免大段样板代码干扰阅读：

// AuthInterceptor.java @Component public class AuthInterceptor implements HandlerInterceptor { @Override public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 只拦截加了 @RequireRole 注解的方法 if (!(handler instanceof HandlerMethod handlerMethod)) { return true; } RequireRole require = handlerMethod.getMethodAnnotation(RequireRole.class); if (require == null) { return true; } String token = request.getHeader("Authorization"); if (token == null || !token.startsWith("Bearer ")) { response.setStatus(HttpServletResponse.SC_UNAUTHORIZED); return false; } // 解析 JWT，失败会抛出异常，由全局异常处理器统一返回 401 Claims claims = JwtUtil.parseToken(token.replace("Bearer ", "")); // 校验角色是否匹配 String role = claims.get("role", String.class); if (!require.value().equals(role)) { response.setStatus(HttpServletResponse.SC_FORBIDDEN); return false; } // 用户上下文存入 ThreadLocal，后续 service 层可以直接取当前用户 ID UserContext.set(claims); return true; } @Override public void afterCompletion(HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex) { // 请求结束后必须清理，否则线程池复用会导致用户身份串号 UserContext.clear(); } }

这段代码有三个容易忽略的细节。第一，HandlerMethod判断不能省，否则放行静态资源时会被误拦截。第二，UserContext用ThreadLocal存储，但请求结束必须调用clear()，否则 Tomcat 的线程池复用会让下一个请求读到上一个用户的身份，这是典型的线上用户串号事故。第三，JWT 密钥不能写在代码里，放application.yml通过@Value注入，服务器和本地用不同的密钥，防止本地调试时生成的 token 在服务器上直接复用。

3.2 报修工单状态机：从提交到完工的四态流转与防重复提交

报修工单的核心不是 CRUD，而是状态流转。我把状态定义为1待派单 → 2处理中 → 3待评价 → 4已完成，外加一个5已取消作为终态。每个状态之间的跳转有对应的业务动作要求比较严格，例如「待派单」状态下只有物业管理员能执行派单操作，业主动作里没有这项。这种限制如果靠 if-else 写，后期加一个状态就要改多处，我习惯建一个状态机：

// RepairOrderStateMachine.java public class RepairOrderStateMachine { private static final Map<Integer, List<Integer>> TRANSITIONS = new HashMap<>(); static { // key 为当前状态，value 为允许跳转的目标状态列表 TRANSITIONS.put(1, Arrays.asList(2, 5)); // 待派单 -> 处理中 / 取消 TRANSITIONS.put(2, Arrays.asList(3, 5)); // 处理中 -> 待评价 / 取消 TRANSITIONS.put(3, Arrays.asList(4, 5)); // 待评价 -> 已完成 / 取消 TRANSITIONS.put(4, Collections.emptyList()); // 已完成，终态 TRANSITIONS.put(5, Collections.emptyList()); // 已取消，终态 } public static boolean canTransit(int from, int to) { List<Integer> allowed = TRANSITIONS.get(from); return allowed != null && allowed.contains(to); } }

状态机的价值在改动时显现：需求说「待评价」状态下业主要能先撤销，你只需要在TRANSITIONS的 3 那行加上 2，不用动任何业务代码。调用方在 service 里先canTransit再执行更新，无效跳转直接抛异常。相比在工作流引擎里画 BPMN，这种硬编码方式更轻、更直观，也足够应付答辩时老师对状态流水的追问。

3.3 缴费单生成：按月批次逻辑与未缴状态的定时扫描

缴费单的常见误区是等业主点「缴费」时才生成账单。真实物业管理里账单按月批次提前生成，业主登录后看到的是「待缴」列表。我设计了一张payment_bill表，生成逻辑放在一个带@Scheduled的方法里：

// PaymentBatchTask.java @Component public class PaymentBatchTask { @Autowired private PaymentBillMapper paymentBillMapper; // 每月 1 日凌晨 2 点生成当月上月账单 @Scheduled(cron = "0 0 2 1 * ?") @Transactional(rollbackFor = Exception.class) public void generateMonthlyBill() { // 1. 查询所有状态为正常入住的房屋 // 2. 按房屋关联的业主生成账单 // 3. 账单金额 = 物业费单价 * 房屋面积 + 固定公摊费 List<House> houses = houseMapper.selectActiveHouses(); for (House house : houses) { PaymentBill bill = new PaymentBill(); bill.setHouseId(house.getId()); bill.setPeriod(YearMonth.now().minusMonths(1).toString()); // 账期 bill.setAmount(house.getArea().multiply(new BigDecimal("2.5")) .add(new BigDecimal("15"))); bill.setStatus(0); // 0 未缴 1 已缴 2 逾期 bill.setDeadline(LocalDate.now().plusDays(15)); // 15 天宽限期 paymentBillMapper.insert(bill); } } // 每天凌晨扫描，把超过宽限期仍未缴的账单标记为逾期 @Scheduled(cron = "0 0 3 * * ?") public void markOverdue() { paymentBillMapper.markOverdue(LocalDate.now()); } }

生成批次有个硬性前提：同一房屋、同一账期不能重复生成。否则定时任务在凌晨因网络抖动触发两次，业主就会看到两条相同的账单。这个唯一约束我在建表时用UNIQUE KEY uk_house_period (house_id, period)兜底。另外物业费单价 2.5 元/㎡ 我是直接写死在代码里的，实际项目中应该从配置表读取，否则物业调价后改代码重新上线，业务方会骂人。定时任务上线后记得看一次触发日志，cron表达式里的 6 个字段用空格分隔，秒、分、时、日、月、周，写错一位就是任务不执行或疯狂重复执行。

4. 部署到服务器：从 Maven 打包到 jar 后台运行的最小命令集

4.1 本地打包：跳过测试用 dev 配置打包可执行 jar

代码写完之后，先把本地跑通，再考虑上服务器。打包前检查两件事：pom.xml里有没有引入spring-boot-maven-plugin，以及application.yml里数据库连接是否使用了环境变量。常见做法是维护application-dev.yml和application-prod.yml两份配置，打包时通过--spring.profiles.active指定跑哪套环境，避免把本地密码带进生产包。

打包命令本身很简单，但有几个参数值得解释：

# 跳过单元测试，用 prod 配置打可执行 jar mvn clean package -DskipTests -Pprod # 如果 Maven 下载依赖慢，可以加国内镜像加速（配置在 settings.xml 里） # mvn clean package -DskipTests -Pprod -s /path/to/custom-settings.xml # 查看打出的 jar 包位置 ls -lh target/*.jar

-DskipTests和-Dmaven.test.skip=true有区别：前者会编译测试代码但不执行，后者连测试代码都不编译，打包速度更快。用-Pprod激活 Maven Profile 时，对应的application-prod.yml会被自动加载，但前提是pom.xml里配置了<profiles>，否则这个参数不起作用，服务启动后还是加载默认配置。打包成功后，jar 通常在target/目录下，几百 MB 到几十 MB 不等，因为 Spring Boot 默认把所有依赖打成一个 fat jar。

4.2 服务器端：jdk 版本检查、jar 后台运行与日志查看

服务器上的 Java 环境是第一个翻车点。本机跑得好好的 jar，上传到服务器一执行java -jar xxx.jar就报UnsupportedClassVersionError，十有八九是服务器 JDK 版本低于编译版本。先检查再运行：

# 检查服务器 JDK 版本，确认与本机一致或更高 java -version # 先前台跑一次，确认启动过程没有报错（Ctrl+C 停掉） java -jar app.jar --spring.profiles.active=prod # 确认无误后用 nohup 后台启动，并记录 PID nohup java -jar app.jar --spring.profiles.active=prod > app.log 2>&1 & # 查看进程是否存活 ps -ef | grep app.jar # 实时看日志 tail -f app.log

前台运行的好处是启动报错能直接看到堆栈，但对服务器来说，你断开 SSH 会话进程就没了。nohup的作用是让进程忽略挂断信号，>把标准输出重定向到app.log，2>&1把错误输出也合并进去，这样出异常时不会漏看关键堆栈。启动完顺手curl http://127.0.0.1:8080/探活，返回 HTTP 200 或登录页内容说明服务起来了。如果端口不通，别急着查代码，先看防火墙和云平台安全组——这是部署环节最高频的翻车原因。

4.3 一个数据库连接的注意事项：公网 IP、时区与 SSL

本地开发连localhost:3306毫无压力，换到服务器后数据库连接串经常出幺蛾子。第一个坑是 MySQL 版本驱动的时区报错：Server returns invalid timezone。解决方式是在连接串上显式声明时区，或者在 MySQL 里执行set global time_zone = '+08:00'。

第二个坑是数据库地址如果写的是公网 IP，务必确认云数据库控制台的白名单和安全组放行了 3306 端口。很多云厂商默认只允许内网访问，你从服务器外连会直接超时。第三个坑是 MySQL 8.0 之后默认启用 caching_sha2_password 认证，如果你的驱动版本太老会报认证失败，把 pom 里mysql-connector-java升到 8.0.33 以上即可。下面是 prod 配置的一个可靠模板：

spring: datasource: url: jdbc:mysql://rm-xxxx.mysql.rds.aliyuncs.com:3306/community?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true username: prod_user password: ${DB_PASSWORD} driver-class-name: com.mysql.cj.jdbc.Driver

useSSL=false是为了避免本地测试时 SSL 握手失败，生产环境如果数据库在内网且链路安全，保持关闭问题不大。allowPublicKeyRetrieval=true专门解决 MySQL 8.0 用 caching_sha2_password 时公网连接报Public Key Retrieval is not allowed的问题。密码用${DB_PASSWORD}从环境变量注入，不要在配置文件里写明文——你永远不知道这份配置会不会被截图发到群里提问。

5. 部署与运行中的 5 个典型踩坑：版本、路径、端口、时区和数据库连接

5.1 现象1：Spring Boot 版本太高，本地能跑、服务器 404 或启动失败

本地mvn spring-boot:run一切正常，打包上传到服务器后java -jar直接报No active profile set或端口起不来，再细看根本原因是 Spring Boot 3.4 及以上版本对 JDK 版本要求变成了 17+，服务器上只有 JDK 8。这个现象我用一次少一次，后来养成了先java -version再选 Spring Boot 版本的习惯。常见做法是 Spring Boot 2.7.x 配 JDK 8，Spring Boot 3.x 配 JDK 17+，混搭必报版本兼容错误。解决方式是你先确认服务器 JDK 版本，再回看 pom 里的spring-boot-starter-parent版本，两边对齐。另外 Spring Boot 3.x 里javax.servlet全部换成了jakarta.servlet，如果你参照老教程写拦截器还 import 着javax，编译能过是因为本地缓存了旧包，服务器上用干净仓库拉依赖直接失败。

5.2 现象2：application.yml 里的路径带了奇怪前缀，静态资源被拦截

登录页能出，但刷新页面就 404。查日志没报错，后端接口也通，问题往往出在 controller 层对静态资源做了全拦。比如你想用拦截器校验登录态，addPathPatterns("/**")把所有请求都拦了，/js、/css、/img这些静态资源也被要求带 token，自然全挂。解决方式是在注册拦截器时显式放行静态路径：registry.addInterceptor(authInterceptor).addPathPatterns("/**").excludePathPatterns("/login", "/js/**", "/css/**", "/img/**", "/error")。Spring Boot 2.x 以后把静态资源默认放到了classpath:/static/，路径不对时按这个顺序找：META-INF/resources→resources→static→public。部署后静态资源 404 时先确认资源确实在target/classes/static下，而不是在 src 里但没被 Maven 打包进去。

5.3 现象3：端口被占用或云服务器安全组没放行，外网访问不通

服务器上进程在跑，curl localhost:8080有响应，但你用浏览器访问公网 IP 就是打不开。查顺序是先看监听：netstat -tlnp | grep 8080，确认进程在 0.0.0.0 上监听而不是 127.0.0.1——后者只有本机能访问。再看防火墙：systemctl status firewalld和iptables -L -n，有云盾或安全狗之类的也要看。最后看云平台控制台，轻量应用服务器在防火墙页面放行 8080，ECS 在安全组里加一条入方向规则。这个坑不分水平高低，几乎每个部署过的人都栽过。解决后记得把 jar 启动参数里加上--server.port=8080显式指定端口，防止服务器上的环境变量覆盖你的配置。

5.4 现象4：数据库时区不对，缴费截止时间提前了 8 小时

缴费账单的deadline是当天 23:59:59，业主在 23:30 缴费，系统却判成逾期。这类问题排查时你先查数据库：SELECT NOW()看时间对不对，再查应用日志里打印的时间。常见做法是把数据库连接串serverTimezone显式设为Asia/Shanghai，同时 JDBC 驱动版本升级到 8.x，因为 5.x 驱动不认识Asia/Shanghai这个写法。应用层再在application.yml配置spring.jackson.time-zone: GMT+8，保证 JSON 序列化时间也统一。层与层之间的时区不一致，就是这种「差 8 小时」的玄学 bug 源头，别想着靠 MySQL 默认时区解决，显式声明是唯一靠谱做法。

5.5 现象5：前端 Vue 打包后放进 Spring Boot 时，刷新 404

如果你选了前后端分离，前端构建产物放在src/main/resources/static下，直接访问首页没问题，一刷新路由就 404。原因是 Vue Router 默认用 history 模式，前端路由是/owner/list，后端没有这个路径对应的 controller，Spring Boot 返回 404。解决方式有两条：一条是 Vue Router 改为 hash 模式，URL 变成/#/owner/list，刷新不再请求后端；另一条是后端加一个 fallback 的 controller 转发所有非 API 路径到index.html。常见做法是：

@Controller public class SpaForwardController { @RequestMapping(value = {"/{path:[^\\.]*}", "/**/{path:[^\\.]*}"}) public String forward() { return "forward:/index.html"; } }

注意前面有个关键约束：带点的路径不转发。像/api/xxx和/js/app.js不会被误伤。否则会出现 API 接口被转发到 index.html 的诡异情况。整套 Vue 打包放进 Spring Boot 的做法能省一台前端服务器，但排查问题时你最好心里清楚：前后端请求混在一个 fat jar 里，区分不了是前端路由问题还是后端接口问题，所以接口请求路径统一加/api前缀，全生命周期都受益。

6. 上线后的进阶验证：慢查询、缓存命中与演示数据的三个自查动作

6.1 开 SQL 日志：把 MyBatis 的执行计划暴露出来

系统跑通了，别急着交差，先用一条配置把 SQL 日志打开，看每个列表页到底查了几次数据库。我一般会在application.yml里加这段配置，只对测试和生产环境生效，避免本地开发时日志刷屏：

logging: level: com.example.community.mapper: debug

debug级别下，MyBatis 会把每个 mapper 方法的完整 SQL 和执行参数打出来。看的时候重点盯两个地方：一是<foreach>批量插入是否生成了几百条 insert；二是关联查询是否触发了 N+1 次查询——比如一次页面加载先查 20 个业主，再对每个业主各查一次房屋。前者改批量执行，后者改一次 join 或增加@Select注解优化。这个自查动作十分钟就能做完，答辩时老师问「你做过性能优化吗」，你能说出 N+1 这个具体词，效果比讲一堆理论强得多。

6.2 给业主列表加一个本地缓存：聊聊命中率怎么衡量

反复查数据字典和业主信息时，加一个本地缓存能明显降低数据库压力。Spring Boot 自带@EnableCaching，用法是启动类加注解，查询方法上标@Cacheable(cacheNames = "owner", key = "#id")。但缓存不是加完就完事，你得验证命中率。比如用 Caffeine 作为本地缓存，可以暴露一个统计接口，看到hitCount和missCount；如果命中率长期低于 50%，说明缓存粒度设错了，比如把整张表当 key 缓存，业主一改资料就全量失效。我这个项目的经验是：数据字典缓存命中率能到 95% 以上，业主列表缓存命中率看数据量，几千条时没必要缓存，直接查库更快——加缓存前先确认查询真的慢，别为了展示技术栈而表演式加缓存。

6.3 演示数据的准备技巧：用一张 seed 表控制可重复导入

答辩演示前最怕演示数据被弄脏。物业管理员手滑把演示环境里的业务数据改乱了，或测试时误删了某条关键记录。我的做法是单独建一张sys_seed_record表，记录脚本每次执行的批次号，演示数据初始化.sql里的插入语句全部带上批次号，这样重跑脚本时先按批次号删掉旧数据再重新插入，不会重复堆积。核心业主的演示数据固定用几个容易记的名字（比如「张三」「李四」），房屋地址统一用一个虚拟楼栋，方便演示时对着业务方喊「你看这户的报修单已经流转到待评价了」。这套 seed 脚本结构不要做成一次性交付，后期改动表结构时同步更新，不然脚本和表结构对不上，演示现场才来调 SQL 就尴尬了。

我吃过最大的亏是没保留一份「干净种子 + 可重复初始化」的备份就带着电脑去答辩，结果演示前一晚把数据库改崩了，连夜重构。现在不管什么项目，都会在写完代码后先做三件事：导出一份查了所有核心表的演示数据、写一份可重复执行的初始化脚本、把 docker-compose 或部署命令写进 README。本地能重复搭建环境，才有底气处理现场问题。希望这篇笔记能帮你把这个常见的毕设题目做成一个真正能跑、能讲、能部署的完整项目。

本文还有配套的精品资源，点击获取