简介《毕设-小康之家-智慧社区管理系统》是一套面向高校毕业设计及课程设计的完整项目包聚焦智慧社区场景覆盖居民信息管理、物业缴费、社区公告、报修服务、智能安防、活动策划与报名等核心模块能够帮助学习者快速理解社区数字化管理系统的业务逻辑与技术实现。压缩包共含2000个文件整体大小25.55MB其中js、php、html、css为前后端代码xml与sql为配置及数据库文件md与txt包含说明文档png、jpg等为界面素材与截图目录结构清晰便于按模块查阅。目前已有135人学习使用。借助这套项目源码学习者可获取完整的代码与数据库设计参考居民信息增删改查、在线缴费流程、维修工单流转等功能的实现方式也可以借鉴其角色权限管理与B/S架构搭建思路适合需要完成类似选题或想提升Web开发实战能力的学生使用。1. 毕设-小康之家-智慧社区管理系统.zip比“功能齐全”更值钱的是“一条业务走通”答辩现场最怕看到这样的演示点开一个页面表格能查能增删改然后停下来等评委提问。如果题目落在“智慧社区管理系统”真正拉开差距的是业主报修、物业接单、完成回访这条线能不能一口气走通是访客从登记到门禁放行的权限能不能实时生效是缴费账单和流水能不能对上。这套“小康之家”毕设技术上的价值不取决于选了什么框架而在于它把你带进“小区物业”这个具体业务场景房屋、业主、工单、账单、车位、公告彼此之间靠外键约束和状态流转串起来。它适合想做完整 Web 全栈的同学拿来做课设框架参考也适合想进入智慧社区领域的从业者作为二次开发的起点。2. 先把数据库拆明白16 张表如何把社区业务分成三层拿到“智慧社区管理系统”这个题我通常不先画页面也不先写接口而是把业务对象拉出来建表。原因很简单这套系统里超过一半的“难”都集中在表关系上一个业主名下可能有多套房产一套房产也可能登记了夫妻两人报修工单从提交到完成要经历四个状态访客记录要和房屋、门禁时间对上。页面可以后面再改数据模型错了后面每个接口都要跟着返工。省事的做法是只建 user、repair、room 三张表能演示但一被追问就露馅。常见的交付级做法会控制在 16 张表左右按“用户权限、空间资源、业务流水”三层组织。下面按这个分层把每张表的职责讲清楚并给出可以照抄的建表 SQL。2.1 用户权限层user 表加 role 字段还是拆出 RBAC 五张表智慧社区的管理端和业主端分属两套界面角色天然只有管理员、物业人员、业主三种。对这个量级最稳的是先用单表加 role 字段不要一上来就做五表 RBAC。我见过不少毕设把 user_role、role_menu、menu 表全建出来最后菜单还是写死在前端路由里RBAC 反而成了摆设。如果担心不够工程化可以在 user 表之外加一张简单的角色字典表用外键关联含义足够表数量也不会膨胀。下面是这套系统里最推荐的用户表结构CREATE TABLE user ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 主键, username VARCHAR(50) NOT NULL COMMENT 登录名, password VARCHAR(100) NOT NULL COMMENT BCrypt 加密后的密码, real_name VARCHAR(50) NULL COMMENT 真实姓名, phone VARCHAR(20) NULL COMMENT 手机号, role_code VARCHAR(20) NOT NULL DEFAULT OWNER COMMENT OWNER/ADMIN/PROPERTY, avatar VARCHAR(255) NULL COMMENT 头像访问路径, status TINYINT NOT NULL DEFAULT 1 COMMENT 1启用 0禁用, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_username (username) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;这里几个字段值得说明。username 上建唯一索引是最基础的防重复注册手段password 务必用 BCrypt 编码后入库不要明文答辩时老师很喜欢查这一项role_code 用字符串而不用数字是为了代码里可读性更好比如在拦截器里写OWNER.equals(roleCode)比记住 0、1、2 直观得多。status 字段是软删除之外的另一个保命开关某个业主账号被投诉时可以直接禁用而不是删数据。角色字典表可以同样简单CREATE TABLE role_dict ( role_code VARCHAR(20) NOT NULL COMMENT 角色编码, role_name VARCHAR(50) NOT NULL COMMENT 角色名称, sort_no INT NOT NULL DEFAULT 0, PRIMARY KEY (role_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT角色字典表;如果你想在答辩时给自己加一点亮点可以在 user 表上加一个wechat_openid字段作为后续对接业主微信端的方向。这一层的核心思路是权限控制在拦截器里用注解做表结构保持简单不要把毕设做成企业级后台那样一上来就是几百个用户组。2.2 空间资源层楼栋、房屋、车位怎样关联才不出乱子小区业务里最典型的空间对象是楼栋和房屋其次是车位。常见设计错误是把楼栋号、单元号、房号直接拼成一个字符串存在订单表里。省事是省事但要统计“3号楼有多少工单”时就得写 LIKE 查询性能难看演示时也容易被问住。正确做法是拆成 building 表和 room 表CREATE TABLE building ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 楼栋ID, building_no VARCHAR(10) NOT NULL COMMENT 楼栋号如 3, address VARCHAR(100) NULL COMMENT 楼栋地址, PRIMARY KEY (id), UNIQUE KEY uk_building_no (building_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT楼栋表; CREATE TABLE room ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 房间ID, building_id BIGINT NOT NULL COMMENT 所属楼栋ID, unit_no VARCHAR(10) NULL COMMENT 单元号, room_no VARCHAR(20) NOT NULL COMMENT 房号如 1201, area DECIMAL(10,2) NULL COMMENT 建筑面积, owner_user_id BIGINT NULL COMMENT 当前绑定业主ID, PRIMARY KEY (id), UNIQUE KEY uk_building_unit_room (building_id, unit_no, room_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT房屋表;room 表里我给了owner_user_id字段这在毕设级别足够用一房一户最简单直接。如果你想做得严谨一点就拆一张owner_binding关系表把“业主-房屋-绑定时间-解绑时间”记成流水以后查房屋历史业主就有依据。但要注意拆成关系表后查询当前房屋业主时要在业务层过滤end_time IS NULL逻辑复杂度会上升我一般默认毕设用字段直挂答辩时口头说明升级方案即可。车位的设计思路类似但要注意车位和房屋不是同一张表能装下的东西车位归属可以绑定房屋也可以单独出售而且一个车位可能绑定多辆车。更稳的结构是park_space车位、park_usage绑定或车辆进出流水两张表配合不要试图在 room 表里加一个parking_no字段把两者揉在一起。2.3 业务流水层报修单、账单、访客记录的表结构细节业务流水表是整个系统里最容易“看起来懂了、实现起来翻车”的地方。先说报修单核心是状态机我用status字段表示从 0 到 4 流转提交、派单、处理中、待验收、已完成。之所以用整数不用字符串是为了排序和索引更紧凑且代码里用常量类统一取名不会出现“处理中”和“处理完成”这种拼写混乱。CREATE TABLE repair_order ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 工单ID, order_no VARCHAR(32) NOT NULL COMMENT 业务单号如 R202402150001, room_id BIGINT NOT NULL COMMENT 报修房屋ID, room_desc VARCHAR(255) NULL COMMENT 报修时房屋快照如 3栋1单元1201, owner_user_id BIGINT NOT NULL COMMENT 报修业主ID, category_code VARCHAR(20) NULL COMMENT 报修分类WATER/ELEC/DECOR/OTHER, description VARCHAR(500) NOT NULL COMMENT 问题描述, images VARCHAR(1000) NULL COMMENT 图片路径逗号分隔, status TINYINT NOT NULL DEFAULT 0 COMMENT 0已提交 1已派单 2处理中 3待验收 4已完成, assign_user_id BIGINT NULL COMMENT 接单物业人员ID, assign_time DATETIME NULL COMMENT 派单时间, finish_time DATETIME NULL COMMENT 业主验收完成时间, rating TINYINT NULL COMMENT 1-5星评价, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_owner_status (owner_user_id, status), KEY idx_room_id (room_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT报修工单表;这里有三个字段容易被省略但很有价值。room_desc是报修时刻的房屋快照房屋绑定关系以后可能会变快照保证工单历史可追溯images用逗号分隔存路径毕设里比建一张附件子表更省事但前提是图片文件本身落盘路径要固定rating可空只有业主点验收时才写入这个字段在演示“服务闭环”时是最好讲的一个点。另外order_no生成规则我用的是“R 日期 四位流水”单机场景下足够但如果你用了 Redis可以改成 Redis 自增保证并发下不重复。账单表我习惯拆成payment_bill应收账单和payment_record实收流水两张表。很多初学者只建一张“缴费记录表”导致一个问题物业生成了一个月的物业费账单业主分三次付清账怎么记两表分离后bill 是金额record 是每次实付bill_id外键关联剩余金额用bill.amount - sum(record.amount)计算。这是应收和实收分离的思路答辩时稍微提一句“我参考了应收实收分离的设计”观感会完全不一样。访客记录表相对独立但有一个字段需要想清楚二维码有效期怎么存。我建议存expire_time时间戳而不存“有效时长”因为生成时间和过期时间之间的换算一旦分发到不同服务就会产生时区差异。CREATE TABLE visitor_record ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 访客记录ID, room_id BIGINT NOT NULL COMMENT 被访房屋, owner_user_id BIGINT NOT NULL COMMENT 受访业主, visitor_name VARCHAR(50) NOT NULL, visitor_phone VARCHAR(20) NULL, plate_no VARCHAR(20) NULL COMMENT 车牌号, qr_code VARCHAR(255) NULL COMMENT 生成的二维码内容, expire_time DATETIME NOT NULL COMMENT 通行码过期时间, status TINYINT NOT NULL DEFAULT 0 COMMENT 0未入场 1已入场 2已过期 3已取消, create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_room_status (room_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT访客通行记录表;2.4 初始化 SQL 的组织方式别把脚本堆在一个文件里数据模型定了落地还有一个习惯问题。我一般把 SQL 拆成三个文件schema.sql建库建表、data.sql塞演示数据并在data.sql里按“用户-房屋-账单-工单”分节注释。不要把全部建表和 insert 堆在一个文件里那样每次重跑都被人为失误打断。演示数据每张表控制在 5 到 10 条够看就好但要用固定主键比如 user id 从 1 开始room id 对应关系写死这样后续联调时前端调试数据不会漂移。一个很划算的加分做法在data.sql里插入三条同一房屋的工单分别处于已提交、处理中、已完成答辩现场演示列表 Tab 筛选时数据是现成的。这个习惯成本很低但对演示节奏的帮助非常大后面第 6 章我会展开讲演示数据的组织。3. 业务主链路落地报修、访客通行、账单缴费的实现顺序数据库定下来之后实现顺序直接影响调试效率。我的习惯是先做“报修闭环”再做“访客通行”最后做“账单缴费”因为这条顺序刚好对应从简单状态流转到跨表事务难度渐次递进。如果把缴费放在第一个做一上来就是金额精度和事务回滚新手很容易在前期被劝退。3.1 报修闭环业主提交、物业接单、验收评分的一条龙接口报修的业务规则是业主提交工单后状态为 0物业接单改为 1处理中改为 2物业完成后改为 3待验收业主点击确认后改为 4并可选填评分。这个流程在后端建议写成五个独立接口而不是一个接口里根据参数走 if-else。因为状态机每一步都可能附加校验逻辑拆开以后每一步的权限校验都清晰。以 Spring Boot 为例提交工单的接口如下PostMapping(/repair) PreAuthorize(hasRole(OWNER)) public ResultLong createRepair(RequestBody RepairCreateRequest req) { // 1. 校验业主身份与绑定房屋 Long ownerId SecurityUtils.getCurrentUserId(); Room room roomService.getById(req.getRoomId()); Assert.isTrue(room ! null room.getOwnerUserId().equals(ownerId), 只能给本人名下房屋报修); // 2. 生成业务单号R yyyyMMdd 4位随机数 String orderNo R LocalDate.now().format(DateTimeFormatter.ofPattern(yyyyMMdd)) String.format(%04d, (int) (Math.random() * 10000)); // 3. 快照房屋信息避免后续绑定关系变化影响工单可读性 RepairOrder order new RepairOrder(); order.setOrderNo(orderNo); order.setRoomId(room.getId()); order.setRoomDesc(room.getBuildingNo() 栋 room.getUnitNo() 单元 room.getRoomNo()); order.setOwnerUserId(ownerId); order.setDescription(req.getDescription()); order.setImages(req.getImages()); order.setStatus(0); repairOrderService.save(order); return Result.ok(order.getId()); }这段代码建议逐行读懂。第 1 步先做归属校验这是接口安全的最低标准第 2 步单号生成用了Math.random()它适合演示但如果你想体现工程意识就改成基于 Redis 自增或雪花算法并说明原因第 3 步快照字段roomDesc是这套表设计里最值得在答辩时展开讲的设计点。接单接口的核心是把 status 做前置校验再更新PostMapping(/repair/{id}/accept) PreAuthorize(hasRole(PROPERTY)) public Result? acceptRepair(PathVariable Long id) { RepairOrder order repairOrderService.getById(id); Assert.isTrue(order.getStatus() 0, 只有已提交状态的工单才能接单); order.setStatus(1); order.setAssignUserId(SecurityUtils.getCurrentUserId()); order.setAssignTime(LocalDateTime.now()); repairOrderService.updateById(order); return Result.ok(); }关键就在Assert.isTrue(order.getStatus() 0, ...)这一句。很多翻车案例是接口没有做前置状态校验导致已完成的工单被再点一次“接单”状态直接倒退回 0数据库里的历史记录再也说不清。状态机设计的价值正在于此每个状态转换只能由特定角色触发且只能从合法的前序状态流转。后面的“处理中”“待验收”“验收评分”接口结构一样只是前置状态和角色不同。3.2 访客通行过期时间校验必须放在后端访客流程常见做法是业主在业主端填写访客姓名电话系统生成一个带expireTime的二维码访客到门禁处展示二维码保安或对讲设备扫描后校验时间有效即放行。这里最容易犯的错是把过期时间交给前端判断——前端按钮显示可通行后端不校验结果扫码设备只认前端传的字段改手机时间就能绕过。后端校验的核心代码是PostMapping(/visitor/{id}/check) PreAuthorize(hasRole(SECURITY)) public ResultBoolean checkVisitor(PathVariable Long id) { VisitorRecord visitor visitorService.getById(id); Assert.notNull(visitor, 访客记录不存在); if (LocalDateTime.now().isAfter(visitor.getExpireTime())) { visitor.setStatus(2); // 标记过期 visitorService.updateById(visitor); return Result.ok(false); } if (visitor.getStatus() 0) { visitor.setStatus(1); visitorService.updateById(visitor); } return Result.ok(true); }这里有一个细节过期后顺手把数据库记录状态改成 2而不是每次都在 if 里计算。这样做的好处是列表页可以直接按状态筛选“已过期”不用每次做时间比较。第二个细节是visitor.getStatus() 0的二次判断保证同一条二维码不能重复入场否则同一条码扫一次放行、再扫一次又放行真实门禁场景就是事故。二维码内容建议只放 visitorId 和随机串不放真实手机号这个细节既保护隐私又能在答辩时展示你考虑到了数据泄露风险。3.3 账单缴费金额用 DECIMAL事务要跨两张表账单缴费的逻辑最考验基本功生成账单时只插入payment_bill表金额用 DECIMAL(10,2)业主支付时插入payment_record表并更新账单的已付金额。有人会问为什么不直接更新 bill 表加个 paid_amount 字段那样确实简单但没法回答“这个业主分三次缴费分别是什么时间”这个问题。服务端扣款接口建议使用事务Transactional(rollbackFor Exception.class) PostMapping(/payment/record) public Result? pay(RequestBody PaymentRequest req) { PaymentBill bill paymentBillService.getById(req.getBillId()); Assert.isTrue(bill.getStatus() 0, 账单已结清不能重复支付); PaymentRecord record new PaymentRecord(); record.setBillId(bill.getId()); record.setPayAmount(req.getAmount()); record.setPayChannel(req.getChannel()); // 微信/支付宝/线下 record.setPayTime(LocalDateTime.now()); paymentRecordService.save(record); // 计算累计已付若大于等于账单金额则置为已结清 BigDecimal paid paymentRecordService.sumAmountByBillId(bill.getId()); if (paid.compareTo(bill.getAmount()) 0) { bill.setStatus(1); bill.setPaidTime(LocalDateTime.now()); paymentBillService.updateById(bill); } return Result.ok(); }这里有两个容易跳的坑。第一个是Transactional只加在方法上还不够还需要确认它被 Spring 代理调用也就是不能同类内自调用第二个是金额比较用了compareTo而不是BigDecimal 用equals或都可能在精度上出问题compareTo才是正解。这两点属于“代码看起来没问题但实际运作有隐患”答辩时主动说出来反而会变成加分项。3.4 Vue 请求封装统一 /api 前缀的三个理由后端接口设计好了前端请求封装有一个点对整个项目维护影响很大把 baseURL 抽成环境变量而不是写在每个请求函数里。开发环境用 Vite 的 server.proxy 做转发页面代码里请求路径直接用/api/...由 Vite 代理转发到后端 8080 端口本地联调不会碰跨域。打包后部署再用 Nginx 把/api前缀反向代理到后端。统一前缀有三个理由一是跨域配置只写一次二是后端如果调整 context-path前端只需要改环境变量三是网络请求日志里很容易区分静态资源和接口。4. 把系统跑起来从初始化 MySQL 到前端联调的最小步骤这一章写给第一次完整跑这个项目的同学。前后端分离的项目本地运行拆成四步数据库先初始化、Redis 起服务、后端打 jar 包启动、前端 dev server 启动。这个顺序不能乱因为后端启动时如果连不上数据库和 Redis大概率会直接报错退出前端晚一点启动没关系但后端没起来点接口全报网络错误浪费排查时间。4.1 MySQL 初始化与账号权限别用 root 跑服务先用schema.sql建库、建表再执行data.sql导入演示数据。执行之前确认 MySQL 字符集是utf8mb4否则业主姓名里带生僻字或表情符号会插入失败。初始化命令如下mysql -uroot -p schema.sql mysql -uroot -p data.sql # 检查是否导入成功 mysql -uroot -p -e USE smart_community; SHOW TABLES;如果data.sql里 insert 语法不对MySQL 会在中途停住并打印大段报错。解决要点是把每个 insert 语句之前加注释分段执行定位出错在哪一段。导入之后再创建一个后端专用账号不要用 root 直接跑服务CREATE USER sc_applocalhost IDENTIFIED BY sc_app_pwd_2024; GRANT SELECT, INSERT, UPDATE, DELETE ON smart_community.* TO sc_applocalhost;只授权项目库不授权全局权限这个习惯能让你在答辩时应对“数据库安全性”的问题。MySQL 初始化成功后再启动 Redis默认 6379 端口不需要额外配置本地没有 Redis 时Windows 上可以用 Memurai 或 WSL 里装一个不建议用 Docker 时把端口映射搞复杂。4.2 后端 application.yml必调的五个参数后端是 Spring Boot 时application.yml里有五个参数最常因理解不到位而配错端口、数据源、时区、上传文件路径、Redis。可直接抄这份示例server: port: 8080 servlet: context-path: / spring: datasource: url: jdbc:mysql://localhost:3306/smart_community?useUnicodetruecharacterEncodingutf8serverTimezoneAsia/ShanghaiuseSSLfalse username: sc_app password: sc_app_pwd_2024 redis: host: localhost port: 6379 timeout: 3000ms servlet: multipart: max-file-size: 10MB max-request-size: 20MB file: upload-path: /data/sc_community/upload/提示JDBC URL 里的serverTimezoneAsia/Shanghai非常关键。不加它MySQL 驱动会用服务器默认时区解析时间常见现象是数据库存的时间比实际早 8 小时尤其当数据库部署在非东八区时。关于file.upload-path建议本地调试用绝对路径Windows 上改成D:/sc_community/upload/。千万别用相对路径./upload/因为用 IDE 启动和用 jar 启动的工作目录可能不同会出现开发能传图、打包后图片 404 的问题。后端启动命令mvn spring-boot:run # 或者打包后用 jar 启动 mvn clean package -DskipTests java -jar target/smart-community-0.0.1-SNAPSHOT.jar启动成功时日志最后会有 Tomcat started 类似字样。如果报错优先看是数据源连接失败还是端口被占用这两类占毕设启动失败的一半以上。端口被占用时用lsof -i:8080或 Windows 的netstat -ano | findstr 8080查占用进程。4.3 Vite 代理配置本地联调不碰跨域前端使用 Vite 时只需要在vite.config.js里配一个代理就能解决跨域问题// vite.config.js export default defineConfig({ server: { port: 5173, proxy: { /api: { target: http://localhost:8080, changeOrigin: true, rewrite: path path.replace(/^\/api/, ) } } } })这里的核心是rewrite。如果后端接口路径本来就以/api开头就不需要 rewrite如果后端接口是/repair/list前端统一用/api/repair/list访问则必须加这一行把/api去掉再转发。很多人前端请求 404调试半天发现是后端路径和前端路径对不上实际上就是 rewrite 规则写反了。前端安装依赖时如果npm install慢可以换国内镜像源但注意不要提交node_modules到代码包。启动命令npm install npm run dev启动后浏览器访问http://localhost:5173打开开发者工具 Network能看到/api/repair/list请求返回 JSON 而不是 HTML就证明前后端打通了。4.4 第一次联调自检清单登录、授权、404、图片第一次联调建议按顺序验证四件事。第一登录接口能拿回 token并且请求头带上 token 后能访问业主端接口。第二切换不同角色账号登录权限拦截生效业主账号访问物业接口返回 403。第三地址栏直接访问一个不存在的页面路径应返回 404 而不是空白页。第四提交一个带图片的报修单刷新页面后图片依然能显示。这四件事都通过说明项目从数据到接口到前端的核心链路是健康的。如果卡在某一步就用第 5 章的清单逐条对照。5. 毕设避坑指南这五个坑不处理演示时容易现场翻车这一章五条经验都来自同类项目的真实调试。每一条按“现象、原因、解决”讲清楚方便快速定位。5.1 时间少了 8 小时时区参数的连锁反应现象业主明明下午提交报修单列表里显示的时间却是凌晨。原因数据库连接 URL 少了serverTimezone参数或者把时区写成了 UTC。MySQL 驱动解析 DATETIME 时会按连接指定的时区转换时区不对必然错位。解决在 JDBC URL 上统一加serverTimezoneAsia/Shanghai同时项目里所有时间字段统一用LocalDateTime不要混用Date和String。这算是典型的“玄学”问题业务代码没错时间就是不对查到最后往往只差一个连接参数。5.2 页面能开但接口全 404rewrite 规则和路径约定现象首页能渲染但列表数据死活不出来Console 里全是 404。原因前后端路径对不上。最简单的情况是后端接口是/repair/list前端却请求/api/repair/list且 Vite 代理没有 rewrite导致后端收到的路径是/api/repair/list匹配不上。解决先看浏览器 Network 里的完整请求 URL再和后端 Controller 的RequestMapping路径对比。全项目统一以/api开头前后端都用它代理里不要做两级拼接这个约定能省掉大半的联调痛苦。5.3 上传的图片刷新后变裂图本地相对路径惹的祸现象上传时报修单里能看到图片一旦刷新页面图片全裂。原因图片存的是后端本地绝对路径但前端把它拼成 URL 去访问前端域名下自然找不到后端文件。解决后端提供一个静态资源映射把/files/**访问映射到上传目录前端图片 URL 存相对路径由后端统一拼接域名。Spring Boot 里只需一个配置类把本地目录映射成虚拟路径/files/不需要改表结构。5.4 重复提交报修单前端防双击与后端唯一索引现象网络稍慢时用户连续点了两下“提交报修”生成了两条一样的工单。原因前端没有防重复提交后端也没有幂等校验。解决前端在按钮点击后立刻置灰同时后端order_no生成后建唯一索引。更严谨的做法是为每个表单生成一个requestId入库前先查一次是否已存在存在就直接返回已有记录这样就不是前端防双击而是后端兜底。5.5 访客码过期判断被前端“篡改”服务端时间才是权威现象访客二维码还没到过期时间门禁端显示已过期或者手机改了时间还能继续进。原因校验时用了前端本地时间和前端传入的状态字段后端没有做权威判断。解决统一以后端时间为准二维码里只放记录 ID校验接口用LocalDateTime.now()和数据库expire_time比较。即使答辩没被问到也建议主动说一句“过期判断放在服务端避免客户端时间被篡改”会让老师觉得你想到了真实安全场景。6. 验收加分的关键一步操作日志加固定演示数据让答辩会讲故事系统能跑只是及格线答辩时真正抓人的是“证据链”。什么叫证据链打开报修列表能看到一条工单从提交到派单到完成每一步都有时间、操作人、状态变化业主端能看到账单从待支付到已结清支付时间、支付渠道一清二楚。为了生成这条证据链建议在数据模型之外再加一张操作日志表operation_log用切面拦截后端写操作自动记录操作人、接口、请求参数摘要、操作时间。Aspect Component public class OperationLogAspect { Around(annotation(operationLog)) public Object record(ProceedingJoinPoint pjp, OperationLog operationLog) throws Throwable { Object result pjp.proceed(); String userId SecurityUtils.getCurrentUserId() null ? anonymous : SecurityUtils.getCurrentUserId().toString(); logService.save(pjp.getSignature().getName(), userId, operationLog.value(), LocalDateTime.now()); return result; } }这段逻辑不要做太复杂只要在业主提交报修、物业接单、业主确认完成的接口上标注OperationLog(业主提交报修)演示时切到操作日志页就能给评委看一条完整的时间线。同时准备一组固定 ID 的演示数据把“3栋1201 业主”的报修、访客、缴费记录全部串成一个故事演示时就按这个故事的顺序点击不要临时乱点。我当年做类似项目时最早没留操作日志答辩现场临时点历史数据状态对不上最后靠重置数据库圆场后来把所有写操作都沉到日志表里演示时才真正觉得心里有底。希望这些经验能帮到你把它落到你的毕设里比多写两个页面更有价值。本文还有配套的精品资源点击获取
