1. 厂房租赁系统到底在解决什么问题我接触过不少厂房租赁类项目先说一个行业现状传统的工业地产招商很多还停留在Excel登记房源、微信传合同、手写台账收租的原始阶段。房源空置信息不同步、客户跟进记录丢失、租金应收实收对不上、合同到期没人提醒——这些问题在中小型园区运营方那里太常见了。毕业设计选这个题目技术上能展示的东西很多业务上又有清晰的价值链条是一个能讲出深度、做出亮点的方向。这套系统本质上是一个面向工业地产运营方的信息管理平台核心围绕三件事房源怎么管、客户怎么招、合同租金怎么控。SpringBoot提供后端服务Vue负责前端交互两者结合做出的是一个既能支撑招商业务流转又能管控房源租控状态的系统。很多同学看到“厂房租赁”觉得只是换个皮的CRUD其实不是这里面的业务逻辑、状态流转、权限设计真要做得完整工作量不小也正因为如此它作为毕业设计的选题非常合适。系统的使用者一般分几类招商专员录入线索、跟进客户、发起签约运营主管审核合同、处置退租财务人员管理收款、生成账单园区管理员维护楼栋、房间、收费标准。不同角色看到的功能菜单、数据权限完全不同这就把SpringSecurity或Shiro这类权限框架的运用串起来了。从技术角度看这个题目覆盖了主流Java后端开发的核心内容MVC分层、MyBatis-Plus操作数据库、Redis缓存热点数据、JWT做无状态认证、VueElement UI构建后台界面、ECharts展示租控图和经营报表。这些技术点完全踩在当下企业级应用开发的通用路线上所以做出来的项目不仅是一份毕业设计更是简历上可以站得住脚的项目经验。这篇内容我会按一个完整的系统从设计到落地的顺序把我实际操作中梳理出来的方案、结构和踩过的坑过一遍适合正在做同类型题目的同学参考。2. 技术选型与整体架构设计2.1 为什么是SpringBootVue组合先聊后端。SpringBoot站在当前确实是JavaWeb项目的首选没有之一。它把Spring生态里繁琐的XML配置全部自动化处理内嵌Tomcat让部署变得极其简单——开发机上直接mvn spring-boot:run就能起服务这对毕业设计阶段的调试效率提升是实打实的。另一个关键点是社区资料极其丰富遇到问题一搜就是答案对于以完成项目为首要目标的学生开发者来说这比技术本身“高级不高级”重要得多。前端选Vue理由同样务实。Vue上手曲线相对平缓渐进式框架的设计思路使得项目可以先用Vue Router做路由、Vuex或Pinia做状态管理再配合Element UI这类的组件库后台管理界面很快就能搭起来。我见过不少选择其他框架的组合最后卡在前后端联调阶段的不少而VueSpringBoot这套组合经过大量项目验证前后端交互模式非常成熟几乎不会出现“框架本身折腾人”的情况。这套组合还有一个隐性优势岗位匹配度。SpringBoot和Vue是当前中小型公司技术栈里出现频率最高的两个关键词做完这个项目你写在简历上的技能栈和实际面试官问的东西高度重合。2.2 整体分层架构怎么规划架构上按照经典的分层设计没有过度设计但每一层职责清晰。我画一张项目结构的逻辑图文字描述版前端Vue项目 ├── views (页面组件) │ ├── system (用户/角色/菜单管理) │ ├── house (房源/楼栋/房间管理) │ ├── lease (客户/合同/账单管理) │ ├── operate (报修/访客/巡查管理) │ └── dashboard (数据看板) ├── api (axios接口封装) ├── store (状态管理) └── router (路由与权限守卫) 后端SpringBoot项目 ├── controller (接口层) ├── service (业务层) ├── mapper (数据访问层) ├── entity (实体类) ├── dto (传输对象) ├── config (配置类) └── utils (工具类)这个结构的好处是职责明确、易于并行开发。我在实际做的时候习惯先把entity和mapper层定义好因为这两个决定了数据模型后面的service和controller都围绕它们展开。前端路由的设计要跟后端的菜单权限动态联动——不同角色登录后看到的菜单项不一样这个是在路由守卫里根据用户权限列表动态生成的。数据库层面用MySQL缓存用Redis。Redis在这个项目里的角色不是主力存储而是存放验证码、登录token、房源热度等高频访问数据。MyBatis-Plus作为ORM工具显著减少单表CRUD代码量它的分页插件和条件构造器在处理这类管理系统时非常好用自带的方法省掉了大量XML映射文件这点用过的同学应该深有体会。2.3 开发环境与版本选择版本选型上我给一个稳定且经过验证的组合这套搭配不会出兼容性问题组件版本选择说明JDK1.8 或 11稳定为主不要一味追求新版本SpringBoot2.7.x2.x系列生态最成熟资料最多MyBatis-Plus3.5.x配合SpringBoot2.x使用顺畅MySQL5.7 或 8.08.0功能更新但5.7资料更多Redis6.x缓存和token存储Node.js16.x或18.x对应Vue CLI工具链Vue2.x Element UI或Vue3 Element Plus均可说实话选Vue2还是Vue3我建议看你手头的参考资料。如果学校教程和已有模板基于Vue2果断用Vue2没必要在这里增加学习成本。技术上Vue3响应式机制更好但对毕设来说项目完成度和稳定性才是评分重点我用Vue2 Element UI做这套系统做起来非常顺手。3. 核心数据库设计3.1 厂房租赁业务的表结构规划数据库设计是整个系统的地基这一块我花了两天时间专门梳理。厂房租赁系统的表结构跟普通商城系统差异很大它要同时承载几种业务形态楼盘空间资源管理、客户与招商流程管理、合同履约与财务管理。先看核心表清单这套设计可以支撑后续所有功能的扩展表名用途关键字段building楼栋信息名称、地址、总面积、层数house房源/房间所属楼栋、面积、状态、单价customer客户信息名称、联系方式、需求面积、行业follow_record跟进记录客户ID、跟进内容、下次跟进时间lease_contract租赁合同房源ID、客户ID、起止日期、租金rent_bill租金账单合同ID、周期、应收金额、实收金额payment_record收款记录账单ID、收款方式、收款时间sys_user系统用户用户名、密码、角色sys_role角色表角色编码、角色名称sys_menu菜单权限表菜单名称、路由、权限标识房源表是整个系统的核心资产表。我在设计时house表不单纯存房间号还包含了房源类型整层、独立车间、仓库、建筑面积、使用面积、层高、承重、是否带行车、是否有消防验收等工业地产专属属性。这些字段在后面前端筛选房源时非常有用——招商人员找房源一定是按照客户需求面积、承重、层高这些条件去匹配的设计阶段多花一点心思后面写查询就省力很多。3.2 租控状态字段的设计思路租控这个需求本质是实时掌控每一间厂房的当前状态。我在house表设计了一个status字段用数字表示0空置1锁定已被客户预定2已出租3装修中4维修中。这个状态流程是整个系统的业务骨架我详细说一下流转逻辑房源初始状态为0空置招商人员可以对外推荐客户看房满意、缴纳定金后状态改为1锁定锁定房源不会再被其他客户看到避免重复谈同一间房源合同签订生效后状态改为2已出租租约到期或中途退租状态改回0如果退租后需要翻新维修则先置为3这里面的关键在状态之间不能任意跳转。比如房源已经出租就不可能直接变回空置必须经过退租流程生成退租记录再触发状态变更。我在service层封装了一个专门的状态流转方法所有状态变更都走这个方法并在方法里加上状态校验逻辑不满足流转规则的直接抛出业务异常。这种设计做完之后运营人员在系统里怎么操作都不会把数据搞乱。3.3 合同与账单的关联设计合同表和账单表的关系我单独讲一下。很多同学在这里容易犯一个错误在合同表里直接记录租金金额然后就没有然后了收款情况要么不做要么零散记录在备注里。这种设计做出来的系统财务人员根本没法用。正确的做法是把合同和账单拆分lease_contract记录合同的核心条款租期、月租金、押金、递增规则rent_bill则按计费周期生成各期的应收记录。合同签订后系统根据起止日期自动生成所有期的账单每期账单有独立的应收日期、应收金额、收款状态。这样财务打开账单列表一眼就能看到哪些费用已收、哪些即将到期、哪些已经逾期催收工作变成了一个查询操作。计费规则的灵活性也要考虑。我在lease_contract里设计了rent_type字段区分固定租金和递增租金递增方式用increase_rate年递增比例和increase_cycle递增周期两个字段表达。计算账单时如果类型是递增先算出当前账单所属年份的租金标准再乘以周期月数。这套逻辑说不上复杂但很贴近真实厂房租赁的商务惯例——工业地产的租约一般3到5年几乎都会约定租金递增条款不做这部分答辩时评委一问就会露怯。4. 前后端接口设计与权限体系4.1 RESTful接口规范接口设计上我推荐全员统一RESTful风格这对前后端联调阶段的效率提升至关重要。具体规范按资源名HTTP方法组合操作HTTP方法接口路径分页查询房源GET/api/house/page新增房源POST/api/house修改房源PUT/api/house删除房源DELETE/api/house/{id}获取租控图数据GET/api/dashboard/tenancy生成租金账单POST/api/contract/generateBill客户跟进记录GET/api/customer/follow/{customerId}统一的返回格式也很关键。项目里我封装了一个Result类包含code、message、data三个字段所有接口统一返回这个结构。前端axios封装里再统一做拦截code为200时直接返回datacode为401时跳转登录页code为500时弹出错误提示并携带后端message。这样一来前端每个请求的处理逻辑大幅简化不会出现接口风格混乱、异常信息无处展示的问题。这里有一个很实用的习惯写接口前先跟前端约定好JSON字段名不要用后端java命名习惯驼峰前端也保持一致风格统一的camelCase就好。很多前后端联调浪费时间的问题根源就是字段不一致或时区不对导致的时间显示异常提前约定能避免大量返工。4.2 SpringSecurityJWT权限控制方案权限控制是这类管理系统的标配功能也是答辩时老师关注的重点之一。系统涉及招商、运营、财务三种角色必须做到登录后才能访问接口、不同角色只能看权限范围内的功能。我采用的方案是SpringSecurity JWT。整体认证流程是用户提交用户名密码后端校验通过后生成JWT token返回前端前端将token存储在localStorage并在axios请求拦截器里加到请求头Authorization: Bearer token后端通过SpringSecurity过滤器链解析JWT将用户信息和权限列表放入安全上下文之后每次请求SpringSecurity根据接口要求的权限标识判断是否有权访问实现细节上用户名密码加密用BCrypt。这里提醒一下不要用MD5明文加密BCrypt是SpringSecurity内置的专门用于密码哈希每次加密自动加盐安全性高一个量级。注册用户时new BCryptPasswordEncoder().encode(password)一键搞定验收人员只会问“你为什么要用BCrypt”——答案就是防彩虹表破解一句话就能展示你的安全意识。权限控制做到方法级。后端在每个Controller的接口方法上标注PreAuthorize(hasAuthority(lease:contract:add))这类注解权限标识在sys_menu表里维护。前端再配合Vue Router的路由守卫在路由meta中声明需要的权限标识路由跳转前检查用户权限列表无权限直接重定向到403页面。前后端双重校验既能提升用户体验没权限的菜单根本看不到又能保证接口安全绕过前端直接调接口也会被拦截。4.3 验证码与登录安全细节登录模块我加了图片验证码功能Kaptcha生成图片验证码内容存Redis并设置5分钟过期。这里有一个隐藏考点验证码为什么要存Redis而不是直接放Session因为多节点部署时Session不共享而Redis天然支持跨节点共享。这一句话在答辩时就能体现你对分布式场景的认知。实际上毕设项目单机部署用Session也没问题但用Redis是更好的工程习惯。登录接口本身要做防刷设计。我在实践中加入了一个简单有效的策略同一个IP在1分钟内密码错误超过5次锁定该IP的登录请求15分钟。实现方式很直接用Redis计数key为login:fail:ip:xxx每次失败加1超过阈值就返回“尝试次数过多请稍后再试”。不要小看这个细节它属于真实生产环境需要考虑的安全措施写进项目里会让系统完整度上了一个台阶。5. 招商管理与租控一体化实现5.1 招商线索到签约的完整业务链路招商管理体系是整个系统的业务灵魂也是你在答辩时最能讲出业务深度的部分。厂房租赁不同于住宅租赁它的客户是生产企业决策周期长、需求表达式鲜明、跟进次数多所以系统必须对客户全生命周期做管理。招商链路我拆成四个阶段线索阶段招商专员通过线上推广、中介合作、老客户转介绍等渠道获取客户信息录入customer表系统记录来源渠道网络推广、中介、转介绍等。这个字段很有用运营一段时间后按渠道统计转化率能看出哪个渠道来的客户质量最高对园区招商策略的调整有直接的指导价值。跟进阶段招商人员对客户进行电话沟通、现场带看。每次沟通都要在系统里记录follow_record包括沟通内容、客户意向等级高/中/低、下次跟进时间。系统今日待办提醒功能就是查follow_record中next_follow_time为目标日期且未完成的记录。这个功能虽然实现简单但对招商人员的日常工作效率提升非常明显。锁定阶段客户看中某间房源并缴纳定金后该房源状态变为“锁定”同时关联客户信息。锁定状态的房源在招商列表中会被标记为“已锁定”但仍然可以看到基本信息便于主管判断哪些房源是热门房源、需要加快推动签约进度。签约阶段双方合同条款谈妥后运营主管录入合同信息。合同审批流程简化为一二级审核——招商经理初审、运营总监终审。审核通过后合同生效房源状态自动改为“已出租”同时根据合同起止日期自动生成租金账单。这个流程走通之后整个系统的主体业务就串起来了从房态管理、招商过程、合同履约到财务收款形成了一条完整闭环。5.2 租控图的数据可视化租控图是智慧园区系统的标配展示功能用可视化的方式把园区楼栋和房源的状态直观展现在一张图上运营管理者不用一个个查房间打开首页就能对园区的出租情况一目了然。我的实现思路是前端用一个纵向层显结构表示楼栋——每一层横向排列该层的所有房源格子每个格子的颜色对应房源状态绿色已出租黄色锁定红色空置灰色维修中。这个视图不仅直观而且交互上可以直接点击某个房源格子弹出该房源详情和关联合同信息招商人员在汇报工作时直接截图这个页面比Excel表有说服力得多。后端接口设计为/api/dashboard/tenancy返回数据格式是一个树形结构{ buildingName: A区1栋, floors: [ { floorNo: 1, houses: [ {houseId: 101, area: 1200, status: 2, customerName: 某科技公司}, {houseId: 102, area: 800, status: 0, customerName: null} ] } ] }前端拿到数据后ECharts的自定义图表custom series或者简单的CSS Grid布局都能实现。如果不想引入ECharts纯Vue的v-for渲染加颜色class绑定也能实现效果差别不大。核心是让状态信息一目了然操作入口顺手可及。5.3 待办提醒与到期预警机制一个成熟的运营系统必须有主动推送信息的能力而不是被动的查询工具。我在系统里设计了一套基于时间维度的待办预警机制这部分看起来是细节但实际使用中好评度最高。具体实现三类预警合同到期预警合同到期前90天、60天、30天分别生成预警记录提醒运营人员联系客户确认续约还是退租。实现方式是在系统启动后跑一个定时任务Scheduled注解扫描合同表和预警记录表当前日期落在预警区间且尚未生成过预警记录的自动插入一条预警消息。租金逾期提醒rent_bill中收款状态为未收且应收日期已过系统自动标记为“逾期”在首页看板和财务工作台按逾期天数排序展示。财务人员每天上班打开工作台先看逾期账单列表直接联系催收这个流程简洁实用。跟进超时提醒客户跟进计划的next_follow_time超过3天仍无新跟进记录系统提醒招商主管关注防止客户资源因跟进不及时而流失。定时任务加上简单的消息表含类型、内容、关联业务ID、是否已读就能构建一个完整的站内消息通知能力。登录后前端通过定时轮询接口每30秒一次拉取未读消息数在顶部导航栏做红点提示。这一套实现了之后系统就不再是一个简单的信息记录工具而是一个有主动服务能力的业务平台。6. 合同与财务管理模块细节6.1 合同管理中容易忽视的业务细节合同表如果只是记录“哪个客户租了哪间房、每月多少钱”那确实太单薄了。厂房租赁合同的实际业务远比这个复杂我在做的时候注意了下面几个细节每一个都对应真实的业务场景。押金管理工业厂房通常收取3个月租金作为押金部分优质客户可谈2个月。押金不是收入是负债需要在合同表单独记录deposit_amount和deposit_status未收/已收/已退还。合同退租时押金用于抵扣欠费或房屋损坏赔偿余额退还客户。很多粗制滥造的系统直接把押金当成租金一次性收取入账这个从财务角度是错账说出来会被答辩老师一句“押金怎么处理的”问住。租金递增这个问题我在前面数据库设计里提过这里放一个具体的计算示例。假设合同约定月租金2万元租金每年递增5%租期3年。第一年每月账单为20000元第二年每月的租金标准变为20000×1.0521000元第三年变为21000×1.0522050元。账单生成时根据当前账单月份所在年份计算当月租金标准。这里要处理好分界的逻辑以合同起始月为第一年起点而不是自然年。提前退租违约金合同表里记录break_penalty违约金规则通常为1-2个月租金。在退租审批流程中系统根据合同剩余期限自动计算应扣违约金并生成退款或补扣账单。这部分在退租功能中容易漏但一漏就显得业务脱离实际。6.2 账单生成与收款的闭环逻辑账单与收款做成了一个闭环每一步状态都有明确流转关系生成账单(应收) → 收款登记(部分/全额) → 自动核销 → 账单完成/剩余待收具体逻辑是合同生效时自动批量生成该合同整个租期内的所有账单这个操作在service层循环插入合同周期内按月生成。账单表状态有三种待收款、部分收款、已收款、已关闭作废。每登记一笔收款记录系统先判断该笔收款对应哪个账单再更新账单的累计实收金额如果实收金额等于应收金额则账单状态变为已收款。有一点要特别注意不要允许直接删除收款记录。真实财务场景中如果某笔收款录错了需要走“冲正”流程——新增一笔负数金额的收款记录将原记录和冲正记录关联标记。这样做的原因是财务数据需要保留完整的审计轨迹。虽然毕设项目可以简化但我在系统里实现了撤销逻辑标记作废而非物理删除这个处理方式能体现你在设计时考虑了真实的财务规则。6.3 看板报表的设计要点首页看板我放了以下几块内容核心指标卡片可出租总面积、已出租面积、出租率、本月应收租金、本月实收租金、本月招商标的新增客户数/带看次数/签约合同数。这些指标用一个SQL查询统计出来前端用统计卡片组件展示。租控趋势图用折线图展示近6个月的出租率变化趋势。出租率的计算方式是当前已出租面积 / 可出租总面积。趋势图用ECharts的折线图实现后端接口返回每个月末的出租率数据。到期分布图柱状图展示未来6个月每月到期合同数量和涉及面积。这张图对运营决策很重要——下个月如果有大片面积到期招商团队需要提前准备替代客户财务需要提前预估租金收入波动。数据报表这一块看起来很常规但实际使用中价值很高。运营总监每天早上打开系统不是为了操作业务就是为了看这些数字的变动。系统好不好用很大程度上取决于这个页面做得好不好。7. 核心功能实现要点与代码架构7.1 分页查询与条件检索的后端实现管理系统后端开发中分页查询是所有页面都要用到的底层能力。我用MyBatis-Plus的Page和LambdaQueryWrapper实现了一套统一的分页查询模式说几个具体要点。第一步前端请求参数约定。每一页的查询参数封装成一个Query对象包括pageNum、pageSize和各自的查询条件字段。后端接收后用LambdaQueryWrapper构建动态条件比如public PageResultHouseVO queryHousePage(HouseQuery query) { LambdaQueryWrapperHouse wrapper new LambdaQueryWrapper(); wrapper.eq(StringUtils.isNotBlank(query.getBuildingName()), House::getBuildingName, query.getBuildingName()); wrapper.eq(query.getStatus() ! null, House::getStatus, query.getStatus()); wrapper.like(StringUtils.isNotBlank(query.getKeyword()), House::getHouseNo, query.getKeyword()); wrapper.ge(query.getMinArea() ! null, House::getArea, query.getMinArea()); wrapper.le(query.getMaxArea() ! null, House::getArea, query.getMaxArea()); wrapper.orderByDesc(House::getCreateTime); // 分页查询 }这里的关键在LambdaQueryWrapper的条件参数写法——第一个参数是布尔条件条件为true时才会拼接该查询条件为空或null时自动忽略。这套写法不仅避免了大量if判断拼接SQL而且完全不存在SQL注入风险——MyBatis-Plus条件构造器内部使用预编译参数。答辩老师问“你怎么防止SQL注入的”你就可以回答“使用预编译框架的条件构造器参数值全部预编译绑定”这是标准答案。7.2 房源状态流转的Service实现状态流转是我重点设计的业务逻辑也分享下这份代码思路。单独写一个HouseStatusService提供状态变更的原子操作public void changeHouseStatus(Long houseId, Integer fromStatus, Integer toStatus, String operator) { House house houseMapper.selectById(houseId); if (house null) { throw new BusinessException(房源不存在); } if (!house.getStatus().equals(fromStatus)) { throw new BusinessException(当前房源状态已变更请刷新后重试); } // 状态流转合法性校验 boolean isValid validStatusTransition(house.getStatus(), toStatus); if (!isValid) { throw new BusinessException(非法状态流转: house.getStatus() - toStatus); } // 并发控制 - 乐观锁 house.setStatus(toStatus); houseMapper.updateById(house); }这里有个并发安全问题值得展开两个招商人员同时看中同一间空置房源都进行锁定操作如果不上锁两人都会读到状态为0的房源并各自更新为锁定导致同一间房被两个客户锁定数据出现脏写。我的解决方案是乐观锁house表加一个version字段更新时的SQL语句带上版本条件where id? and versionoldVersion。MyBatis-Plus支持Version注解开启乐观锁插件后updateById方法会自动带上版本条件更新成功则版本号加1。第二个操作者更新时因为版本号已经不匹配影响行数为0系统捕获到后提示“操作冲突请刷新重试”。这个设计体现了典型的并发控制意识属于加分的细节。7.3 Vue前端页面与接口联调实践前端实现上我以租控看板页面举例讲一下Vue的基本套路。Element UI的el-dialog、el-table、el-form、el-tabs几个组件组合就能解决几乎所有管理页面的UI需求。一个典型的列表页基本结构是顶部搜索条件区el-form的inline模式、中部操作按钮区新增、批量删除、导出、底部表格区el-table加分页组件el-pagination。监听条件变化重新加载数据这个在方法里统一处理// 获取列表数据的统一方法 async function fetchList() { const params { pageNum: pageNum.value, pageSize: pageSize.value, buildingName: queryForm.buildingName, status: queryForm.status } const res await listHouseApi(params) tableData.value res.data.records total.value res.data.total }前后端联调最容易踩的坑是跨域配置。开发阶段后端配置跨域可以让调试顺畅很多我用一个CorsFilter把常用的请求头都放开前端axios的baseURL设置为http://localhost:8080/api开发时直接访问后端服务。生产部署后因为前后端用Nginx做反向代理同源部署就没有跨域问题了。联调阶段我还有一个习惯分享所有接口先写后端文档再动手写前端页面。接口文档不用额外工具生成直接在Controller注释里写清楚入参出参含义即可。前后端约定好之后可以并行推进最后联调阶段通过Swagger-ui或直接在浏览器里请求接口做验证大量减少沟通成本。8. 系统部署与常见问题排查8.1 本地环境完整部署流程整个系统在本地跑起来我整理一份经过验证的具体部署步骤照着做基本不会出问题。后端启动步骤本地安装JDK 1.8、Maven 3.6、MySQL 5.7、Redis 6.xMySQL中执行项目提供的init.sql脚本创建数据库表和初始数据管理员账号、基础菜单权限、测试房源数据修改application.yml配置文件将数据库连接地址、用户名、密码、Redis连接信息改为本机配置Maven执行mvn clean package -DskipTests后端打为jar包命令行执行java -jar factory-lease-system.jar启动服务看到“Started”日志即启动成功前端启动步骤安装Node.js然后在Vue项目目录执行npm install推荐用npm install --registryhttps://registry.npmmirror.com国内镜像加速执行npm run dev启动开发服务器浏览器访问http://localhost:8080即进入系统登录页首次登录用初始化的管理员账号进入系统后先配置楼栋、房源数据再创建部门的用户角色分配权限菜单。这里有几个部署时常见的端口问题后端默认端口改一下很有必要因为8080端口在开发环境经常被占用。我在application.yml里把服务端口设置为8088前端vue.config.js中devServer的proxy代理目标同步改成http://localhost:8088这样一个环境变量适配所有接口请求换环境部署只需要改这一处。8.2 高频报错与规避方案做这套系统的过程中有几类报错频率极高我这里整理成速查表都是实际踩过的报错现象根本原因解决方案前端请求接口返回404跨域未配置或接口路径错误后端配置CorsFilter前端确认baseURL和接口路径一致启动报DataSource错误数据库连接配置不对核对url、username、password确认MySQL服务已启动JWT认证401token过期或请求头未携带前端axios拦截器携带token后端配置token过期时间中文乱码数据库字符集不是utf8mb4建库时指定DEFAULT CHARACTER SET utf8mb4MyBatis-Plus分页不生效缺少分页插件配置添加PaginationInnerInterceptor配置类npm install卡住网络问题切换npmmirror镜像源其中中文乱码是最常见也最好解决的。MySQL安装时的默认字符集可能不是utf8mb4建库时我习惯一条命令写清楚CREATE DATABASE factory_lease DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;另外后端application.yml里加上characterEncodingutf8连接参数双保险。这个问题如果建库时处理好后面全都顺风顺水否则每张表都要手工调整字符集那滋味谁做谁懂。8.3 演示环境准备与答辩常被追问的问题最后把答辩阶段的经验也分享一下这不涉及技术实现但和项目完整度直接相关。演示数据的质量直接决定系统演示效果。我建议准备一套干净、专业的模拟数据比如3栋楼、每栋4层、每层3-5间房源房源状态做好分布部分出租、部分空置、个别锁定客户数据准备8-10条并且有不同跟进阶段合同数据准备几份包括一份即将到期的和一份已经逾期的。这样演示时可以很自然地展示所有核心功能不用现场临时造数那种临时编数据演示的体验谁试过谁知道有多尴尬。答辩时老师针对这套系统最常追问的集中在几个点为什么是MyBatis-Plus而不是MyBatis或JPA回答要点MyBatis-Plus兼容MyBatis生态单表操作免写XML复杂查询仍然可以手写SQL学习成本低JPA自动生成SQL对复杂条件查询支持弱且自动生成的SQL性能不可控。Redis在这里到底承担什么角色回答要点验证码存储、登录token的分布式会话管理、房源热度缓存。进一步可以讲如果热点房源每次都被点击查看详情每次都查数据库数据库压力大用Redis做缓存可以有效降低数据库查询压力。如果要在生产环境部署还要做哪些加固回答要点数据库开启备份策略、Nginx配置HTTPS、日志接入监控系统、接口增加操作审计日志、生产环境禁止开放Swagger文档。有这份思考说明你不只是实现了功能而是具有生产环境的工程意识。9. 系统扩展方向与个人实操体会核心功能做完之后如果你还有余力有几条扩展路径值得考虑它们能让这个毕设从“完成”走向“优秀”。小程序端目前的后台系统是面向运营人员的客户端的线上找房、预约看房功能可以通过微信小程序实现。后端只需增加一组面向C端的接口查询房源列表按需求面积筛选。这个扩展能展示你对多端业务的理解而且小程序是当前企业数字化标配答辩时加分明显。消息推送站内消息目前依赖前端轮询可以扩展接入微信公众号模板消息或者短信服务合同到期提醒直接推送到运营人员的手机上业务响应速度更快。这个扩展只要抽象出一个消息发送接口预留短信实现和微信实现两个子类就行设计模式里的策略模式正好用上。大数据分析系统运行一段时间后积累的招商数据渠道来源、带看转化率、成交周期、租金价格走势可以做多维分析。后端用定时任务对数据进行统计汇总前端用ECharts绘制漏斗图线索→带看→签约和热力图不同区域房源的出租热度这些分析结果能直接支持园区运营决策是系统价值的进一步延伸。我在实际做这套系统的过程中最深的体会是毕业设计的技术深度不是看用了多少技术栈而是看你对业务逻辑的理解有多到位对细节的处理有多严谨。厂房租赁系统的表面是增删改查但里面隐藏着房源状态机、合同期与账单的联动、权限角色的数据隔离、并发锁控制这些真正考验设计能力的地方。把这些想清楚、做扎实答辩时每一处设计都能讲出为什么这么做、解决了什么问题这套系统的含金量自然会体现出来。如果你现在正在做这个题目我的建议是优先把核心业务闭环走通——招商线索到合同签约、房源状态流转、账单生成收款这几条主线做完整系统的主体就立住了然后再去补充管理端、看板和扩展功能。做完一个完整可用的系统也确实弄懂了每个模块为什么这么设计这份收获比辛苦调三天页面样式值得多。
1. 厂房租赁系统到底在解决什么问题我接触过不少厂房租赁类项目先说一个行业现状传统的工业地产招商很多还停留在Excel登记房源、微信传合同、手写台账收租的原始阶段。房源空置信息不同步、客户跟进记录丢失、租金应收实收对不上、合同到期没人提醒——这些问题在中小型园区运营方那里太常见了。毕业设计选这个题目技术上能展示的东西很多业务上又有清晰的价值链条是一个能讲出深度、做出亮点的方向。这套系统本质上是一个面向工业地产运营方的信息管理平台核心围绕三件事房源怎么管、客户怎么招、合同租金怎么控。SpringBoot提供后端服务Vue负责前端交互两者结合做出的是一个既能支撑招商业务流转又能管控房源租控状态的系统。很多同学看到“厂房租赁”觉得只是换个皮的CRUD其实不是这里面的业务逻辑、状态流转、权限设计真要做得完整工作量不小也正因为如此它作为毕业设计的选题非常合适。系统的使用者一般分几类招商专员录入线索、跟进客户、发起签约运营主管审核合同、处置退租财务人员管理收款、生成账单园区管理员维护楼栋、房间、收费标准。不同角色看到的功能菜单、数据权限完全不同这就把SpringSecurity或Shiro这类权限框架的运用串起来了。从技术角度看这个题目覆盖了主流Java后端开发的核心内容MVC分层、MyBatis-Plus操作数据库、Redis缓存热点数据、JWT做无状态认证、VueElement UI构建后台界面、ECharts展示租控图和经营报表。这些技术点完全踩在当下企业级应用开发的通用路线上所以做出来的项目不仅是一份毕业设计更是简历上可以站得住脚的项目经验。这篇内容我会按一个完整的系统从设计到落地的顺序把我实际操作中梳理出来的方案、结构和踩过的坑过一遍适合正在做同类型题目的同学参考。2. 技术选型与整体架构设计2.1 为什么是SpringBootVue组合先聊后端。SpringBoot站在当前确实是JavaWeb项目的首选没有之一。它把Spring生态里繁琐的XML配置全部自动化处理内嵌Tomcat让部署变得极其简单——开发机上直接mvn spring-boot:run就能起服务这对毕业设计阶段的调试效率提升是实打实的。另一个关键点是社区资料极其丰富遇到问题一搜就是答案对于以完成项目为首要目标的学生开发者来说这比技术本身“高级不高级”重要得多。前端选Vue理由同样务实。Vue上手曲线相对平缓渐进式框架的设计思路使得项目可以先用Vue Router做路由、Vuex或Pinia做状态管理再配合Element UI这类的组件库后台管理界面很快就能搭起来。我见过不少选择其他框架的组合最后卡在前后端联调阶段的不少而VueSpringBoot这套组合经过大量项目验证前后端交互模式非常成熟几乎不会出现“框架本身折腾人”的情况。这套组合还有一个隐性优势岗位匹配度。SpringBoot和Vue是当前中小型公司技术栈里出现频率最高的两个关键词做完这个项目你写在简历上的技能栈和实际面试官问的东西高度重合。2.2 整体分层架构怎么规划架构上按照经典的分层设计没有过度设计但每一层职责清晰。我画一张项目结构的逻辑图文字描述版前端Vue项目 ├── views (页面组件) │ ├── system (用户/角色/菜单管理) │ ├── house (房源/楼栋/房间管理) │ ├── lease (客户/合同/账单管理) │ ├── operate (报修/访客/巡查管理) │ └── dashboard (数据看板) ├── api (axios接口封装) ├── store (状态管理) └── router (路由与权限守卫) 后端SpringBoot项目 ├── controller (接口层) ├── service (业务层) ├── mapper (数据访问层) ├── entity (实体类) ├── dto (传输对象) ├── config (配置类) └── utils (工具类)这个结构的好处是职责明确、易于并行开发。我在实际做的时候习惯先把entity和mapper层定义好因为这两个决定了数据模型后面的service和controller都围绕它们展开。前端路由的设计要跟后端的菜单权限动态联动——不同角色登录后看到的菜单项不一样这个是在路由守卫里根据用户权限列表动态生成的。数据库层面用MySQL缓存用Redis。Redis在这个项目里的角色不是主力存储而是存放验证码、登录token、房源热度等高频访问数据。MyBatis-Plus作为ORM工具显著减少单表CRUD代码量它的分页插件和条件构造器在处理这类管理系统时非常好用自带的方法省掉了大量XML映射文件这点用过的同学应该深有体会。2.3 开发环境与版本选择版本选型上我给一个稳定且经过验证的组合这套搭配不会出兼容性问题组件版本选择说明JDK1.8 或 11稳定为主不要一味追求新版本SpringBoot2.7.x2.x系列生态最成熟资料最多MyBatis-Plus3.5.x配合SpringBoot2.x使用顺畅MySQL5.7 或 8.08.0功能更新但5.7资料更多Redis6.x缓存和token存储Node.js16.x或18.x对应Vue CLI工具链Vue2.x Element UI或Vue3 Element Plus均可说实话选Vue2还是Vue3我建议看你手头的参考资料。如果学校教程和已有模板基于Vue2果断用Vue2没必要在这里增加学习成本。技术上Vue3响应式机制更好但对毕设来说项目完成度和稳定性才是评分重点我用Vue2 Element UI做这套系统做起来非常顺手。3. 核心数据库设计3.1 厂房租赁业务的表结构规划数据库设计是整个系统的地基这一块我花了两天时间专门梳理。厂房租赁系统的表结构跟普通商城系统差异很大它要同时承载几种业务形态楼盘空间资源管理、客户与招商流程管理、合同履约与财务管理。先看核心表清单这套设计可以支撑后续所有功能的扩展表名用途关键字段building楼栋信息名称、地址、总面积、层数house房源/房间所属楼栋、面积、状态、单价customer客户信息名称、联系方式、需求面积、行业follow_record跟进记录客户ID、跟进内容、下次跟进时间lease_contract租赁合同房源ID、客户ID、起止日期、租金rent_bill租金账单合同ID、周期、应收金额、实收金额payment_record收款记录账单ID、收款方式、收款时间sys_user系统用户用户名、密码、角色sys_role角色表角色编码、角色名称sys_menu菜单权限表菜单名称、路由、权限标识房源表是整个系统的核心资产表。我在设计时house表不单纯存房间号还包含了房源类型整层、独立车间、仓库、建筑面积、使用面积、层高、承重、是否带行车、是否有消防验收等工业地产专属属性。这些字段在后面前端筛选房源时非常有用——招商人员找房源一定是按照客户需求面积、承重、层高这些条件去匹配的设计阶段多花一点心思后面写查询就省力很多。3.2 租控状态字段的设计思路租控这个需求本质是实时掌控每一间厂房的当前状态。我在house表设计了一个status字段用数字表示0空置1锁定已被客户预定2已出租3装修中4维修中。这个状态流程是整个系统的业务骨架我详细说一下流转逻辑房源初始状态为0空置招商人员可以对外推荐客户看房满意、缴纳定金后状态改为1锁定锁定房源不会再被其他客户看到避免重复谈同一间房源合同签订生效后状态改为2已出租租约到期或中途退租状态改回0如果退租后需要翻新维修则先置为3这里面的关键在状态之间不能任意跳转。比如房源已经出租就不可能直接变回空置必须经过退租流程生成退租记录再触发状态变更。我在service层封装了一个专门的状态流转方法所有状态变更都走这个方法并在方法里加上状态校验逻辑不满足流转规则的直接抛出业务异常。这种设计做完之后运营人员在系统里怎么操作都不会把数据搞乱。3.3 合同与账单的关联设计合同表和账单表的关系我单独讲一下。很多同学在这里容易犯一个错误在合同表里直接记录租金金额然后就没有然后了收款情况要么不做要么零散记录在备注里。这种设计做出来的系统财务人员根本没法用。正确的做法是把合同和账单拆分lease_contract记录合同的核心条款租期、月租金、押金、递增规则rent_bill则按计费周期生成各期的应收记录。合同签订后系统根据起止日期自动生成所有期的账单每期账单有独立的应收日期、应收金额、收款状态。这样财务打开账单列表一眼就能看到哪些费用已收、哪些即将到期、哪些已经逾期催收工作变成了一个查询操作。计费规则的灵活性也要考虑。我在lease_contract里设计了rent_type字段区分固定租金和递增租金递增方式用increase_rate年递增比例和increase_cycle递增周期两个字段表达。计算账单时如果类型是递增先算出当前账单所属年份的租金标准再乘以周期月数。这套逻辑说不上复杂但很贴近真实厂房租赁的商务惯例——工业地产的租约一般3到5年几乎都会约定租金递增条款不做这部分答辩时评委一问就会露怯。4. 前后端接口设计与权限体系4.1 RESTful接口规范接口设计上我推荐全员统一RESTful风格这对前后端联调阶段的效率提升至关重要。具体规范按资源名HTTP方法组合操作HTTP方法接口路径分页查询房源GET/api/house/page新增房源POST/api/house修改房源PUT/api/house删除房源DELETE/api/house/{id}获取租控图数据GET/api/dashboard/tenancy生成租金账单POST/api/contract/generateBill客户跟进记录GET/api/customer/follow/{customerId}统一的返回格式也很关键。项目里我封装了一个Result类包含code、message、data三个字段所有接口统一返回这个结构。前端axios封装里再统一做拦截code为200时直接返回datacode为401时跳转登录页code为500时弹出错误提示并携带后端message。这样一来前端每个请求的处理逻辑大幅简化不会出现接口风格混乱、异常信息无处展示的问题。这里有一个很实用的习惯写接口前先跟前端约定好JSON字段名不要用后端java命名习惯驼峰前端也保持一致风格统一的camelCase就好。很多前后端联调浪费时间的问题根源就是字段不一致或时区不对导致的时间显示异常提前约定能避免大量返工。4.2 SpringSecurityJWT权限控制方案权限控制是这类管理系统的标配功能也是答辩时老师关注的重点之一。系统涉及招商、运营、财务三种角色必须做到登录后才能访问接口、不同角色只能看权限范围内的功能。我采用的方案是SpringSecurity JWT。整体认证流程是用户提交用户名密码后端校验通过后生成JWT token返回前端前端将token存储在localStorage并在axios请求拦截器里加到请求头Authorization: Bearer token后端通过SpringSecurity过滤器链解析JWT将用户信息和权限列表放入安全上下文之后每次请求SpringSecurity根据接口要求的权限标识判断是否有权访问实现细节上用户名密码加密用BCrypt。这里提醒一下不要用MD5明文加密BCrypt是SpringSecurity内置的专门用于密码哈希每次加密自动加盐安全性高一个量级。注册用户时new BCryptPasswordEncoder().encode(password)一键搞定验收人员只会问“你为什么要用BCrypt”——答案就是防彩虹表破解一句话就能展示你的安全意识。权限控制做到方法级。后端在每个Controller的接口方法上标注PreAuthorize(hasAuthority(lease:contract:add))这类注解权限标识在sys_menu表里维护。前端再配合Vue Router的路由守卫在路由meta中声明需要的权限标识路由跳转前检查用户权限列表无权限直接重定向到403页面。前后端双重校验既能提升用户体验没权限的菜单根本看不到又能保证接口安全绕过前端直接调接口也会被拦截。4.3 验证码与登录安全细节登录模块我加了图片验证码功能Kaptcha生成图片验证码内容存Redis并设置5分钟过期。这里有一个隐藏考点验证码为什么要存Redis而不是直接放Session因为多节点部署时Session不共享而Redis天然支持跨节点共享。这一句话在答辩时就能体现你对分布式场景的认知。实际上毕设项目单机部署用Session也没问题但用Redis是更好的工程习惯。登录接口本身要做防刷设计。我在实践中加入了一个简单有效的策略同一个IP在1分钟内密码错误超过5次锁定该IP的登录请求15分钟。实现方式很直接用Redis计数key为login:fail:ip:xxx每次失败加1超过阈值就返回“尝试次数过多请稍后再试”。不要小看这个细节它属于真实生产环境需要考虑的安全措施写进项目里会让系统完整度上了一个台阶。5. 招商管理与租控一体化实现5.1 招商线索到签约的完整业务链路招商管理体系是整个系统的业务灵魂也是你在答辩时最能讲出业务深度的部分。厂房租赁不同于住宅租赁它的客户是生产企业决策周期长、需求表达式鲜明、跟进次数多所以系统必须对客户全生命周期做管理。招商链路我拆成四个阶段线索阶段招商专员通过线上推广、中介合作、老客户转介绍等渠道获取客户信息录入customer表系统记录来源渠道网络推广、中介、转介绍等。这个字段很有用运营一段时间后按渠道统计转化率能看出哪个渠道来的客户质量最高对园区招商策略的调整有直接的指导价值。跟进阶段招商人员对客户进行电话沟通、现场带看。每次沟通都要在系统里记录follow_record包括沟通内容、客户意向等级高/中/低、下次跟进时间。系统今日待办提醒功能就是查follow_record中next_follow_time为目标日期且未完成的记录。这个功能虽然实现简单但对招商人员的日常工作效率提升非常明显。锁定阶段客户看中某间房源并缴纳定金后该房源状态变为“锁定”同时关联客户信息。锁定状态的房源在招商列表中会被标记为“已锁定”但仍然可以看到基本信息便于主管判断哪些房源是热门房源、需要加快推动签约进度。签约阶段双方合同条款谈妥后运营主管录入合同信息。合同审批流程简化为一二级审核——招商经理初审、运营总监终审。审核通过后合同生效房源状态自动改为“已出租”同时根据合同起止日期自动生成租金账单。这个流程走通之后整个系统的主体业务就串起来了从房态管理、招商过程、合同履约到财务收款形成了一条完整闭环。5.2 租控图的数据可视化租控图是智慧园区系统的标配展示功能用可视化的方式把园区楼栋和房源的状态直观展现在一张图上运营管理者不用一个个查房间打开首页就能对园区的出租情况一目了然。我的实现思路是前端用一个纵向层显结构表示楼栋——每一层横向排列该层的所有房源格子每个格子的颜色对应房源状态绿色已出租黄色锁定红色空置灰色维修中。这个视图不仅直观而且交互上可以直接点击某个房源格子弹出该房源详情和关联合同信息招商人员在汇报工作时直接截图这个页面比Excel表有说服力得多。后端接口设计为/api/dashboard/tenancy返回数据格式是一个树形结构{ buildingName: A区1栋, floors: [ { floorNo: 1, houses: [ {houseId: 101, area: 1200, status: 2, customerName: 某科技公司}, {houseId: 102, area: 800, status: 0, customerName: null} ] } ] }前端拿到数据后ECharts的自定义图表custom series或者简单的CSS Grid布局都能实现。如果不想引入ECharts纯Vue的v-for渲染加颜色class绑定也能实现效果差别不大。核心是让状态信息一目了然操作入口顺手可及。5.3 待办提醒与到期预警机制一个成熟的运营系统必须有主动推送信息的能力而不是被动的查询工具。我在系统里设计了一套基于时间维度的待办预警机制这部分看起来是细节但实际使用中好评度最高。具体实现三类预警合同到期预警合同到期前90天、60天、30天分别生成预警记录提醒运营人员联系客户确认续约还是退租。实现方式是在系统启动后跑一个定时任务Scheduled注解扫描合同表和预警记录表当前日期落在预警区间且尚未生成过预警记录的自动插入一条预警消息。租金逾期提醒rent_bill中收款状态为未收且应收日期已过系统自动标记为“逾期”在首页看板和财务工作台按逾期天数排序展示。财务人员每天上班打开工作台先看逾期账单列表直接联系催收这个流程简洁实用。跟进超时提醒客户跟进计划的next_follow_time超过3天仍无新跟进记录系统提醒招商主管关注防止客户资源因跟进不及时而流失。定时任务加上简单的消息表含类型、内容、关联业务ID、是否已读就能构建一个完整的站内消息通知能力。登录后前端通过定时轮询接口每30秒一次拉取未读消息数在顶部导航栏做红点提示。这一套实现了之后系统就不再是一个简单的信息记录工具而是一个有主动服务能力的业务平台。6. 合同与财务管理模块细节6.1 合同管理中容易忽视的业务细节合同表如果只是记录“哪个客户租了哪间房、每月多少钱”那确实太单薄了。厂房租赁合同的实际业务远比这个复杂我在做的时候注意了下面几个细节每一个都对应真实的业务场景。押金管理工业厂房通常收取3个月租金作为押金部分优质客户可谈2个月。押金不是收入是负债需要在合同表单独记录deposit_amount和deposit_status未收/已收/已退还。合同退租时押金用于抵扣欠费或房屋损坏赔偿余额退还客户。很多粗制滥造的系统直接把押金当成租金一次性收取入账这个从财务角度是错账说出来会被答辩老师一句“押金怎么处理的”问住。租金递增这个问题我在前面数据库设计里提过这里放一个具体的计算示例。假设合同约定月租金2万元租金每年递增5%租期3年。第一年每月账单为20000元第二年每月的租金标准变为20000×1.0521000元第三年变为21000×1.0522050元。账单生成时根据当前账单月份所在年份计算当月租金标准。这里要处理好分界的逻辑以合同起始月为第一年起点而不是自然年。提前退租违约金合同表里记录break_penalty违约金规则通常为1-2个月租金。在退租审批流程中系统根据合同剩余期限自动计算应扣违约金并生成退款或补扣账单。这部分在退租功能中容易漏但一漏就显得业务脱离实际。6.2 账单生成与收款的闭环逻辑账单与收款做成了一个闭环每一步状态都有明确流转关系生成账单(应收) → 收款登记(部分/全额) → 自动核销 → 账单完成/剩余待收具体逻辑是合同生效时自动批量生成该合同整个租期内的所有账单这个操作在service层循环插入合同周期内按月生成。账单表状态有三种待收款、部分收款、已收款、已关闭作废。每登记一笔收款记录系统先判断该笔收款对应哪个账单再更新账单的累计实收金额如果实收金额等于应收金额则账单状态变为已收款。有一点要特别注意不要允许直接删除收款记录。真实财务场景中如果某笔收款录错了需要走“冲正”流程——新增一笔负数金额的收款记录将原记录和冲正记录关联标记。这样做的原因是财务数据需要保留完整的审计轨迹。虽然毕设项目可以简化但我在系统里实现了撤销逻辑标记作废而非物理删除这个处理方式能体现你在设计时考虑了真实的财务规则。6.3 看板报表的设计要点首页看板我放了以下几块内容核心指标卡片可出租总面积、已出租面积、出租率、本月应收租金、本月实收租金、本月招商标的新增客户数/带看次数/签约合同数。这些指标用一个SQL查询统计出来前端用统计卡片组件展示。租控趋势图用折线图展示近6个月的出租率变化趋势。出租率的计算方式是当前已出租面积 / 可出租总面积。趋势图用ECharts的折线图实现后端接口返回每个月末的出租率数据。到期分布图柱状图展示未来6个月每月到期合同数量和涉及面积。这张图对运营决策很重要——下个月如果有大片面积到期招商团队需要提前准备替代客户财务需要提前预估租金收入波动。数据报表这一块看起来很常规但实际使用中价值很高。运营总监每天早上打开系统不是为了操作业务就是为了看这些数字的变动。系统好不好用很大程度上取决于这个页面做得好不好。7. 核心功能实现要点与代码架构7.1 分页查询与条件检索的后端实现管理系统后端开发中分页查询是所有页面都要用到的底层能力。我用MyBatis-Plus的Page和LambdaQueryWrapper实现了一套统一的分页查询模式说几个具体要点。第一步前端请求参数约定。每一页的查询参数封装成一个Query对象包括pageNum、pageSize和各自的查询条件字段。后端接收后用LambdaQueryWrapper构建动态条件比如public PageResultHouseVO queryHousePage(HouseQuery query) { LambdaQueryWrapperHouse wrapper new LambdaQueryWrapper(); wrapper.eq(StringUtils.isNotBlank(query.getBuildingName()), House::getBuildingName, query.getBuildingName()); wrapper.eq(query.getStatus() ! null, House::getStatus, query.getStatus()); wrapper.like(StringUtils.isNotBlank(query.getKeyword()), House::getHouseNo, query.getKeyword()); wrapper.ge(query.getMinArea() ! null, House::getArea, query.getMinArea()); wrapper.le(query.getMaxArea() ! null, House::getArea, query.getMaxArea()); wrapper.orderByDesc(House::getCreateTime); // 分页查询 }这里的关键在LambdaQueryWrapper的条件参数写法——第一个参数是布尔条件条件为true时才会拼接该查询条件为空或null时自动忽略。这套写法不仅避免了大量if判断拼接SQL而且完全不存在SQL注入风险——MyBatis-Plus条件构造器内部使用预编译参数。答辩老师问“你怎么防止SQL注入的”你就可以回答“使用预编译框架的条件构造器参数值全部预编译绑定”这是标准答案。7.2 房源状态流转的Service实现状态流转是我重点设计的业务逻辑也分享下这份代码思路。单独写一个HouseStatusService提供状态变更的原子操作public void changeHouseStatus(Long houseId, Integer fromStatus, Integer toStatus, String operator) { House house houseMapper.selectById(houseId); if (house null) { throw new BusinessException(房源不存在); } if (!house.getStatus().equals(fromStatus)) { throw new BusinessException(当前房源状态已变更请刷新后重试); } // 状态流转合法性校验 boolean isValid validStatusTransition(house.getStatus(), toStatus); if (!isValid) { throw new BusinessException(非法状态流转: house.getStatus() - toStatus); } // 并发控制 - 乐观锁 house.setStatus(toStatus); houseMapper.updateById(house); }这里有个并发安全问题值得展开两个招商人员同时看中同一间空置房源都进行锁定操作如果不上锁两人都会读到状态为0的房源并各自更新为锁定导致同一间房被两个客户锁定数据出现脏写。我的解决方案是乐观锁house表加一个version字段更新时的SQL语句带上版本条件where id? and versionoldVersion。MyBatis-Plus支持Version注解开启乐观锁插件后updateById方法会自动带上版本条件更新成功则版本号加1。第二个操作者更新时因为版本号已经不匹配影响行数为0系统捕获到后提示“操作冲突请刷新重试”。这个设计体现了典型的并发控制意识属于加分的细节。7.3 Vue前端页面与接口联调实践前端实现上我以租控看板页面举例讲一下Vue的基本套路。Element UI的el-dialog、el-table、el-form、el-tabs几个组件组合就能解决几乎所有管理页面的UI需求。一个典型的列表页基本结构是顶部搜索条件区el-form的inline模式、中部操作按钮区新增、批量删除、导出、底部表格区el-table加分页组件el-pagination。监听条件变化重新加载数据这个在方法里统一处理// 获取列表数据的统一方法 async function fetchList() { const params { pageNum: pageNum.value, pageSize: pageSize.value, buildingName: queryForm.buildingName, status: queryForm.status } const res await listHouseApi(params) tableData.value res.data.records total.value res.data.total }前后端联调最容易踩的坑是跨域配置。开发阶段后端配置跨域可以让调试顺畅很多我用一个CorsFilter把常用的请求头都放开前端axios的baseURL设置为http://localhost:8080/api开发时直接访问后端服务。生产部署后因为前后端用Nginx做反向代理同源部署就没有跨域问题了。联调阶段我还有一个习惯分享所有接口先写后端文档再动手写前端页面。接口文档不用额外工具生成直接在Controller注释里写清楚入参出参含义即可。前后端约定好之后可以并行推进最后联调阶段通过Swagger-ui或直接在浏览器里请求接口做验证大量减少沟通成本。8. 系统部署与常见问题排查8.1 本地环境完整部署流程整个系统在本地跑起来我整理一份经过验证的具体部署步骤照着做基本不会出问题。后端启动步骤本地安装JDK 1.8、Maven 3.6、MySQL 5.7、Redis 6.xMySQL中执行项目提供的init.sql脚本创建数据库表和初始数据管理员账号、基础菜单权限、测试房源数据修改application.yml配置文件将数据库连接地址、用户名、密码、Redis连接信息改为本机配置Maven执行mvn clean package -DskipTests后端打为jar包命令行执行java -jar factory-lease-system.jar启动服务看到“Started”日志即启动成功前端启动步骤安装Node.js然后在Vue项目目录执行npm install推荐用npm install --registryhttps://registry.npmmirror.com国内镜像加速执行npm run dev启动开发服务器浏览器访问http://localhost:8080即进入系统登录页首次登录用初始化的管理员账号进入系统后先配置楼栋、房源数据再创建部门的用户角色分配权限菜单。这里有几个部署时常见的端口问题后端默认端口改一下很有必要因为8080端口在开发环境经常被占用。我在application.yml里把服务端口设置为8088前端vue.config.js中devServer的proxy代理目标同步改成http://localhost:8088这样一个环境变量适配所有接口请求换环境部署只需要改这一处。8.2 高频报错与规避方案做这套系统的过程中有几类报错频率极高我这里整理成速查表都是实际踩过的报错现象根本原因解决方案前端请求接口返回404跨域未配置或接口路径错误后端配置CorsFilter前端确认baseURL和接口路径一致启动报DataSource错误数据库连接配置不对核对url、username、password确认MySQL服务已启动JWT认证401token过期或请求头未携带前端axios拦截器携带token后端配置token过期时间中文乱码数据库字符集不是utf8mb4建库时指定DEFAULT CHARACTER SET utf8mb4MyBatis-Plus分页不生效缺少分页插件配置添加PaginationInnerInterceptor配置类npm install卡住网络问题切换npmmirror镜像源其中中文乱码是最常见也最好解决的。MySQL安装时的默认字符集可能不是utf8mb4建库时我习惯一条命令写清楚CREATE DATABASE factory_lease DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;另外后端application.yml里加上characterEncodingutf8连接参数双保险。这个问题如果建库时处理好后面全都顺风顺水否则每张表都要手工调整字符集那滋味谁做谁懂。8.3 演示环境准备与答辩常被追问的问题最后把答辩阶段的经验也分享一下这不涉及技术实现但和项目完整度直接相关。演示数据的质量直接决定系统演示效果。我建议准备一套干净、专业的模拟数据比如3栋楼、每栋4层、每层3-5间房源房源状态做好分布部分出租、部分空置、个别锁定客户数据准备8-10条并且有不同跟进阶段合同数据准备几份包括一份即将到期的和一份已经逾期的。这样演示时可以很自然地展示所有核心功能不用现场临时造数那种临时编数据演示的体验谁试过谁知道有多尴尬。答辩时老师针对这套系统最常追问的集中在几个点为什么是MyBatis-Plus而不是MyBatis或JPA回答要点MyBatis-Plus兼容MyBatis生态单表操作免写XML复杂查询仍然可以手写SQL学习成本低JPA自动生成SQL对复杂条件查询支持弱且自动生成的SQL性能不可控。Redis在这里到底承担什么角色回答要点验证码存储、登录token的分布式会话管理、房源热度缓存。进一步可以讲如果热点房源每次都被点击查看详情每次都查数据库数据库压力大用Redis做缓存可以有效降低数据库查询压力。如果要在生产环境部署还要做哪些加固回答要点数据库开启备份策略、Nginx配置HTTPS、日志接入监控系统、接口增加操作审计日志、生产环境禁止开放Swagger文档。有这份思考说明你不只是实现了功能而是具有生产环境的工程意识。9. 系统扩展方向与个人实操体会核心功能做完之后如果你还有余力有几条扩展路径值得考虑它们能让这个毕设从“完成”走向“优秀”。小程序端目前的后台系统是面向运营人员的客户端的线上找房、预约看房功能可以通过微信小程序实现。后端只需增加一组面向C端的接口查询房源列表按需求面积筛选。这个扩展能展示你对多端业务的理解而且小程序是当前企业数字化标配答辩时加分明显。消息推送站内消息目前依赖前端轮询可以扩展接入微信公众号模板消息或者短信服务合同到期提醒直接推送到运营人员的手机上业务响应速度更快。这个扩展只要抽象出一个消息发送接口预留短信实现和微信实现两个子类就行设计模式里的策略模式正好用上。大数据分析系统运行一段时间后积累的招商数据渠道来源、带看转化率、成交周期、租金价格走势可以做多维分析。后端用定时任务对数据进行统计汇总前端用ECharts绘制漏斗图线索→带看→签约和热力图不同区域房源的出租热度这些分析结果能直接支持园区运营决策是系统价值的进一步延伸。我在实际做这套系统的过程中最深的体会是毕业设计的技术深度不是看用了多少技术栈而是看你对业务逻辑的理解有多到位对细节的处理有多严谨。厂房租赁系统的表面是增删改查但里面隐藏着房源状态机、合同期与账单的联动、权限角色的数据隔离、并发锁控制这些真正考验设计能力的地方。把这些想清楚、做扎实答辩时每一处设计都能讲出为什么这么做、解决了什么问题这套系统的含金量自然会体现出来。如果你现在正在做这个题目我的建议是优先把核心业务闭环走通——招商线索到合同签约、房源状态流转、账单生成收款这几条主线做完整系统的主体就立住了然后再去补充管理端、看板和扩展功能。做完一个完整可用的系统也确实弄懂了每个模块为什么这么设计这份收获比辛苦调三天页面样式值得多。
