写这篇博客我想以过来人的身份聊聊这个经典组合——Spring Boot Vue 的房产销售系统。这是我当年带着源码和论文从零到一完整走下来的项目。整个过程包括踩坑、优化、答辩各个阶段的细节我都还记得很清楚。这篇文章没有废话直接讲清这套系统该怎么拆、怎么做、怎么说希望给正在准备毕业设计或者想练手全栈项目的同学一个踏实的参考。1. 项目整体设计与技术选型思路1.1 为什么是 Spring Boot Vue 这套组合很多同学刚开始定课题时都会纠结技术栈我当初也绕了不少弯路。选这套组合核心是三个层面的原因市场需求、开发效率、学习性价比。先说市场层面。虽然各种新的框架层出不穷但 Spring Boot 和 Vue 的生态成熟度在中小企业、外包公司里依旧是最稳固的。我答辩时老师也强调课题选型要体现“工程实用性”。这套组合意味着你掌握了一套很主流的全栈开发技能不是只能做课设玩具的技术。效率层面更直观。Spring Boot 帮你把 SSM 时代繁琐的配置几乎都自动处理了内嵌 Tomcat改完代码直接跑 main 方法。Vue 的前后端分离模式又让页面开发非常顺手组件化写起来一级棒不用再像 JSP 里那样把 Java 代码跟 HTML 混在一起。我实测下来单人开发这种规模的项目从搭建到完成核心模块四周左右基本能出一个可演示的版本。学习性价比层面。这套组合的资料极其丰富出现任何一个报错搜索一下基本都有答案。这意味着你不需要在环境配置上耗费太多精力。尤其是对不少基础一般、平时没怎么敲代码的同学来说选一套社区成熟、文档完善的技术栈至少能把项目顺利跑通这已经是成功的一半了。1.2 房产销售系统的角色与需求边界做毕业设计最忌讳的是把需求想得太大。我当时只圈定了三类角色管理员、销售顾问、普通客户。管理员管后台核心配置楼盘的上下架、房源信息的审核、销售数据的统计、用户账号的管理。销售顾问负责日常跟进录入自己负责的房源、更新房源销售状态、登记客户的预约看房记录。普通用户走前台流程浏览房源、按小区和户型筛选、在线提交预约看房、查看自己的预约记录。这个边界划分有讲究。核心就是抓“房源生命周期”和“预约流程”这两条主线同时每条线都留出一定的新功能扩展空间。比如后期可以有客户意向登记、成交合同管理、定金缴纳记录。如果一开始就把合同、贷款、售楼员业绩提成全塞进去这个项目就不是毕业设计而是工业项目了开发量可能翻好几倍。毕业设计的答辩评分通常看重的是“逻辑完整 代码见功底 业务闭环”。房源从“录入”到“展示”到“预约”再到“成交”形成一条完整的链路远比一堆零散菜单要拿分。1.3 数据库设计的心得建立面积大于字段数量表结构是整个系统能否跑通的地基。我当时设计了三张核心业务表后来实践证明这个思路是对的。楼盘表我管它叫“项目表”。主要字段是楼盘名称、地段、所属区域、开发商、楼盘封面图地址、简介。这里有一个非常容易踩的坑就是房源表和楼盘表容易混淆。房源是一套具体的房子它有真实的门牌号、面积、户型、朝向、楼层、单价而楼盘是一个更大的物理范围。很多初学者会把看过房的朋友随口问一句“你项目有几个表”实际上这里拆开建模后面统计分析时才知道有多舒服。房源表要重点记录的字段包括所属楼盘 ID、楼栋号、单元号、门牌号、所在楼层、总层数、户型几室几厅、建筑面积、朝向、装修情况毛坯/简装/精装、挂牌单价、总价、房源描述、房源图片、销售状态待售/已售/下定、录入时间、最后更新时间。预约表记录用户的看房意向。核心字段包括房源 ID、预约用户 ID、预约时间、联系电话、状态待处理/已看房/已取消/已完成。为了做演示和答辩数据分析建议加一个创建时间和备注字段。用户表给管理员和销售顾问共用一张表用一个 role 字段来区分。客户其实也是用户但功能权限不同。为了信息完整我后来又加了一张客户意向表记录客户对什么价位的房子感兴趣方便销售顾问后期电销。这里想特别说一句建表的字段宁多勿少但表关系别搞得太复杂。比如面积、朝向、户型这种字段数据库直接存数值和字符串即可千万不要为了省事把整个房源信息存在 MongoDB 里或一个大 JSON 字段里这样虽然前期方便但论文里的 ER 图和数据库设计章节会非常难写答辩时也可能被问住。2. 核心功能模块拆解与实现逻辑2.1 用户认证与权限控制的细节毕业设计里权限太高深没有必要但一点不做又显得基本功不扎实。我最终采用的是基于拦截器 Session 简单角色判断的方案。在实现登录接口时密码我用了 MD5 加盐处理。裸奔存储密码答辩时被问“安全方面做了什么”场面会很尴尬。加盐逻辑很简单前端传密码后端先拼上一个固定盐值字符串再算 MD5。比如md5(password salt2025)这种写法虽然不算最安全但至少体现了“校验阶段是加密比对”的意识不是一个观念没有的人。权限拦截我用的是 Spring 拦截器。定义了一个LoginInterceptor在 preHandle 方法里从 session 中取出当前登录用户如果为空直接重定向到登录页。接下来用注解区分接口角色比如RequireRole(ADMIN)。在拦截器里如果用户角色的权限小于接口要求的级别返回 403。这样一个极简的 RBAC 雏形就完成了。这里想分享一个实战问题前端登录后怎么知道用户是普通用户还是管理员我的做法是登录接口返回一个用户对象只包含 ID、昵称、头像、角色标识这些基本信息不返回密码。前端存到 localStorage 里每次路由跳转前判断角色再决定渲染哪些菜单。用这种方式菜单就能动态生成管理员和客户看到的侧边栏是不同的这个交互在答辩时非常加分。2.2 房源搜索与列表展示的骨架式设计前台首页的房源检索功能是整个面向客户的核心入口。搜索条件我支持了关键词楼盘名、区域、户型、价格区间、朝向等组合查询。后端接口是GET /api/houses参数通过对象接收我用 MyBatis-Plus 的 LambdaQueryWrapper 实现动态拼接查询条件。很多同学在这里会犯一个错误把多个查询条件用 if-else 硬拼 SQL 字符串既不优雅又难维护。LambdaQueryWrapper 的本质是多条件动态查询代码可读性强很多。这块在实现时有几个细节容易翻车。第一价格区间查询别用字符串比较要转 BigDecimal 再比较第二状态字段千万要用枚举或固定编码比如 0 代表在售、1 代表已售、2 代表已下定不要用“是”“否”这种不确定性文本第三前端传过来的条件可能为空要做空值判断否则查出一堆错误结果。前端房源的卡片列表我用了 Element Plus 的 el-card 组件来铺底。每个卡片展示封面图、楼盘名、简要信息和价格标签点击后跳转到房源详情页。详情页是真实的门面图片轮播、户型描述、配套信息都要完整。这里我加了一个很贴心的功能页面上直接显示“在线预约看房”按钮点击后弹出时间选择对话框提交后生成预约记录形成一个完整的业务闭环。真正让这个页面出彩的不是什么高端技术而是交互逻辑的完整。访客未登录时点击预约会被引导到登录页登录成功后自动跳回刚才的房源详情页。这种体验感对项目评价相当有用。2.3 后台管理模块如何做到“能用又好看”后台管理页面我用 Vue Router 配合二级路由做了侧边布局。管理员进入后有若干菜单每个菜单对应一个列表页和若干操作按钮。这里想详细展开两个比较核心的模块一个是房源管理一个是预约管理。房源管理是整个系统的关键。除了普通的增删改查我加了几个特殊操作。第一是房源照片上传。前端用 el-upload 组件这里我用的是组件自带的 action 属性指向后端文件上传接口上传成功后拿到返回的文件名拼到详情表单的图片列表里。后端我用的是 MultipartFile 接文件然后转存到本地一个 upload 目录再把访问 URL 返回给前端。需要注意的几个点文件目录要用配置统一维护别写死在代码里上传后的文件需要做文件类型校验我只允许 jpg、png、webp文件名用 UUID 重命名避免中文和重复名互相干扰。还要做的是新房源录入时我用了一个二级联动组件。选择一个区域后下拉框只出现该区域的楼盘。因为楼盘表和区域字段是一对多关系所以这个功能其实是基于接口的联动筛选逻辑非常简单但体验提升明显。房源“编辑”和“详情”我复用了同一个表单组件只是初始化时是否填充数据不同这个设计合理减少了代码体积。预约管理模块后台可以看到所有客户提交的看房申请。列表要有时间排序、状态筛选。管理员或者销售顾问可以点击“处理”按钮把状态从待处理改成已看房同时填写看房反馈。这里我特意加了一个统计小卡片今日预约数、待处理数、本月新增房源数。这三个数据是仪表盘我建了一个单独的统计接口用 group by 配合 count 聚合计算。统计图一开始我打算引 ECharts后来发现为了稳定完全可以做成简洁的数字卡片展示效果还是不错的而且不会增加系统复杂度。2.4 数据统计模块的实用做法物业管理或者房产销售系统的总负责人都比较关心房子的销售数据。所以在后台我加了一个“统计分析”页面用 ECharts 画了饼图和柱状图。月度成交量用折线图展示不同户型的库存量用柱状图展示各区域的房源占比用饼图展示。后端统计接口怎么写我当时是直接在 Service 层写方法从房源表里查 group by 户型或者 group by 区域的汇总结果。前端拿到数组后转换为 ECharts 需要的结构。这里要提醒大家特别注意数据格式问题ECharts 的 series data 大多接收数组而后端查出来的 List可能需要重新组装。我当时就是转换这一步没做好图表一直空白后来在前端 console 里打印数据才发现字段名对不上。如果想让这个模块更出彩可以加一个简单的条件筛选。比如按时间范围过滤统计这个时间范围内的成交量。这就是动态 SQL 的又一次应用技术含量增加不多但演示效果会更好。2.5 前端路由守卫与请求封装这块内容在论文里能占不少篇幅我把实际做法写下来。Vue Router 的 beforeEach 导航守卫判断用户是否有 token没有就跳转登录。有 token 但访问了无权限的页面则根据角色标识做二次拦截。这里注意不要只依赖前端限制后端接口的权限校验必须同步做前端限制只是为了用户体验。请求封装我用了 axios 实例设置 baseURL 和超时时间在拦截器里统一注入 token 到 headers。响应拦截器里判断 HTTP 状态码如果是 401 就强制清除登录状态并跳转登录页。这种统一封装的好处是后续写业务接口时不需要重复处理错误状态逻辑代码保持在最简状态。这一段在论文“前端架构设计”章节可以扩展润色是技术细节比较丰富的部分。3. 实操过程与核心环节实现3.1 开发环境版本选型与避坑很多项目跑不起来第一问题就是版本冲突。我当时的版本组合用了相当稳的组合记录在这。后端用 Spring Boot 2.7.18不是 3.x 系列。因为 3.x 要求 JDK17 以上部分老师在运行老项目时可能环境不配而且不少第三方依赖的兼容性在 2.7 时代最稳。JDK 用 1.8这是为了对老平台还原度更好也完全满足需求。数据库用 MySQL 5.7经典稳妥不需要上 8.0 的新特性。前端部分Vue 用 2.6 还是 3.x 本身有争论。我做的是 3.x Vite Element Plus 的组合。但注意Vite 和 Node 版本有对应要求我当时本地 Node 版本偏老跑 Vite 项目一直报错后来升级到 Node 16 才顺畅很多。如果你不确定自己环境可以直接去网上找一个现成的 Vue3 Vite 基础模板跑起来再开始写业务代码。MyBatis-Plus 版本建议 3.5.x这个版本对 LambdaQueryWrapper 的支持非常到位。连接池不用多考虑用默认的 HikariCP 完全够用。为了防止大家踩环境坑我建议直接把后端依赖固定版本号前端 package-lock.json 也不要随便删。如果下载依赖速度慢就换国内镜像源淘宝源的经验大家都有不展开说。3.2 后端项目初始化与代码分层规范创建一个 Spring Boot 项目。我的做法是用 Maven 的 archetype 先生成然后在 pom.xml 里引入 web、mybatis-plus、mysql-connector、lombok、validation 这些起步依赖。代码包结构我建议先分域名里层还是代码分层。当时我用的是经典分层controller、service、mapper、entity、config、interceptor、common、dto、vo。实体类和数据库字段用 MyBatis-Plus 的注解一一对应DTO 用于前端传入的参数对象VO 用于组装返回给前端的响应数据。controller 层只负责接收参数和返回结果不写业务逻辑service 层做业务处理mapper 层保持最简 SQL。快速开发的场景下这种分层并不会显得臃肿而且论文的“系统设计”章节可以自然多几页内容。统一返回结果封装类我定义了一个 Result。这个类包含 code200 表示成功、message、data 三个字段。所有接口返回这个结构。统一返回值的好处是前端 axios 拦截器可以按 code 做全局判断比如 code 为 500 直接弹错误提示不用在每一个业务方法里单独写错误处理逻辑。还有一个细节是全局异常处理。我用了 RestControllerAdvice 注解捕获异常统一转成 Result 返回。这样即使代码抛出了空指针前端拿到的也是一段 JSON 而不是 Tomcat 默认的错误页。这个设计能减少很多低级联调问题我自己在第四周联调时受益很多。3.3 前端页面搭建与核心组件开发流程前端搭建我分三步走。第一步配置路由。在 router/index.js 里先定义好所有页面路径。用懒加载方式导入组件即component: () import(../views/xxx.vue)这样首屏加载会快一些。这里解释一下路由懒加载是 Vue 的性能优化手段虽然在小项目里效果不明显但写进论文里是一个加分点。第二步封装公共组件。把复用频率最高的内容先做好。比如分页组件、搜索栏组件、房源卡片、空状态占位。El-Pagination 的分页逻辑要注意数据总量 total 是后端返回的必须正确绑定否则翻页会出问题。我在这个坑上花了将近一晚上才明白明明接口返回了数量但表格下面就是不显示分页器后来发现是把 current-page 绑定写错成了字符串数据类型不对 Vue 就失效了。第三步写页面级组件。把登录页、注册页、首页、房源列表、房源详情、预约中心、后台布局以及后台各个管理页面依次完成。前后端接口联调时我习惯先在浏览器控制台的 network 里看接口报文对照返回来确定问题出在前端还是后端。3.4 预约看房与业务流转逻辑的完整梳理这是业务闭环的核心环节我把整个数据流转写下来。用户在前台房源详情页点击预约按钮前端弹出时间选择组件用户选择预约日期。发起请求前前端拦截判断没有登录就跳转登录页。登录后继续预约流程把房源 ID 和预约时间传给后端。后端预约接口的逻辑是先判断这个房源是否存在且状态是待售如果已经已售就不能预约。如果通过了创建预约记录状态置为待处理同时把房源状态改为“下定”。这里注意同步修改状态其实是一个小事务因为涉及两个表的更新所以我在 service 方法上加了 Transactional。这是事务管理的实操应用答办时值得拿出来讲解。前端在预约成功后跳转“我的预约”页面用户可以在这里看到自己所有预约记录并且可以取消预约。管理员在后台看到状态为“待处理”的预约点击“完成看房”后状态改为已完成。如果需要可以录入反馈。业务流转到这里就形成了一个闭环。整个流程没有任何复杂算法但业务逻辑完整、功能可演示、事务处理合理这些维度在答辩里都能成为亮点。为了让项目看起来更饱满我建议在用户端加一个“浏览历史”功能。用户访问过哪些房源记录到 localStorage下次登录还能看到。这个功能不需要后端参与写起来很简单但让项目多了一个记忆点和“用户体验”层面的讨论直接挂钩答辩时可以聊几句。4. 常见问题与排查技巧实录4.1 项目跑不起来的几个高频根因我把实际开发中最容易卡壳的问题整理成一张速查表同学可以直接对照排查。现象可能原因排查建议Spring Boot 启动报连接不上数据库MySQL 服务没开、密码错误、数据库名和配置不一致先用 Navicat 或命令行本地连接确认能连通再启动项目前端访问接口报跨域错误后端未配置跨域过滤器或前端请求 URL 写错看 network 里请求的 URL或者在后端加一个全局 CORS 配置类代码改完页面没有生效前端没启动热更新或浏览器缓存了旧包刷新浏览器重启 npm run dev清除浏览器缓存分页数据返回正常但前端不显示字段名大小写或 types 类型不匹配在控制台打印返回的 data 结构跟组件里写死的 field 按字段名比对上传图片后访问 404图片目录不存在或资源的静态映射没配置确保 upload 目录已创建并在配置里声明静态资源映射计算字段总数不对查询条件不一致或者统计时没有过滤状态把 SQL 单独拿出去执行为里看一下 group by 的结果这些问题是新手全栈开发的标配难点几乎人人都会至少碰到其中三四项。建议同学们碰到问题不要慌先看浏览器 console 和 network再回去看后端日志两个信息一对照基本上能在一两小时内定位。另外平时在开发阶段就养成前后端分离日志输出的习惯后端把请求路径、参数、返回状态都打印出来排查效率会好很多。4.2 后端常见业务逻辑错误与分析房产销售系统里最经典的业务逻辑坑我几乎都踩过。第一个是预约重复提交。用户连续点击两次预约按钮就会生成两条预约。我的解决方法是前端在提交过程中禁用按钮同时在后端接口加了一个简单的防抖判断同一用户对同一房源是否已有未处理的预约记录。如果在直接报业务异常“已有待处理的预约无需重复提交”。第二个是下架房源的读保护。如果管理员把某套房子下架了用户端列表已经看不到但如果用户事先保存了详情页链接还能直接访问 URL。我的处理方案是详情接口中检查房源状态如果已下架统一返回“房源不存在”避免这种边缘情况。这类细节体现了对业务状态机的理解面试和答辩都很加分。第三个是空结果返回的安全问题。前端拿到 null 数据然后直接访问其属性极容易报错“Cannot read properties of undefined”。我后来写前端有一个习惯拿到后端数据先做一层空数据处理比如list || []、data || {}然后用可选链?.访问属性。这个习惯是从踩坑中逼出来的现在写任何项目都改不掉了。第四个问题是列表中嵌套的其他实体字段没返回。房源列表接口中为了让前端直接展示楼盘名称我需要在 SQL 里通过关联查询把楼盘名字带出来。如果表设计用时前没有造好冗余字段或者没有用好关联查询前端就会一直显示不出楼盘名还以为是接口错了。后来我在房源表的 VO 里加了一个projectName字段专门用于列表展示这是很常见的冗余查询设计也值得在论文里写一段。4.3 前端页面细节问题的避坑提醒Element Plus 组件默认填充样式虽然好看但有些参数不设置就会出现奇怪的布局问题。我这里挑几个最常见的说。表格列宽问题。el-table如果不设置列宽内容多时会把布局撑得非常奇怪。我的习惯是每一列都设定合适的min-width且最后一列设为固定宽度方便放置操作按钮。下拉框组件数据初始化。用了el-select时如果 options 的数据是通过异步接口加载的而回显值是初始化阶段就绑定好的那么可能回显时找不到对应的 label页面就显示一串数字 ID。解决方法是在拿到 options 之后再用 setValue 或重新赋值的方式进行回显。表单校验问题。el-form的 rules 规则如果触发方式设置成change而不是blur输入过程中校验提示会频繁触发。对于价格、手机号这种字段我建议设置成blur触发校验回车或失焦时再提示体验更自然。移动端适配的问题。这个系统虽然是桌面端为主但我在写首页和房源详情页时顺手加了一些简单的响应式样式比如在窄屏下列卡片单列展示。这个属于加分项不强制要求有精力的同学建议加一下成本不高但演示效果确实不错。4.4 论文写作与答辩准备的实操建议到了论文环节很多代码写得不错的同学反而卡住了。我的经验是论文一定先搭好目录框架再填充内容而不是一边写代码一边写论文。毕业设计的论文一般包含摘要、绪论、需求分析、系统设计、系统实现、系统测试、总结几大章。摘要要突出三要素用了什么技术、实现了什么系统、解决了什么问题。这一段要反复打磨因为答辩老师第一眼就会看到印象也来自摘要。第一章绪论部分关于背景和意义可以用行业数据来充实但不要太长两页以内就够了重点还是后面的设计和实现。需求分析章节是论文的骨架。要列出功能需求和非功能需求最好做几个用例图虽然我手画时丑到不忍直视但画完会很加分。系统设计章节对应数据库设计和概要设计把 ER 图和表结构放进去。系统实现章节是大头每一个核心功能模块配截图 核心代码片段 逻辑讲解这里千万要避免大段代码贴上去截取关键代码片段就行。测试章节容易被低估。我建议至少写 15 条以上的测试用例覆盖正常流程、异常流程、权限验证、数据校验等维度。每条测试用例含前置条件、输入内容、预期结果、实际结果四项这部分“凑字”非常有效率而且老师一眼能感觉到你干活了。测试除了功能测试外可以提一下使用了 Postman 做接口测试这也是一个亮点。答辩准备方面我的经验是先准备好一个三五分钟的演示路径先展示首页和房源浏览再模拟登录管理员后台增删改查最后切到统计图表页面。途中准备好可能被问到的问题诸如“你的项目有哪些亮点”“数据库为什么这么设计”“权限控制怎么实现的”“如果并发量大怎么办”。这些问题不算太难但很考验对项目的整体理解。建议把核心业务表结构和核心接口的调用过程背下来答办时做到不看资料也能说清楚印象分会好很多。5. 系统亮点提升与扩展方向作为一个毕业设计至少要把“够用”和“出彩”分开。基础要求是把业务闭环走通而能让答辩分数上一个台阶的是几个小而实的亮点设计。第一个亮点是防止重复提交的接口幂等性处理。在预约接口上做基于用户和房源维度的唯一约束或状态检查这是生产系统中非常常见的需求。技术上简单但在答辩中展示了你对并发和数据一致性的思考比堆砌一堆华而不实的炫技更有说服力。第二个亮点是图片上传接入云的可行性。如果条件允许把图片上传到云存储前端直接用 CDN 访问。这里只需要改一个存储实现类就能把本地存储换成云对象存储。答辩时可以聊聊本地存储和云端存储的取舍展示自己的视野。第三个亮点是引入 Redis 做房源浏览量的缓存。用户每次点击详情页浏览量加一这个接口如果频繁写数据库压力不小。引入 Redis 的 incr 命令缓存浏览量定期同步到数据库。这是一个非常经典的高频读多写少场景优化案例虽然项目小但是设计思路可以放大到真实的互联网业务中去。这个扩展方向如果讲清楚能量比技术深度本身更大。第四个亮点是搜索引擎或者全文检索的思考。房源列表如果数据量大MySQL 的 like 查询性能会变差可以引进全文索引或者 Elasticsearch。同样现在我们做的是小数据量但聊一聊数据增大后怎么演进说明你对系统的扩展性有认知这在答辩中是加分项。不过不推荐在项目里真的引入重件容易导致部署复杂化和系统不稳定。还有一点值得提的是对项目部署的态度。把 Spring Boot 打包成 jar在服务器上用nohup跑起来前端打包后交给 Nginx 托管同时配置反向代理转发 API 请求。这里面不需要运维经验只需要了解基本的 Linux 命令和 Nginx 配置。如果能在答辩现场打开浏览器访问线上地址体验的直观性和可信度会非常高。我身边有不少同学就是靠这个环节拿下了不错的分数。6. 个人经验总结与避坑指南前后端分离项目最舒服的开发节奏我是这样体会的先定义好接口文档无论用 Swagger 还是 YApi好在动手写前端之前就把接口响应的 JSON 结构定下来。很多人前后端联调慢根本原因就是接口没有先定义清楚前端等后端写完了再对照返回值改代码后端等前端催着改接口两边来回扯皮。我在项目开发中期才意识到接口文档的重要性后来补了一个简单的 Markdown 接口文档把每个接口的路径、入参、返回示例写清楚。自己一个人开发还好如果两个人协作这个文档的价值会成倍放大。而且答辩时老师问“项目有没有 API 文档”拿出来也是加分点。测试与部署要安排足够的时间这大概是整个过程最容易拖延的部分。本地跑得好好的部署到服务器上却连不上数据库。通常是因为服务器的安全组或者防火墙没放行端口。我的建议是部署前把可能出现的网络问题提前排查服务器上能否访问公网 MySQL、端口是否被防火墙拦截、数据库连接用户是否授予了远端访问权限。这类问题如果到答辩前一晚才遇到心态会被彻底搞崩。最后一点我特别想分享的是做毕设的核心目标不是把所有功能都做全而是把一个闭环做得完整且稳。宁可只有预约和房源两个核心模块也要保证模块之间逻辑顺畅运行无 bug。评委老师见过太多程序跑着跑着就崩溃的演示一个稳定跑完全流程的系统本身就胜过了大部分半成品。这个房产销售系统在我的整个技术成长中占据了一个比较特殊的位置。它让我把前端、后端、数据库、权限、事务、部署这些散落的点真正连成了一条线。后续我再做其他项目时很多设计模式、分层思路、异常处理方法其实都是从这个项目里开始的。如果你也正在做类似的项目希望这篇记录能帮你省下一些不必要的弯路把时间花在真正能提升系统质量和答辩底气的地方。