企业官网建设流程全解析

1. 选题与需求拆解：为什么物业管理系统是毕业设计的常青树

每年到了毕业设计季，总能看到形形色色的管理系统选题，从图书管理到食堂订餐，从课程设计到论文评审，但“物业管理系统”始终是出现频率最高的那一批。我身边不少同学一开始嫌它“土”，觉得满大街都是，结果真正做下去才发现，物业管理系统几乎把企业级开发里最常见的业务场景全占了：基础档案管理、业务流程流转、状态机变化、权限控制、消息通知、报表统计，甚至还有支付和文件上传。把它啃透了，后面做任何管理系统都能顺藤摸瓜。

这套基于SpringBoot的物业管理系统，说白了就是围绕“小区里的人和事”做一套增删改查加流程处理的后台。业主、房产、车辆、缴费、报修、投诉、公告，这些实体之间天然存在关联，比单纯的单表CRUD有意思得多。比如“业主”和“房产”是多对一还是多对多？“缴费单”和“物业费标准”怎么联动？“报修单”从提交到派工到完成，状态怎么流转？想清楚这些问题，你的数据库设计和业务逻辑能力可以实打实上一个台阶。

从技术角度看，SpringBoot几乎是当前Java后端毕业设计的最优解，没有之一。它默认帮你搞定了Tomcat内嵌、自动配置、依赖管理，你只需要一个@SpringBootApplication注解就能跑起来。相比传统的SSH或SSM框架，SpringBoot省去了大量XML配置，让新手能把精力放在业务代码而不是环境搭建上。而且市面上SpringBoot的学习资料、示例代码、面试题多到看不完，遇到问题随手一搜就有答案，对赶论文、赶答辩的学生党极其友好。

这套源码适合谁？第一类是Java基础还行、但不知道做什么项目的同学，拿来拆解一遍能快速理解分层架构和数据流转；第二类是时间紧、需要快速跑通一套完整系统的同学，把项目启动起来改改数据库和页面就能作为演示；第三类是打算深挖源码的进阶玩家，通过阅读一个完整项目的编码风格、异常处理、MVC模式，能学到很多课程设计里不会教的东西。

但我要提前泼一盆冷水：如果你是打算原封不动交作业，建议别这么干。毕业设计的核心是“设计”二字，老师要看到的是你如何分析问题、如何拆解模块、如何解决实际问题。这套源码的价值在于提供一个高质量的可运行基座，你基于它做二次开发、加模块、优化设计，才能既省时间又说得清道得明。

2. 系统整体架构与核心表设计思路

2.1 功能模块划分：从物业管理员的日常工作反推需求

物业管理系统不像电商项目有那么强的“用户增长”逻辑，它的核心矛盾在于“物业公司如何高效管理小区资源并服务业主”。所以模块划分要从物业管理员的岗位职责去反推，而不是凭空想象。通常一套完整的物业管理系统包含以下六大模块：

• 系统管理：用户管理、角色管理、菜单权限、登录日志。这里负责的是“谁可以登录系统、能看哪些菜单、能做哪些操作”。
• 房产管理：楼宇、单元、房屋信息的维护，房屋状态（未售、已售、入住、空置）的管理，以及业主与房屋的绑定关系。
• 业主管理：业主档案的增删改查、家庭成员信息、联系方式、与房产的关联。一个业主名下可以有多套房产，一套房产也可能有多位共有人，这是最容易踩坑的设计点。
• 缴费管理：物业费标准的设置、账单自动生成、缴费记录登记、欠费查询、逾期提醒。这是整个系统的“财务命脉”，逻辑复杂度最高。
• 报修管理：业主提交报修单、物业派工、维修进度上报、业主评价，形成完整的工单闭环。
• 公告投诉：小区公告发布、投诉建议登记、处理反馈，相对独立但不可或缺。

模块划分最忌讳的是把“业主管理”做成一个孤立的CRUD。实际上业主和房产是一对多的关系，缴费和房产是关联的，报修又跟业主和房屋挂钩。所以设计模块时，脑子里要有一张数据关系图，每个模块都是这张图上的一个节点。

2.2 数据库表设计：关系比字段更重要

数据库是管理系统的地基，地基塌了，上面写得再花哨也是白搭。基于SpringBoot的物业管理系统，我推荐按如下核心表来设计，既满足业务需求，又不会过度复杂到压垮新手：

• building（楼宇表）：字段包括楼宇编号、名称、层数、单元数、备注。这是最顶层的房产“容器”。
• house（房屋表）：关键字段为楼宇ID、单元号、房号、面积、户型、状态（0未售/1已售/2入住/3空置）。房屋表必须冗余楼宇ID和楼栋名，避免每查询一次房屋都要关联楼宇表。
• owner（业主表）：字段包括姓名、手机号、身份证号（注意脱敏）、性别、入住时间。这里要设计一个中间表house_owner来维护房屋与业主的多对多关系，因为现实中一套房可能夫妻共有。
• fee_standard（费用标准表）：字段包括房产类型、面积区间、单价（元/平方米/月）、收费项目（物业费、停车费、垃圾清运费等）。缴费金额的关键计算逻辑就是“单价 × 面积 × 月份数”。
• payment_record（缴费记录表）：字段包括房屋ID、业主ID、费用类型、金额、计费月份、缴费时间、缴费方式、操作人。这张表记录的是“每一笔真实交出去的钱”。
• repair_order（报修工单表）：字段包括工单编号、房屋ID、业主ID、报修内容、报修类型（水/电/暖/其他）、状态（待派工/维修中/已完成/已评价）、派工人、完成时间、评价内容。
• notice（公告表）：字段包括标题、内容、发布人、发布时间、置顶标志。
• complaint（投诉建议表）：字段包括标题、内容、投诉人、处理人、处理结果、状态。

在设计表时，有两点我特别想强调。第一，所有业务表都要加create_time、update_time、deleted这几个审计字段，这是企业级开发的规范，也是答辩时能加分的点。第二，不要滥用外键。在真实的SpringBoot项目中，外键约束会影响插入和删除效率，团队开发时也容易造成耦合。我的做法是：只在逻辑层面维护关系，实体类中用@ManyToOne、@OneToMany标注关联，数据库层面只保留索引，不设置物理外键。这样既保证了数据查询的直观性，又提高了写入性能。

2.3 接口设计与权限模型：RESTful不是花架子

很多同学的接口设计就是“路由+Service调用”，完全没有规范的意识。这套系统的接口设计建议严格遵循RESTful风格：

• GET /api/owner获取业主列表（分页）
• POST /api/owner新增业主
• PUT /api/owner/{id}修改业主
• DELETE /api/owner/{id}删除业主（逻辑删除）
• GET /api/house/{id}/owners获取某房屋下的业主列表
• POST /api/payment/generate生成缴费账单
• POST /api/repair/{id}/dispatch派工

接口命名用复数名词，操作通过HTTP方法区分，路径尽量层级化。这对前后端分离的Vue项目尤其重要，前端团队可以根据接口文档直接对接，不需要后端反复解释。同时，所有接口返回统一封装为Result<T>：包含code、message、data三个字段。code为0表示成功，非0表示业务错误。这样做的好处是前端拦截器可以统一处理错误提示，而不是每个接口各自为政。

权限模型用Spring Security + JWT，或者更轻量的Sa-Token。我推荐前者，因为毕业设计考察的是你对主流框架的掌握程度。核心思路是：用户登录成功后颁发Token，后续请求在Header中携带Token，由拦截器解析用户身份和角色。角色设计为ADMIN（物业经理）、STAFF（物业工作人员）、OWNER（业主）三种。不同角色能访问的接口通过@PreAuthorize("hasRole('ADMIN')")等注解控制。比如业主只能查看自己的缴费记录和提交报修，而管理员可以查看所有工单并派工。权限模型不需要做得很复杂，把“基于RBAC的权限控制”这个点讲清楚，答辩时就是一道加分题。

3. 核心功能实现与源码细节深挖

3.1 业主与房产信息的动态关联

业主和房产的关系是这套系统里最容易出Bug的地方。我见过很多代码写成“业主表里加一个house_id字段”，结果一套房卖出后换了主人，旧业主的数据就被覆盖了。正确的做法是用关联表house_owner维护多对多关系，表结构如下：

CREATE TABLE `house_owner` ( `id` bigint(20) NOT NULL AUTO_INCREMENT, `house_id` bigint(20) NOT NULL COMMENT '房屋ID', `owner_id` bigint(20) NOT NULL COMMENT '业主ID', `relation` varchar(20) DEFAULT NULL COMMENT '与户主关系：本人/配偶/子女', `is_primary` tinyint(1) DEFAULT '0' COMMENT '是否为首要业主', PRIMARY KEY (`id`), KEY `idx_house` (`house_id`), KEY `idx_owner` (`owner_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

查询某业主名下所有房产时，SQL可以这么写：

SELECT h.* FROM house h INNER JOIN house_owner ho ON h.id = ho.house_id WHERE ho.owner_id = #{ownerId}

反过来查询某房产下的所有业主同理。实体类中，Owner里通过@ManyToMany映射房屋集合，House里也映射业主集合，中间表不需要单独建实体，直接用@JoinTable注解即可。但有一点要注意：如果中间表除了关联还有额外字段（如is_primary、relation），则必须单独建实体类来操作。这也是一个很经典的面试考点：关联表的建模深度。

实际编码时，新增或修改业主信息后，要同步维护house_owner表。建议在Service层提供事务方法bindOwnerToHouse(ownerId, houseId, relation)，统一处理绑定逻辑，避免出现“业主有记录但房屋绑不上”的脏数据。我在实际测试中发现，很多同学在这里会漏掉事务注解，导致并发操作时数据错乱。记得在方法上加@Transactional(rollbackFor = Exception.class)。

3.2 缴费管理：金额计算、账单生成与状态流转

缴费管理是整个系统含金量最高的模块，因为它既有规则计算，又有状态机变化。以物业费为例，计算逻辑是：应缴金额 = 物业费单价 × 建筑面积 × 计费月数。单价从费用标准表中读取，建筑面积从房屋表中读取。设计上，我推荐采用“先生成账单，后缴费销账”的思路，而不是直接让前台计算金额。

生成账单的伪代码如下：

public void generateBills(Long houseId, String yearMonth) { House house = houseMapper.selectById(houseId); FeeStandard standard = feeStandardMapper.findByHouseType(house.getHouseType()); BigDecimal amount = standard.getUnitPrice() .multiply(house.getArea()) .multiply(BigDecimal.valueOf(1)); // 默认按月生成 PaymentRecord record = new PaymentRecord(); record.setHouseId(houseId); record.setOwnerId(house.getPrimaryOwnerId()); record.setAmount(amount); record.setMonth(yearMonth); record.setStatus("UNPAID"); paymentRecordMapper.insert(record); }

这里的核心要点是：金额计算必须用BigDecimal，禁止使用double或float。因为浮点数在计算机中无法精确表示，0.1 + 0.2的结果是0.30000000000000004，涉及金钱时这是致命的。BigDecimal构造时也要用字符串构造器new BigDecimal("0.1")，不要直接传double。

账单状态一般分为：待缴费、已缴费、已作废、逾期。当业主缴费后，账单状态变为已缴费，同时在缴费记录中写入交易流水号、支付方式、操作时间。逾期状态可以通过一个定时任务实现：每天凌晨检查所有待缴费账单，如果截止日期早于当前日期，则状态置为逾期。这也是SpringBoot集成Quartz或Spring Task的典型场景。

我在实际项目中遇到的一个高频坑是：生成的账单没有关联具体的房屋和业主的“快照”。如果一个月后物业费单价调整或房屋面积变更，历史账单的金额就变得无法追溯。解决办法是：在账单表中冗余存储unit_price、area、amount等字段，生成账单时把这些值固化下来。宁可冗余，不丢历史。

3.3 报修工单流程：从提交到完结的闭环

报修工单是一个典型的流程型业务，状态随着用户操作不断迁移，通常包括：待派工→维修中→待验收→已完成（或已取消）。实现方式有两种：一种是直接在repair_order表里加一个status字段，每次更新状态；另一种是单独建一张repair_log表记录状态变更历史。我建议两种结合，既保留当前状态字段，又用日志表记录完整的操作轨迹。

报修模块的接口设计可以这样拆解：

• POST /api/repair业主提交报修，传入房屋ID、报修类型、问题描述、图片附件（可选）。
• PUT /api/repair/{id}/dispatch管理员派工，指定维修人员。
• PUT /api/repair/{id}/progress维修人员更新进度，比如“已上门”、“维修中”、“完成度80%”。
• PUT /api/repair/{id}/finish标记维修完成。
• POST /api/repair/{id}/evaluate业主提交评价。

每个步骤都需要校验当前状态是否允许该操作。比如“派工”只有待派工状态才能执行，否则抛出业务异常。在SpringBoot中，可以用枚举类定义状态集合，并通过StateMachine或者简单的if-else做状态校验。对于毕业设计，用if-else足够了，不需要引入复杂的工作流引擎。

报修模块的另一个细节是图片上传。这里可以集成MinIO，也可以更简单地用本地磁盘存储。如果用MinIO，SpringBoot里只需配置endpoint、accessKey、secretKey和bucket，然后封装一个MinioTemplate工具类。我看到很多淘宝二手源码里根本没有报修图片功能，因为涉及到文件上传后前后端联调的问题。我的建议是：如果时间充裕，能把报修流程完整跑通，包括状态流转和图片上传，这个系统就足以在答辩时展示“高完成度”。

3.4 公告发布与投诉建议的轻量实现

公告模块其实就是一个简单的“CMS”：发布、编辑、删除、置顶、分页查询。数据库字段很少，但有一个位置容易出彩：公告阅读量统计。可以用view_count字段，每次查询详情时update view_count = view_count + 1，或者在Redis里做计数器后异步落库。对于毕业设计，直接更新数据库字段也能接受，但要小心高并发下的大量写操作。这里我提一个折中方案：查询详情接口返回view_count，并在Service层延迟更新，比如5秒内同一条公告只更新一次阅读量，降低数据库压力。

投诉建议模块比公告稍微复杂一点，因为涉及到处理流程。状态通常为：待处理、处理中、已处理、已反馈。物业工作人员在处理后填写处理结果，系统自动通知投诉人（邮件或短信，毕业设计可以用站内信代替）。站内信功能可以单独建一张message表，在用户登录后拉取未读消息。这个功能虽然小，但能体现你对用户交互的考虑，也是答辩时的亮点。

4. 源码运行与环境搭建实战指南

4.1 拿到源码后先别急着跑

很多同学从网盘下载或GitHub克隆到源码后，直接双击启动，然后报错，接着就开始怀疑人生。这里我按经验排序，教你三步快速定位问题。

第一步，看项目的pom.xml或者build.gradle，确认JDK版本。现在很多SpringBoot项目要求JDK 1.8或11，如果你的本机装了17甚至21，很可能会因为默认生成的字节码版本不兼容而报错。解决办法是：要么在IDE中把项目SDK切换到匹配版本，要么修改pom.xml里的java.version（但改版本可能导致某些依赖不兼容，建议优先切SDK）。第二步，检查配置文件application.yml或application.properties。重点看数据源配置、Redis配置、端口号。如果数据库账号密码和你本地的对不上，先改成自己的。如果项目依赖Redis，本地必须装好Redis服务，否则启动时会连接超时。第三步，找到启动类Application.java，右键运行。如果控制台输出Started XxxApplication in x.xxx seconds，说明启动成功。

启动失败最常见的三个错误，我先给你打预防针：

• Cannot determine embedded database driver class for database type NONE：通常是因为没有配置数据源。确认application.yml里有spring.datasource.url/username/password。
• Port already in use：默认端口8080被占用了。在配置文件里改成server.port: 8081即可。
• Invalid bound statement (not found): com.xxx.mapper.UserMapper.findById：这是MyBatis的Mapper XML文件没有扫描到。检查启动类上的@MapperScan注解路径是否和Mapper接口包路径一致。

4.2 数据库初始化与基础数据导入

项目里的SQL脚本一般放在src/main/resources/db目录下，常见命名是schema.sql和data.sql。我的习惯是先在Navicat或DataGrip里手动执行这部分SQL，而不是完全依赖Spring Boot的自动执行机制。因为自动执行时一旦脚本中包含注释或特殊字符，容易因为编码问题报错。手动导入还能顺手检查表结构是否符合预期。

导入完成后，需要确认数据库中已经存在管理员账号。很多源码默认的管理员账号是admin/admin123，如果登录不上，直接查sys_user表的password字段，看是不是用了BCrypt加密。如果密码是明文，可以直接登录；如果是$2a$10$开头的BCrypt哈希值，说明登录时会用加密后的密码比对，你需要在注册或重置密码功能里换一个已知密码。这里有个小技巧：临时把密码改成123456的BCrypt哈希值，直接用BCryptPasswordEncoder生成一串替换即可。

4.3 前端项目与后端的联调配置

如果是前后端分离的项目，前端通常是一个Vue + ElementUI的管理后台。拿到Vue项目后，先执行npm install安装依赖，然后找到vue.config.js或者.env.development文件，配置代理。比如后端启动在8080端口，前端默认跑在9528端口，跨域问题就靠代理解决：

devServer: { port: 9528, proxy: { '/api': { target: 'http://localhost:8080', changeOrigin: true, pathRewrite: { '^/api': '' } } } }

注意这里如果后端的接口路径本身就是/api/xxx，那么pathRewrite就不能把/api去掉。你要先看清楚后端Controller类的@RequestMapping注解，统一路径前缀是什么。联调时最头疼的问题是“前端传参格式和后端实体对不上”。比如后端用LocalDate接收日期，前端传的却是"2025-06-01T00:00:00.000Z"，这种格式转换错误会让接口报400。解决办法是前后端约定好统一的时间格式，通常在SpringBoot配置类里注册：

@Bean public Jackson2ObjectMapperBuilderCustomizer customizer() { return builder -> builder.simpleDateFormat("yyyy-MM-dd HH:mm:ss"); }

对了，登录认证的Token要在前端请求拦截器里全局带上，否则每个请求都会401。Vue的axios配置如下：

axios.interceptors.request.use(config => { const token = localStorage.getItem('token') if (token) { config.headers['Authorization'] = 'Bearer ' + token } return config })

后端拦截器也要相应的放行登录接口和静态资源，这个放到[4.4]里说。

4.4 多环境配置与日志输出

一个完整的SpringBoot项目通常会区分dev、prod环境，配置文件拆成application-dev.yml、application-prod.yml，再通过spring.profiles.active指定当前环境。毕业设计至少要用上dev环境，这能体现工程化思维。配置内容上，dev环境建议开启SQL日志，方便调试：

logging: level: com.example.mapper: debug

MyBatis打印SQL后，你能直观看到参数绑定是否正常，排查逻辑错误的速度提升不止一倍。另外一个实用配置是server.servlet.context-path，如果你给系统加了个前缀，比如/property，那么所有Controller的请求路径前会自动加上这个前缀。这样做的好处是部署时可以用Nginx区分多个应用，缺点是前端代理也需要跟着调整，前后端联调时很容易忘记改动而踩坑，非必要不建议加context-path。

5. 源码二次开发建议与答辩准备

5.1 如何基于源码快速扩展新功能

刚拿到一套源码，不要急着改代码。先花半天把项目结构、实体类、Mapper接口、Service接口、Controller层的命名规范摸清楚。我有个“三层定位法”：拿到一个功能，先看Controller里有什么接口，再找Service里怎么调用Mapper，最后在Mapper XML里看SQL怎么写。反复三轮，你就能对整条链路烂熟于心。

想要快速扩展新功能，可以按照以下四步走：

1. 复制一个相近的实体类，比如想做“车位管理”，就复数house实体，改字段为车位号、绑定车辆、尺寸、状态。
2. 创建对应的Mapper接口和XML文件，先写一个最简单的selectList查询。
3. 创建Service和ServiceImpl，继承IService<T>并实现接口，这一步能借助MyBatis-Plus自带的CURD减少代码量。
4. 在Controller中暴露/api/parking相关的RESTful接口，然后在前端菜单中加一个页面。

如果你发现这套源码已经集成了MyBatis-Plus，那恭喜你，扩展CRUD功能基本不用写SQL。但注意，简单的增删改查MyBatis-Plus能搞定，复杂的统计查询还是要手动写@Select或XML里的动态SQL。

5.2 答辩现场的高频问题与应对思路

毕业答辩时，老师的问题通常集中在“设计思路”和“技术细节”上。以下是我总结的十个常见问题，建议你提前准备答案：

• 为什么选择SpringBoot而不是SSH？答：SpringBoot简化了配置，内嵌容器，易于微服务化，是当前主流。
• 项目的前后端如何交互？答：采用RESTful接口，前端通过axios发送HTTP请求，后端返回JSON数据，基于JWT做身份认证。
• 数据库表是如何设计的？答：从业务实体出发，分析实体关系，遵循三范式，同时为了查询效率适当冗余字段。
• 如何保证缴费金额计算的准确性？答：使用BigDecimal，避免浮点误差；账单金额固化保存，追溯历史。
• 遇到并发问题怎么解决？答：对修改操作加锁（乐观锁/悲观锁），或使用Redis分布式锁，本项目重点是避免重复缴费。
• 项目上线后如何部署？答：前后端分离，前端打包成静态文件部署到Nginx，后端打成Jar包运行在服务器，数据库用MySQL主从或备份。
• 什么是JWT，和Session有什么区别？答：JWT是自包含令牌，服务端不存状态，适合分布式场景。
• MyBatis-Plus和MyBatis有什么区别？答：MyBatis-Plus在MyBatis基础上提供通用Mapper和常用功能封装。
• 系统的权限是怎么控制的？答：基于RBAC模型，用户关联角色，角色关联权限，接口通过Spring Security注解校验。
• 你觉得这个系统还有什么可以优化的地方？答：可以引入Redis做缓存、用消息队列处理报修通知、增加大屏数据展示。

在回答技术问题时，不用讲太深，但要给出清晰的逻辑链条：输入是什么，经过什么处理，输出是什么，异常怎么处理。把自己写的代码和设计原因串起来，比背概念更有说服力。

5.3 论文写作：从源码反向梳理论文章节

论文写作最大的误区是“先写代码，最后拖着写论文”。实际上，论文和源码应该相互呼应。拿这套物业管理系统来说，论文目录可以这样组织：

• 第1章 绪论：写选题背景、国内外研究现状、论文结构。背景可以写物业管理数字化趋势、传统人工管理效率低等。
• 第2章 相关技术介绍：写SpringBoot、MyBatis、Vue、MySQL、JWT的核心原理。技术介绍不用贪多，每项技术200-300字加上架构图就够。
• 第3章 系统分析：画用例图、E-R图、数据流图，描述功能性需求和非功能性需求。用例图可以拆分为管理员用例、业主用例、维修人员用例。
• 第4章 系统设计：写总体架构图、功能模块设计、数据库设计（核心表结构）、接口设计。这部分和源码的Controller/Service层一一对应。
• 第5章 系统实现：挑4-5个核心功能页面（登录、房产管理、缴费、报修）写实现过程和核心代码片段，注意代码要贴关键方法，不要大段贴Controller。
• 第6章 系统测试：写测试方法、测试用例、测试结果。功能测试表里列出测试步骤、预期结果、实际结果、是否通过。
• 第7章 总结与展望：总结完成的工作，指出不足，展望基于微服务或大数据的扩展。

论文中所有的功能图、流程图、界面截图，直接可以从你正在运行的系统中获取。注意界面上尽量使用真实数据，别用“张三”“李四”的示例数据撑场，至少把小区名字、楼栋号、房号设置得像模像样，答辩时观感好很多。

6. 实际跑通这套系统后的几点经验

我前后调试过不少SpringBoot管理系统源码，包括这套物业系统，总结几条实际经验供你参考：

第一，源码里自带的application.yml永远不要直接用于生产环境。至少要把密码改成强口令，关闭spring.datasource.sql-script-initialize或保证初始化脚本不覆盖正式数据。毕业设计虽然不要求你搞安全攻防，但安全意识是加分项，论文的“系统安全性”小节就能写这个。

第二，文件上传后要防止路径穿越和重名。如果做图片上传，建议用UUID作为文件名，只保留原始文件名作为展示字段。否则用户上传的图片名带了../之类的字符，轻则路径错乱，重则被利用来上传恶意文件。这位同学如果之后想扩展系统，这是必改点。

第三，启动项目前先检查Lombok插件是否安装。很多SpringBoot源码大量使用@Data注解，如果你的IDEA没装Lombok插件，编译会报找不到getter/setter方法。这个错让无数新手浪费两小时，给你先排掉。

第四，不要忽略前端控制台的报错。后端接口即使返回200，前端也可能因为字段名不匹配而渲染不出数据。看到空白页时，按F12打开Network，看接口返回的JSON字段，再和前端el-table的prop对比，绝大多数问题都出在驼峰和下划线命名不一致上。

最后再提一点扩展建议：把这套物业管理系统跑熟之后，试着给它加上一个“小区公告大屏”页面，用轮询或WebSocket实时刷新，配合ECharts展示今日报修量、缴费率、工单完成率。这个扩展既能体现你对前端可视化的能力，又能把后端聚合查询接口用起来，放在答辩演示环节绝对是压轴效果。