Spring Boot+微信小程序房地产销售管理系统设计与实战

1. 从毕业设计到可演示项目，这套系统到底能解决什么问题

先说说这个项目给我的第一感觉。每年到毕业季，都会有一批土木、计算机、甚至经管类专业的学生来问怎么做一个"看起来完整、答辩能过、老师不刁难"的系统。这其中的核心技术栈，就是Java后台加微信小程序前端。而房地产销售管理系统恰好是一个非常典型、永远不会过时的选题，因为它天然包含两类用户（买家和管理员）、三类核心业务（房源展示、预约看房、成交跟进）。

这套系统从名字就能看出来，它不是一套纯理论课程设计，而是"源码加文档加运行视频加讲解视频"四件套，基本就是给需要快速落地、长期维护和最终答辩演示的人准备的。无论你是准备毕业设计、课程大作业，还是想练手一个面向真实业务场景的Spring Boot项目，这套系统的覆盖面都够用：有数据库设计、有微信小程序移动端、有后台管理端，所有业务流程都围绕房产行业的真实痛点展开。

我在实际看这套项目结构的时候，最关心的问题其实是三个：第一，前端小程序能不能不经过太多修改就跑起来；第二，Spring Boot端在权限控制、文件上传这类高频模块上做得到不到位；第三，房源信息这种核心数据，是直接静态展示还是做成了可持续维护的数据库模型。下面我逐个环节来拆。

2. 项目整体设计与技术选型思路

2.1 为什么是Spring Boot加微信小程序，而不是SSM加大前端后台

很多人一看到系统带"后台管理"几个字，下意识就以为要写一个Vue或React的Web管理端。但这套项目的实际设计思路是在后台部分使用Spring Boot提供REST API，管理端以小程序或Web页面通过API实现数据操作。这里有一个很关键的背景：许多高校的毕设项目更看重移动端创新点。微信小程序不需要安装、打开即用，而且天然天然适合LBS类应用场景，例如查找附近楼盘，这一点在房产这种依赖地理位置与线下带看的业务中非常契合。

Spring Boot的加入则把后端开发的复杂度大幅降低。以前用SSM时，光配置spring.xml、springmvc.xml、mybatis-config.xml就能折腾掉两三天。现在Spring Boot通过自动配置和起步依赖解决了最繁琐的问题，我们只需要引入一个spring-boot-starter-web、一个mybatis-plus-boot-starter，再把数据库连接写在application.yml里，一个能跑起来提供接口的REST服务只需要十分钟就能搭好。别小看这个效率提升，对核心目标是做业务逻辑的人来说，这是最友好的技术栈。

2.2 技术架构里的隐藏设计，看懂这些才敢改需求

我拆解这套系统的技术分层后，发现它的架构思路非常"毕设友好"，但又保留了企业级项目的骨架。整体分层大概是这样的：

• 表现层：微信小程序端，负责房源展示、用户登录授权、预约表单提交；后台管理端负责数据列表、状态流转、统计概况及配置管理。
• 控制器层：用Spring MVC的@RestController暴露JSON接口，统一返回Result对象，包含code、message、data三段结构，方便前端统一处理报错。
• 业务层：Service接口加Impl实现类，比如房源增删改、预约状态流转、成交记录管理，所有业务规则都在这一层做校验。
• 持久层：MyBatis Plus做的ORM映射，几乎不用手写SQL，单表查询靠LambdaQueryWrapper，复杂统计再用@Select注解。

这套分层最核心的价值，不是它用了什么高科技，而是改造成本低。比如房源模块原本只有"在售"和"已售"两种状态，但如果后期想加入"待签约"和"已预定"，你不需要改小程序端的全部交互代码，只需在业务层加一个状态枚举透传下去，改动范围就很可控。

关于多端适配，也就是"微信小程序管理端 + 微信小程序客户端"的组合，还有一个设计上的取舍要讲。有些人可能觉得，管理端用Web更多，为什么也用小程序？这就得看你在什么场景下去演示了。实话说，在真实房产公司管理中，销售经理拿着手机看看今日预约量、改一改房源状态，比开电脑方便得多。所以说这个小程序两端设计，不是作者拍脑袋想出来的，而是有业务逻辑做支撑的。

2.3 这套系统的核心功能边界，你要做到心里有数

在我拿到这个项目源码的前期，我会先梳理一遍系统的功能边界。你不能到答辩时，老师问一句"你们的系统能不能实现房源批量导入"，你就开始含糊其辞。所以必须明确哪些是本系统的核心亮点，哪些是需要回避的边界。

从实际使用的角度看，这套系统主要分成两条用户线。第一条是普通访客或者说购房用户，他们的操作路径是：打开微信小程序 -> 授权登录 -> 浏览在售房源 -> 查看房源详情（图片、户型、面积、价格、地段）-> 提交看房预约 -> 在个人中心查看预约进度。第二条是置业顾问或者管理员，他们的操作路径是：登录管理端 -> 录入新盘房源 -> 管理户型图与标签 -> 处理预约请求 -> 把预约转为线下带看记录 -> 登记成交 -> 查看整个月的销售漏斗数据。

边界在哪里呢？这套系统不会去触碰合同电子签章、银行贷款计算器、VR看房这类高复杂度的领域模块。它做的事情是房产销售前期的链路管理，这个定位必须清晰，后续所有数据库设计和接口划分才有依据。

3. 核心功能模块拆解与数据库设计实战

3.1 用户端小程序，哪些页面最容易被面试官追问

小程序端是这套系统在答辩演示时最抓眼球的部分，因为它是用户能直接看到、直接操作的界面。页面通常包括首页、房源列表、房源详情、预约看房表单、个人中心和我的预约。每个页面背后对应的都是具体业务场景，你不能只做一个静态页面出来。

先说首页，绝大多数模仿链家的设计，顶部搜索框、中部Banner轮播、下面按"最新开盘"推荐房源列表。Banner如果做的是静态图片轮播，就要注意小程序端只能用<swiper>组件加JPG或PNG，URL尽量不要用本地路径，而是从后端返回图片URL列表，这样后台管理员换了一张活动图，小程序端不用发版就能看到变化。

再看房源详情页，这个页面要承载的内容很多，核心信息字段包括标题、小区名、几室几厅几卫、建筑面积、单价、总价、朝向、楼层、装修情况、标签（如"满五唯一""近地铁""学区房"）和图文详情。这里有一个经验要说：价格字段在后端存取一定要用整数存总价，不能用浮点类型存单价。比如一套房子总价是185万，后台字段就是total_price为1850000，单价可以在展示层用totalPrice/area动态算出来。这样后续做价格区间筛选时，SQL写起来会很顺畅，避开浮点问题。

预约表单就更要仔细了，因为这是产生业务数据的关键入口。用户在提交预约时，前端至少要传三个核心字段：用户ID、房源ID、期望看房时间。这里建议额外带一个"备注"字段，比如用户备注"周末下午才能到，希望经纪人提前联系"，这对线下带看转化很重要。而后端收到请求后要做的校验，不只是用户有没有登录，还要判断房源是不是已经是下架状态，这些逻辑看着小，但最容易在项目答辩时被深挖。

3.2 管理端功能，从房源到预约的一整条操作链

管理端的设计常见两种形式，一种是网页里嵌后台，另一种是做一套独立的小程序管理包。对于这个项目，我用得到的是基于权限区分的后台管理端——普通管理员能操作业务数据，超级管理员还能操作人员账号和系统配置。

整个管理端的操作链路可以分成三层。第一层是数据概况层，也就是dashboard仪表盘，展示总房源数、总预约数、本月成交量、待跟进预约数，配几个带数字的卡片就行，不需要复杂的图表库，以免增加开发量。第二层是核心业务层，包括房源管理（上下架、编辑、置顶）和预约管理（查看预约列表、处理状态）。第三层是基础配置层，包括用户管理、销售顾问管理、公告管理或户型标签管理。

一个细节容易被忽略，就是对预约状态的处理。我见很多新手写系统，预约状态就用两个状态"未处理"和"已处理"，这在真实业务里是经不起推敲的。老师或面试官只要问一句"用户取消预约了怎么办？""经纪人带看后爽约了怎么标记？"，系统就露怯了。比较好的做法是设计一套完整的状态机：待确认 -> 已确认 -> 已带看 -> 已成交/已取消。如果用户自己取消，进入取消状态；经纪人确认带看时间后，进入已确认；线下带看后，销售录入结果。这套状态机写熟了，你的系统逻辑完整度立刻往上走一个档次。

3.3 数据库表设计里的关键关联关系，用一张表说清

数据库是这类管理系统的基础，很多毕设项目挂掉就是挂在表关系混乱。这套系统的数据库设计大致围绕五个核心实体展开：用户表、房源表、预约表、成交记录表以及员工表。它们之间的逻辑关系，我用一个典型流程来说明：用户浏览房源，对某套房发起预约，系统在预约表中插入一条记录，接下来管理员看到预约并处理，确认后在线下带看，最终如果双方达成意向，则在成交记录表新增一条签约数据，同时把房源状态从"在售"改成"已售"。

这里我想单独解释一下openid的作用。微信小程序的登录机制中，前端通过wx.login()拿一个临时code，后端用这个code调微信接口换取openid，openid就是用户在当前小程序维度的唯一身份标识。很多刚接触的同学会把用户昵称头像直接存表里当作身份凭证，这不对，昵称可以伪造、可以重复，openid才能代表一个微信用户。所以用户在提交预约时，后端必须先根据openid查用户表，拿到整型主键user_id，再做预约的动作，这样外键关系才完整。

3.4 鉴权方案选择：为什么不用Shiro不再纠结

讲到后台权限，很多人在刚开始做毕设时会有个困惑：要不要引入Spring Security或者Shiro做一整套权限模型？我可以给个比较稳的结论：对于这类管理端和用户端分离的小程序项目，不用照搬RABC五表权限模型，因为业务角色就两类（管理员和普通用户），你引入二十多张表只会增加演示成本。

这套系统采用的鉴权思路通常是这样：小程序用户通过微信登录拿到一个自定义登录态的token，后续请求在Header里带上token，后端用一个拦截器校验token对应openid是否有效；而管理端的账号则是独立于微信生态的用户名密码体系，登录后签发一个JWT给管理员使用。两条鉴权链路互不污染，写起来也简单直接。

如果你想在答辩时展示一点技术含量，可以在自定义注解上做文章。比如写一个@RequireLogin注解，拦截器判断有value为true的属性就直接拦截。核心思路比引入整套Shiro要容易讲清楚，毕竟面试官最关心的不是你会不会配框架，而是你对请求一进来、token解析、用户身份获取这条链路有没有完整认识。

4. 核心接口设计与前端联调的关键细节

4.1 小程序登录接口，看似简单实则坑最多

联调过程中最常见的坑其实不是业务接口，而是微信登录。整套流程可以按下面这种方式写在代码里：

java复制@PostMapping("/wxLogin")
public Result wxLogin(@RequestBody WxLoginDTO dto) {
    // 1. 前端传入临时code，这里还要带上用户昵称等非敏感资料
    // 2. 调用 jscode2session 接口
    String url = "https://api.weixin.qq.com/sns/jscode2session?appid=" 
        + appid + "&secret=" + secret
        + "&js_code=" + dto.getCode() + "&grant_type=authorization_code";
    String result = restTemplate.getForObject(url, String.class);
    // 3. 从返回值中解析 openid
    // 4. 如果用户不存在则先注册，再生成自定义token
    // 5. 返回 { token, userInfo }
}

这里面有三个高频坑，我写代码时都踩过。第一，appid和appsecret必须放后端配置里，不能写在前端代码里，小程序端一旦打包上线，前端所有代码对用户都是可见的，secret直接暴露等于把大门钥匙交出去了。第二，微信接口有频率限制，如果调试时频繁调用jscode2session，会短暂被限流，所以别一个页面刷新就重新调wx.login()。第三，code是一次性的，用后即失效，后端必须在一次请求内完成换取openid的动作，不能前端保存code下次再用。

还有一个容易出错的地方，是小程序端的登录态token存储。不要用wx.setStorageSync('token', ...)存完之后就不管了，而是要在请求封装wx.request时统一从本地取token，放到Header里。同时处理好401状态码的全局响应，如果token过期，清掉本地缓存并引导用户重新静默登录，这个逻辑看起来基础，但是直接影响你在演示时到底会不会当众弹出一个"登录过期"的尴尬页面。

4.2 房源列表的分页与条件筛选，SQL怎么写才高效

列表页是联调大头，因为功能多、字段多。这套系统里，房源列表页通常支持按区域筛选、按价格排序、按户型过滤，并配套搜索关键词。这些条件组合起来，后端不能简单写死SQL，而是要把条件对象传入Mapper。

用MyBatis Plus来实现，可以参考下面这种片段，利用LambdaQueryWrapper构建动态查询条件：

java复制public Page<House> queryHousePage(int page, int size, HouseQuery query) {
    LambdaQueryWrapper<House> wrapper = new LambdaQueryWrapper<>();
    wrapper.eq(House::getStatus, 1); // 只看在售状态
    if (StringUtils.hasText(query.getKeyword())) {
        wrapper.and(w -> w.like(House::getTitle, query.getKeyword())
                .or().like(House::getAddress, query.getKeyword()));
    }
    if (StringUtils.hasText(query.getDistrict())) {
        wrapper.eq(House::getDistrict, query.getDistrict());
    }
    if (query.getMinPrice() != null) {
        wrapper.ge(House::getTotalPrice, query.getMinPrice());
    }
    if (query.getMaxPrice() != null) {
        wrapper.le(House::getTotalPrice, query.getMaxPrice());
    }
    wrapper.orderByDesc(House::getCreateTime);
    return houseMapper.selectPage(new Page<>(page, size), wrapper);
}

这段代码有三个实用心得可以分享。第一，价格区间用ge和le，如果只传了最小值，那就只加上限条件，这依赖条件外的空值判断，不能让用户逼着必须填完整区间。第二，关键词查询一定要用and包一层，因为关键词可能同时命中标题和地址，但如果外层已有其他条件，直接用两个like拼接会出现or的优先级问题。第三，排序默认按创建时间倒序，刚上架的新房源排在前面，这个符合用户浏览习惯，也方便演示时让新录入的数据立刻出现在第一屏。

对于首页推荐位，不能简单把列表前几条拿来复用。我建议合理利用数据库里的一个is_recommend字段，推荐位只取该字段值为1的数据，并按浏览量倒序取6条。这样做从产品视角来看更说得通，因为"给你推荐"和"全部房源"必须有区别。

4.3 图片上传与文件访问，本地存储方案要处理好

房源图片管理是房产系统的刚需，小程序端上传图片走的是wx.chooseMedia加wx.uploadFile接口。后端接收上传时，要考虑三个问题：文件存放在哪、能存多大、如何防止同名文件覆盖。

我记得看这套项目源码时，它的存储逻辑比较朴素，就是把上传的MultipartFile写到一个本地目录，然后返回一个URL路径。这种方法在本地演示完全够用，但有几个细节必须补上。一是目录不能用绝对路径写死，比如E://upload/，因为换一台电脑部署就崩了。应该用Spring配置项定义一个upload.path，再通过ResourceUtils.getFile配合相对路径处理。二是文件名需要用UUID、时间戳加原始后缀重新生成，避免两个用户上传同名为1.jpg的图片时相互覆盖。

有时候，你在管理系统上已经上传了图片，小程序端却看到图片裂开，这个问题八成出在URL上。如果你配置了虚拟路径映射/upload/**映射到本地磁盘目录，那么小程序<image>标签里要用完整的后端地址拼接路径，而不是相对路径。假如后端部署在服务器8080端口，图片存储的相对路径是/upload/house/xxx.jpg，那前端应拼接为http://服务器IP:8080/upload/house/xxx.jpg。很多人忽略了真机调试时，localhost指向的是手机自己，不是电脑，所以联调时这个细节要格外注意。

4.4 预约流程的状态流转，后端如何保证并发不超卖

再来讲一个听起来高级、做起来也不难的业务逻辑：预约同一套房子的并发控制。设想一个场景，两个用户同时看中了一套总价很香的房子，都在同一秒提交了预约。如果不做控制，预约表可能插入两条记录，可房子只有一套，这会造成业务数据冲突。

在真实行业里，这个问题的核心解法是在数据库层面控制：房源在"在售"状态下，同一个house_id才能插入预约记录；状态一旦被修改为"已预定"，后续插入就应该失败。用MySQL的乐观锁或者事务配合行锁都能做。从毕设答辩层面看，最容易讲清楚且不易出错的方案是加一个版本号字段：

java复制@Update("UPDATE house SET status=2, version=version+1 WHERE id=#{houseId} AND version=#{oldVersion} AND status=1")
int lockHouse(@Param("houseId") Long houseId, @Param("oldVersion") Integer oldVersion);

在提交预约的事务里，先执行这个update，如果返回值是0，说明房子状态已经被别人改了，直接抛出"该房源已被预约，请重新选择"的提示。如果返回值是1，则说明你成功占用了这套房源，再继续去插入预约记录。这个思路我建议每个做销售类系统的都学会封装，因为它就是最典型的并发控制问题。

5. 本地部署与运行指南：从0到能演示的完整步骤

5.1 准备环境和初始化项目，五分钟看清全局

我一般拿到源码后会按下面这张清单检查环境，再决定下一步怎么做：

首次导入项目用IDEA时，我会建议选择pom.xml作为Maven项目打开，让依赖全部下载完成后，先别急着点运行。第一步是改配置文件application.yml，把数据源地址、账号密码改成自己本地数据库的，第二步是执行项目里提供的SQL脚本在MySQL中创建数据库表以及初始化管理员账号，第三步才是启动项目。

有同学喜欢用Navicat直接拖SQL文件进去执行，这没问题，但要注意执行前检查一下数据库的name是否与配置里一致。如果脚本里用的是create database estate;而你的连接配置写成了estate_db，那即使脚本执行成功，后端启动也会找不到表。启动后，如果你能看到类似"Started Application in xx seconds"的日志，同时访问http://localhost:8080/api/ping能返回正常JSON，说明后端跑通了。

5.2 小程序端的导入与AppID切换注意事项

小程序端的目录一般是独立的，比如miniapp或wechat-app。打开微信开发者工具时，选择"导入项目"，目录选到小程序根目录，AppID这里非常关键。

如果你只是本地开发调试，可以选测试号，但某些能力受限。如果你用自己注册的小程序AppID，需要在小程序管理后台把request合法域名配置成http://localhost:8080或你后端电脑的局域网IP，并且勾选"不校验合法域名..."这种开发模式选项，否则真机预览时请求会被拦截。实际上在微信开发者工具中，开发调试阶段最方便的方式是右上角详情 -> 本地设置 -> 勾选"不校验合法域名、web-view（业务域名）、TLS版本以及HTTPS证书"，这样不用等备案也能高优先联调。

另外，项目里用于管理端登录的账号，通常是初始化脚本预设的，比如admin和123456。别去小程序端找密码，管理员账号和普通用户是两套体系，这也是很多新人混淆的入口。

5.3 如果出现404、白屏、登录失败，先按这个顺序排查

本地把站点跑起来之后，经常出现前端白屏或者接口报错的情况。我根据经验整理出一条排查路径，建议按顺序来。

第一步，看后端启动日志有没有红色报错。常见的启动失败原因包括：MySQL端口被占用、Table 'xxx' doesn't exist、Redis连接不上，等等。遇到这种问题，先把对应的外部依赖启动起来再说，不要闷头改前端。

第二步，打开浏览器或小程序的调试器，看Network面板里面请求的URL。如果是404，说明前端请求的路径和后端@RequestMapping路径不匹配；如果是403，多半是拦截器把未登录请求拦下了；如果是500，要看后端控制台具体的堆栈信息。

第三步，验证数据。先直接在数据库执行一遍系统的核心SQL，看看表里有没有数据。很多时候预览不出房源，不是后端代码问题，而是你只在管理后台录入了楼栋，却没给楼栋录入任何在售的房源，自然首页就空了。

6. 常见问题与避坑经验实录

6.1 微信小程序真机预览时的网络问题，最容易被忽视

后端和电脑端开发者工具都正常，但手机上打不开页面，这是联调环节最高频的问题之一。原因多出在手机与电脑不在同一个局域网，或者后端接口监听的是localhost而不是0.0.0.0。

解决方法是分三步自查。第一步，不要在小程序端把请求地址设置为http://localhost:8080，因为在真机上，这个地址指向的是手机自己。你应该改成电脑的局域网IP。第二步，启动Spring Boot时让它在所有网卡上监听，不要在配置里写死server.address为127.0.0.1，如果要绑定就绑定0.0.0.0。第三步，就是前面提到的开发者工具需要勾选"不校验合法域名"。这几步做完后，真机访问一般就能通了。

6.2 数据库表字符集引发的乱码，以及表字段命名的大坑

房产系统里会出现大量中文，比如地址、备注、标签等。如果建表时字符集用了latin1或者utf8，存emoji或冷僻字的时候会出现"?", "乱码"。我的建议是建库时指定utf8mb4，因为在MySQL 8.0的默认配置之下，utf8mb4是更全面的选择，它兼容emoji字符的存储。

字段命名这个坑值得单独提。有些同学习惯给字段取中文拼音缩写，比如房源面积叫mianji，这非常影响可读性和后续维护。项目里如果给字段加了@TableField("house_area")做映射，就别再在Service层写setMianji()这种取名风格了。规范化的命名是area、totalPrice、status加驼峰风格，它让前后端沟通成本直线下降。

6.3 后端启动显示端口被占用，快速定位与换端口

在Windows开发时，8080端口非常容易被其他程序占用，比如Skype、Docker或者另一个正在运行的Spring Boot实例。最快的处理方式是打开命令行执行：

bash复制netstat -ano | findstr 8080

然后看最后一行显示的PID，再执行taskkill /PID 刚才的数字 /F关掉对应进程。如果这个端口上跑的是你自己另一个重要服务，想换端口更简单，改application.yml中的server.port为8081或者8082即可，但记住小程序端的request地址也要同步改，否则请求还会打到旧的8080端口上。

6.4 项目讲解视频怎么录才加分

说到底，源码加文档加运行视频加讲解视频的配置，不只是让你拿到手就用，也意味着你需要掌握演示的方法论。录讲解视频时，不要照着PPT念需求，而是走一条业务故事线：先点开小程序首页，模拟一个用户找到一套房，点详情后发起看房预约，然后切换到管理端，处理收到的新预约，并把状态推进到带看和成交，最后回到首页，看到房源已经变成了已售状态。这条链路完整地展示了你的数据结构、接口调用、状态设计，比简单罗列页面有价值得多。

强调一个小技巧：在录视频前，把数据库里造几条看起来够真实的数据。比如房源字段不要放"test1"这样的占位内容，而是正经的"XX花园3室2厅 108平 南北通透"、价格写成"188万元"这类带业务感的文案。演示时观感直接不一样，老师对你的印象分自然会高。

7. 从毕设到真实项目，这套代码还能怎么扩展

7.1 如果房源量上涨，本地存储和查询应该怎么升级

这套系统在本地环境和几百条房源数据下运行毫无压力，但如果想把它演进成能支撑数十万房源量级的业务系统，从架构角度有几件事要提前做。

第一，图片存储要从本地目录迁到云存储，或至少改用FastDFS、MinIO这类分布式文件存储中间件。因为本地磁盘的扩容和维护都是有上限的，而且一旦部署环境变化，历史图片的迁移非常痛苦。第二，接口层要加上缓存。房源列表接口的大多数请求都是读多写少，可以加上简单的Redis缓存，把热点房源的详情页缓存十分钟，能明显减少数据库查询压力。第三，可以考虑引入全文检索，等关键词搜索出现"地铁""学区""南北"这类语义化标签时，MySQL的like %keyword%就会变慢，这时换成Elasticsearch更合适。

但我也要说实话，针对毕设场景，这些扩展不一定落地，面试时能讲出演进思路，已经能拉开你和同龄人的差距了。

7.2 增加销售漏斗看板、合同电子签、跟进计划提醒

如果要给这个项目增加新功能，我会优先推荐加数据看板模块，也就是用ECharts柱状图展示每月新增预约数和成交量。它实现难度不大，后端只需要写一个按月份分组的SQL，前端用一个柱状图组件渲染即可，但做出来后对整个系统"数据可视化"的档次提升立竿见影。

7.3 把管理后台迁到Web端，技术栈可以怎么降级或升级

很多同学会觉得"管理端也用小程序有点独特"，答辩时老师可能会问一句"为什么不做网页后台？"这时候你不必慌张，因为从Spring Boot接口层来看，管理端无论换成Vue还是换成小程序，调用的都是同一套REST API。真正要改动的只是视图层的展示组件和路由。比如管理端首页要放一个表格列表，在Vue里就写el-table，在小程序里就写<view>加wx:for循环。

我自己在实际操作中比较建议的是：如果你时间充裕，把管理端做成Web管理后台，整套系统会更贴近企业中后台产品的形态；如果你时间比较紧，维持小程序双端也完全没有问题，毕竟业务闭环是完整的。实在要改成Web端，有个成本很低的路线，后端接口基本不动，只新写一套Vue3加Element Plus的管理界面就行。几天时间能完成主要页面切换。

说到底，这套系统最大的价值不在于有多少先进技术，而是它能让你在一个完整的业务闭环中，把Java Spring Boot开发里最核心的REST API设计、数据库建模、小程序联调、权限校验等知识点全部实践一遍。能够独立说清每个模块"为什么这么设计"，这份沉淀就已经超过很多只顾着抄代码的同学了。