企业官网建设流程全解析

家政保洁预约系统，名字听着不复杂，但真正落地时涉及到的业务边界，比我做之前预想的多得多。前段时间我刚完成一个基于SpringBoot+Vue的家政保洁预约系统，从数据库设计、后端接口开发到前端页面联调，整个过程踩了不少坑，也沉淀出一些可以复用的经验。这个系统解决的需求很明确：让用户不再打电话反复约阿姨时间，让家政公司不再拿着一张Excel表格靠人肉排单，让订单状态随时可查、可追踪、可统计。

这篇文章我不打算讲太多“高大上”的架构，而是站在从业者的角度，把项目的设计思路、表结构、核心代码逻辑、前端要点和真实踩坑实录完完整整梳理一遍。适合在做类似预约类系统的朋友，或者准备把这类题目当毕业设计的同学参考，哪怕你还没有接触过SpringBoot和Vue，按着这套思路往下走也能少走很多弯路。

1. 项目整体思路与核心模块拆解

1.1 这类系统到底在解决什么问题

很多刚接触这个题目的人会以为“家政保洁预约系统”就是一个普通的商城加一个日历控件，但真正做下来你会发现，业务规则才是核心难点。家政公司原来的工作模式一般是：用户在微信上发一句“明天下午能做保洁吗”，客服再挨个联系阿姨确认档期，确认后手工记在本子上。一旦单量上来，这种模式必然出错，用户和阿姨之间的时间冲突、错单漏单都是家常便饭。

所以基于SpringBoot+Vue做这套系统，价值不在于把页面做得好看，而在于把“人找服务”转变成“系统调度服务”。用户端可以自主浏览服务项目、选择合适的日期时段、下单支付；管理后台能看到所有待处理订单，并对阿姨进行排班派单；阿姨端可以查看自己被分配的订单、更新时间状态；运营者还能从后台看到哪个服务项目最受欢迎、哪个阿姨的完工率最高、哪些时间段的订单最集中。这些数据是从前完全没有的，或者说是散落在纸质记录里的。

这类系统适用的范围其实很宽。家政保洁只是预约业务里最常见的一种，凡是涉及“服务人员上门/到店服务”的场景，比如家电清洗、月嫂服务、宠物上门喂养、甚至是个人健身私教，都可以套用同一套预约模型。所以如果你在思考这个题目能带来什么影响，那就是一套可复用的“服务预约基础设施”，核心价值是标准化和数字化。

1.2 核心业务流程与角色权限划分

我最终把系统分成了三个端：用户端、阿姨端、管理后台。先看角色，再看流程。

用户端（C端）核心操作链路是这样的：注册登录 -> 维护服务地址 -> 选择服务项目 -> 选择服务日期和时段 -> 下单支付 -> 等待阿姨上门 -> 服务完成后评价。阿姨端（P端）更简单，主要就是查看被分配的订单、确认接单、开始服务、完成服务、查看自己的收入统计。管理后台（B端）则负责基础数据维护和运营管理，包括服务项目管理、阿姨信息管理、订单人工调度、优惠券管理、订单日志查看和报表统计。

权限设计方面，我采用的是RBAC（基于角色的访问控制）模型，用户、阿姨、管理员三种角色。后端接口统一做权限拦截，前端根据角色动态渲染菜单。这里有一个非常重要的经验：权限控制一定要在后端接口做，不能只靠前端隐藏入口。我在项目开发中就遇到过这样一个问题：前端把“阿姨修改订单状态”的按钮藏起来以后，以为安全了，结果测试时直接调用接口，发现接口只校验了登录状态，没有校验当前登录人是不是该订单的负责人，阿姨A就能改掉阿姨B的订单。这个问题最终通过增加“资源归属校验”才解决。

再理一下订单的核心状态流：用户提交预约单，生成待支付订单；支付成功进入待派单；管理员派单给阿姨，产生已接单状态；服务开始时间到达前后，阿姨点击开始服务，状态变为服务中；服务结束点击完成，状态变为已完成；最后用户评价，订单关闭。其中任何一步需要取消或异常介入，都要走单独的状态分支，不能在状态机上乱跳。这个状态机设计我放在后面的数据库和实现细节里重点说。

1.3 技术选型：为什么是SpringBoot+Vue

这个题目里点名了SpringBoot和Vue，那我就讲讲为什么这个组合适合家政预约类项目，而不是单纯“因为题目要求”。

SpringBoot最大的特点是起步快、约定优于配置。一个内嵌Tomcat的可执行jar包就能完整跑起来，部署成本极低，不需要额外安装Web容器。对于中小型项目来说，这能省掉很多环境问题。配合MyBatis-Plus操作数据库，单表CRUD几乎不用手写SQL，代码生成器一键生成实体、Mapper、Service，开发效率很可观。Vue前端生态在国内也非常成熟，PC后台用Element Plus，移动端H5用Vant，组件库开箱即用，而且社区资料丰富，遇到问题搜一下基本都能找到答案。

那为什么不推荐一上来就上Spring Cloud微服务呢？我见过太多项目把系统拆成了网关、用户服务、订单服务、支付服务、消息服务，最后脑袋全花在服务间调用和分布式事务上，业务本身却没做扎实。家政预约这个体量，大概率一台4核8G的服务器就能撑住日常访问量，单体应用加合理的表结构设计绰绰有余。选型永远要基于业务体量，而不是技术热度。类似的，为什么不用Go、Django或者PHP？不是说它们不好，而是对于需要快速招人维护、需要大量现成解决方案的传统业务系统，SpringBoot+Vue确实是最稳妥的选择之一。

2. 数据库设计与核心表结构

2.1 数据模型的总体思路

做表结构设计时，我习惯“从订单出发逆向推”。预约系统最核心的实体就是订单，先想清楚一张订单要关联哪些信息：谁下的单、在哪个地址、选了什么服务、约了什么时间、由哪个阿姨服务、收了多少钱、服务效果怎么样。围绕这些关系，用户表、阿姨表、服务项目表、用户地址表、时段表、评价表、优惠券表就自然出来了。

需要注意的一个设计决策是：不要把用户和阿姨放在同一张表里。虽然两者都有手机号、姓名、头像，但在业务上差异太大了。用户表要存常用地址、用户偏好、会员等级；阿姨表要存身份证照片、服务区域、星级评分、工作状态、提成比例。强行合成一张表，会凭空增加很多冗余字段和奇怪的判断逻辑。拆开以后，登录可以统一走账号体系表，业务表各自独立，代码里更清晰。

订单表我还做了一些“适度冗余”。比如订单里直接存服务项目名称、阿姨姓名、用户昵称、服务地址文本快照。有同事质疑过这种冗余，但在预约系统里，这其实是必要的。订单生成以后，如果后台修改了服务项目名称，或者阿姨改了昵称，历史订单不应该跟着变化，否则对账和客服处理历史订单时会非常麻烦。所以订单表里保存“快照字段”是业务需要，不是设计失误。

再说金额。订单金额必须在下单那一刻锁定，不能下单后因为服务项目调价而变化。很多初级开发者会把金额写成double，然后在计算优惠时出现各种精度问题。这个问题我下面会详细说，但先在表结构层面定调：所有金额字段一律使用DECIMAL(10,2)，Java里用BigDecimal接收。

2.2 关键表结构与状态设计

下面是我最终落地时用到的核心表清单：

这里重点说说时段表和服务时间的处理。我前后用过两种方案，第一种是在数据库只存service_date和start_time，由前端自己计算服务时长；第二种是预先把一天切成固定的大时段，比如“上午 08:00-12:00”“下午 13:00-18:00”“晚上 18:00-22:00”。家政保洁服务大多是按小时或按次购买，比如2小时深度保洁、4小时日常保洁，所以预生成大时段反而更好处理。

最终我采用的是第二种：用户选择日期后，前端展示可选时段，后端根据服务项目的时长自动计算可选择的开始时间。例如上午时段是08:00-12:00，用户买了2小时服务，就只能选08:00、09:00、10:00，选11:00的话服务结束会超过12:00，直接禁用。时段表里我再维护一个“当前可用”标记，后台可以临时关闭某个时段的预约，用于处理阿姨人手不足的突发情况。

订单状态字段我没用字符串，而是用TINYINT保存数字枚举。状态值定义如下：0待支付、1待派单、2已接单、3服务中、4已完成、5已取消、6售后处理中。每个状态对应一个枚举类，前后端通过枚举字典翻译成文字展示。状态流转必须遵循严格的状态机，比如待派单不能直接跳已完成，必须经过已接单和服务中。为了保证状态变更可追溯，我加了一张order_log表，每次状态变更都插入一条操作日志，记录操作人、操作类型和备注。这个设计在排查问题时帮了大忙，后面部署阶段还会提到。

2.3 时间字段、金额字段的坑

先说时间，这个可以说是预约系统里最容易出错也最隐蔽的坑。SpringBoot默认序列化LocalDateTime时，如果数据库连接串没有指定时区，很容易出现存进去的时间是UTC时间、前端查出来少8小时的情况。我在项目里做了三重保证：第一，数据库连接串显式配置serverTimezone=Asia/Shanghai；第二，SpringBoot全局配置文件里加上spring.jackson.time-zone=GMT+8；第三，实体里的时间字段统一用LocalDateTime表示，服务日期字段单独用LocalDate。

订单创建时间、支付时间、状态变更时间这类后端字段，我一般不靠手工new Date()，而是用MyBatis-Plus的自动填充功能，比如在create_time字段上标注@TableField(fill = FieldFill.INSERT)，配合一个MetaObjectHandler实现类统一填充。这样既减少重复代码，也避免不同开发人员写出的时间格式不一致。

金额字段就一句话：不要用浮点数。0.1 + 0.2在double计算中不等于0.3这种问题，在订单金额上会彻底放大。所有价格字段均使用BigDecimal，数据库用DECIMAL(10,2)。计算优惠时也要基于BigDecimal的setScale(2, RoundingMode.HALF_UP)，绝不能直接float/double运算后再转回来。如果将来对接微信支付、支付宝支付，金额单位是“分”，还要注意在DTO层做转换，避免前端显示“0.1元”而后端却收到“1分”的错位问题。

3. 后端核心实现细节（SpringBoot）

3.1 分层架构与统一返回体

后端我采用最经典的分层结构：Controller、Service、ServiceImpl、Mapper。Controller只负责接收请求参数、调用Service，再包装返回值；所有业务判断都放在Service层。这样做的好处是，Controller非常薄，Service可以单独写单元测试，后面接消息队列、写定时任务时也能直接复用Service里的逻辑。

统一返回体是每个接口遵守的约定。我定义了一个泛型类R<T>，包含code、message、data三个字段，约定code=200表示成功，非200都是业务失败。全局异常处理我用了@RestControllerAdvice，针对参数校验异常、业务异常、未知异常分别返回不同的错误码和提示信息。这样前端处理逻辑就非常简单：axios响应拦截器里判断如果code !== 200，统一弹出错误提示，不需要每个页面自己写一遍。

再强调一点：参数校验不能只在Controller层做。实体上加了@NotBlank、@Size这些JSR 303注解，并在Controller里开启@Validated，这只能解决基础格式问题。业务层面的校验，比如“服务地址是否在阿姨的服务区域内”“优惠券是否已过期”“用户是否同时存在未完成订单”，必须在Service里做二次校验。我就踩过只依赖参数注解的坑，结果用户提交了一个超出服务范围的地址，订单直接进入待处理，后台人工盯了很久才处理掉。后来我把服务区域范围做成了配置项，在Service层统一校验，才彻底解决。

3.2 预约冲突与防重提交设计

预约系统里最核心的并发问题是：同一时段同一阿姨不能被重复预约。初期我用的思路是“先查时段是否空闲，再插入订单”，结果测试阶段就有两个请求几乎同时提交，都查到空闲，最后生成两笔订单，同一阿姨同一时段被约了两次。这就是典型的并发竞态问题。

解决方式我推荐用数据库唯一索引兜底。我加了一张order_schedule_lock表，唯一索引建在(keeper_user_id, service_date, time_slot_id)上。下单事务里先尝试插入一条“锁定”记录，如果插入失败，说明该时段已经被占，直接抛业务异常“该时间段已被预约”。利用数据库唯一索引的原子性，可以非常可靠地防止并发冲突，而且不依赖额外的Redis。如果项目里本身有Redis，也可以用SETNX key value做分布式锁，但要处理锁过期时间的问题，复杂度会高一些。对于家政预约这个体量，唯一索引方案反而是最稳固的。

另一个高频问题是用户重复点击提交订单。前端虽然会把按钮置灰，但总有人通过快速刷新、返回页面等方式绕过前端限制。我的处理方式是：在用户点击下单时生成一个request_id（或叫origin_token），把它随请求传给后端，订单表里对origin_token建立唯一索引。如果同一请求ID被提交两次，第二次会因为唯一索引冲突直接返回“请勿重复提交”。这个方案在整个系统里非常实用，支付回调去重也是类似的思路。

3.3 定时任务与订单生命周期提醒

家政服务对时间敏感，订单状态不能全靠用户手动变。我写了一个OrderScheduleTask，用SpringBoot自带的@Scheduled每1分钟扫描一次，处理三类问题：

第一类是超时未支付订单，规则是状态为待支付且创建时间超过15分钟，自动把订单改为已取消，同时释放时段占用。第二类是服务开始前提醒，规则是状态为已接单且预约时间接近开始时间（比如提前1小时），为用户推送站内消息和第三方短信。第三类是异常超时单检测，规则是服务开始时间已经超过2小时，订单仍处于已接单状态，系统自动标记为异常单，通知管理员介入。

定时任务的扫描SQL需要注意加LIMIT，一次只处理一批数据，不要一次捞全表。比如“待支付超过15分钟”的清理任务，每次只取出100条，处理完再扫描下一批，避免数据库压力过大。同时，给status、create_time、service_date这几个字段建好联合索引，不然全表扫描会拖垮MySQL。

这里还要讲一个幂等设计。定时任务扫描到“应该发送提醒”的记录后，我们不要直接在任务里调用短信接口。正确做法是先插入一条消息记录表，标记为待发送，再由异步任务去发送并更新状态。消息发送表里用biz_type + biz_id做唯一约束，这样即使任务重复扫描，也不会重复发短信。我有一次就是因为没做这一步，短信服务商重试了一次，用户收到了两条一模一样的“服务即将开始”的提示，体验很差。

3.4 接口安全与参数校验

接口安全方面，我做了几个层级。第一层是登录认证，使用JWT令牌，用户登录成功后在Header里携带Authorization: Bearer xxxx，后端通过拦截器解析令牌中的用户ID和角色。JWT密钥不能写在代码里，我放在了application.yml外部配置中，并计划后续迁移到环境变量。第二层是权限校验，不同角色的接口需要在注解或代码里显式声明允许访问的角色，比如管理后台的阿姨管理接口只允许管理员访问。

第三层是资源归属校验，这个最容易忽略。在阿姨修改订单状态、用户查看订单详情时，必须判断当前登录人是否属于该订单关联的对象，否则就会出现越权操作。我当时写了一个@RequireOrderOwner的注解，在进入Controller前置判断当前用户是否为订单的所属用户或所属阿姨，省得每个接口里都重复写一遍判断逻辑。

参数白名单校验也很重要。比如接收订单状态时，不要直接接收Integer再入库，先用枚举的fromCode方法校验状态值是否合法，防止脏数据进入。文件上传功能要限制扩展名和文件大小，我见过通过上传恶意文件想要获取服务器权限的案例，所以在实际项目中上传接口都做了白名单和大小限制。另一个安全细节是生产环境要关闭Swagger文档，线上接口文档裸奔等于把攻击面送给人看。可以通过Spring Profile做到开发环境开启、生产环境关闭。

4. 前端Vue实现要点

4.1 项目组织与动态路由权限

前端我拆成了两个独立项目：用户端是Vue3 + Vant构建的移动端H5，后台工作台是Vue3 + Element Plus构建的PC端。两个项目放在同一个Git仓库但用不同目录管理。有人可能想合并成一个项目，用路由区分移动端和PC端，但我的体验是：两者使用的组件库、页面布局、接口粒度差异很大，拆开以后维护成本更低，上线部署也是两套Nginx目录，互不干扰。

后台工作台的权限路由设计比较关键。后端登录接口返回当前用户的角色和菜单权限列表，前端拿到后通过router.addRoute动态注册路由。这里有个非常容易踩的坑：如果只在用户登录后一次性动态添加路由，刷新页面时Vue Router已经初始化完成，动态路由就丢失了，直接访问一个二级页面会出现404。解决方案是在全局前置守卫里判断“路由是否已经初始化过”，如果没有，就先调用获取菜单接口重新注册路由，再放行本次导航，否则直接放行。

菜单权限的粒度我控制在“页面级”和“操作按钮级”。页面级通过动态路由控制，操作按钮级通过指令或全局方法控制，比如没有“派单权限”的管理员，页面上“派单”按钮不渲染。但要注意后端接口也要同步校验，不能只靠前端控制按钮显示。

4.2 用户端核心页面：日历预约与下单流程

用户端最核心的流程是“选服务 -> 选时间 -> 填地址 -> 确认订单 -> 支付”，这个流程我拆成了多个步骤，用Vant的Steps组件展示进度。

选时间这一步，我们用的是日历组件，默认禁选今天之前的日期，并且通过后端接口获取每个日期可预约的时段余量。接口按月份返回，比如/api/calendar/getMonthlySchedule?year=2025&month=6，返回该月每天每个时段的余量状态。前端渲染时把已经约满的时段置灰。当用户切换月份时再重新请求，避免一次性加载全年数据。

下单流程中有一个非常考验细节的地方：用户选了服务项目之后，可选的开始时间要动态计算。假设用户选的是2小时服务，而时间段是固定的上午、下午、晚上三大时段，前端必须根据服务时长计算可选开始时间。比如上午段是08:00-12:00，2小时服务可以选的开始时间是08:00、09:00、10:00，11:00开始会超时，需要禁用。这种计算逻辑前端要做，后端在提交订单时也要做。如果只在前端控制，别人通过直接组装接口请求就能绕过限制，最终会产生时间重叠的脏数据。

订单填写的每一步数据都存在Vuex/Pinia里，最后提交时一次性组装请求参数。有一个容易忽略的交互：用户修改了服务地址后，之前选择的时段可能已经不在新地址的服务范围内，或者服务项目本身在该地址不可用。这时候需要监听地址变化，重置时间和服务项目选择，并重新请求可约时段。我一开始没做这个监听，上线后用户反馈“我改了地址，怎么原来那个时段还能选”，查了一下才知道是地址变动没有联动重置。

4.3 前后端联调与接口管理

前后端联调最怕的是字段对不上。项目一开始我就定了接口文档规范，要求所有接口在Swagger/OpenAPI里维护，并且前后端都以此为唯一依据。字段命名统一采用小驼峰，例如serviceDate、keeperUserId。订单状态值在前端不做魔法数字判断，而是通过公共枚举字典转换。

请求统一封装在src/api目录下，按照模块划分文件。axios实例配置了基础URL和请求拦截器，请求时自动带上token；响应拦截器统一处理错误码，当code !== 200时自动弹出Toast或Message提示，页面业务代码里不需要重复处理错误分支。

本地联调时的跨域问题也值得说。前端开发服务跑在8080端口，后端跑在8081，如果不处理，浏览器会拦截请求。我的办法是同时在后端配置CorsMappings，允许本地开发端口跨域；前端Vite配置里也设置server.proxy，把/api开头的请求代理到http://localhost:8081。生产环境则直接由Nginx通过同一个域名提供服务，前端静态资源放在Nginx的html目录，location /api反向代理到后端服务，从源头上规避跨域问题，也便于后续在Nginx层做限流。

5. 实操过程与踩坑实录

5.1 从0到1的初始化顺序

我做一个新项目的初始化顺序是固定的：先建库建表，再写后端，再写前端。有人喜欢先搭前端页面再mock接口，但我觉得对于业务逻辑复杂的系统，还是应该先把数据库和接口稳定下来，前端才能有真实的字段可以参考。

具体操作顺序是：第一步，用Navicat或直接写SQL脚本创建数据库表结构，字符集用utf8mb4，排序规则用utf8mb4_general_ci。建表时一定把字段备注写全，因为这会影响后续代码生成器生成的Java注释和Swagger文档注释。第二步，用MyBatis-Plus代码生成器生成entity、mapper、service等基础工程代码，然后手写业务Service。第三步，在Controller里写接口并用Swagger调试。第四步，开发前端页面，对接真实接口。

环境版本上我推荐一个比较稳的组合：SpringBoot 2.7.x、JDK8或JDK11、MySQL5.7或MySQL8.0、Vue3 + Vite + Element Plus + Vant。不建议一上来就用SpringBoot 3.x，因为3.x要求JDK17，很多老项目的依赖、插件、云厂商的部署环境不一定兼容，折腾环境的时间可能比业务开发时间还长。

代码生成器生成的实体里，我建议加上逻辑删除字段deleted，默认值为0，所有删除操作都走逻辑删除而不是物理删除。管理后台经常会需要“恢复误删数据”或者查看历史数据，逻辑删除能保留完整痕迹。数据库表里还要有create_time、update_time两个自动填充字段，这个在MyBatis-Plus里通过MetaObjectHandler统一处理。

5.2 真实项目里遇到过的问题清单

下面这些问题是实际开发中真实遇到过的，我整理成了一张速查表，对做同类系统的人应该很有参考价值：

其中“MySQL连接数被打满”这个问题，我记得是某次报表导出功能没有经过分页查询，导出全部订单时一次性查了十几万条数据，直接把数据库拖挂了。后来在导出功能里加了分批查询，并且把导出任务放到线程池里异步执行，数据库才算稳下来。这类“技术账”都是上线后压力测试才能暴露出来的，提前在代码层面养成限制查询规模的意识很重要。

5.3 部署阶段的注意事项与实践心得

部署我用的是一台2核4G云服务器，安装JDK8、MySQL8、Nginx和Maven。后端项目打成分层jar包，用systemd配置开机自启，日志重定向到/var/log/app/order.log。前端项目执行npm run build后把产物上传到/usr/share/nginx/html，再在Nginx配置里添加反向代理规则：location /api/ { proxy_pass http://127.0.0.1:8081/; }。

生产环境一定要把Swagger接口文档关掉。通过Spring Profile区分环境，生产环境不加载Knife4j或Springfox的配置。否则任何一个懂技术的人都能通过/swagger-ui.html看到你所有接口的参数和结构，这对一个真实上线的系统来说是很可怕的信息暴露。另外，正式环境的数据库账号不要用root，创建一个专用账号，只授予应用所需库的SELECT/INSERT/UPDATE/DELETE权限，尽量减小被攻击后的影响。

数据库备份我写了一个crontab脚本，每天凌晨3点执行mysqldump全库备份，保留最近7天备份文件。有一天备份突然失败，排查发现是磁盘满了。后来在脚本里加了磁盘空间检查，如果剩余空间低于10%就发送告警通知，同时清理更早的备份文件。很多小团队做这个类型的系统往往忽视运维，我的实际感受是：“上线前先把备份脚本和重启脚本写好，不然半夜数据库出问题，全靠记忆手动敲命令，人真的会崩溃。”

最后再聊一个管理层面的心得。后台管理端确实需要“人工改状态”的便利，比如客服要帮用户取消选错的订单，但每次改状态都必须记录原因。我实现了一个订单日志功能，每次状态变更都在order_log表插入一条记录，包含操作人、操作类型、备注。后来运营人员问我“某笔订单怎么突然变成已取消”，直接查日志就能定位到是误操作还是用户要求，不用再靠聊天记录去猜。这个功能代码量不大，但对长期运维的价值非常高。

6. 系统应用场景与可扩展方向

6.1 从家政保洁复制到更多预约场景

做完这个项目之后，我最大的体会是：家政保洁预约系统本质上是一套“服务预约引擎”。换一个行业，只需要改掉服务项目表里的商品字段、调整时段划分规则、增加对应的业务属性，系统骨架完全可以复用。

比如家电清洗，除了预约时间和地址，还要用户填写品牌型号，这时候给order_info表增加一个extra_infoJSON字段就能解决；宠物上门喂养，用户可能需要上传门锁密码、宠物喂食说明，可以在订单里增加一个“服务备注附件”功能；私教预约则更需要强调“指定服务人员”，这时候阿姨端可以增加“可接单时段设置”功能，让每个教练自己维护档期。这些扩展点都建立在核心预约流程稳定的基础上，说明这套设计的影响范围其实很广。

6.2 下一步可以做的优化方向

如果这个系统要持续演进，我下一步会做这些优化：第一，引入消息队列处理短信、站内信等异步通知，降低定时任务和订单接口的耦合；第二，把“阿姨排班”做成可视化日历，管理员可以直接在日历上拖拽调整阿姨的休息日和可接单时段；第三，增加更细粒度的权限控制，比如管理员只能查看自己管辖城市的订单；第四，增加运营报表页面，用折线图展示每日新增订单、完工率、销售金额等核心指标；第五，把支付从模拟支付切换到真实的微信支付/支付宝支付，处理好回调幂等和异常退款。

这些优化并不复杂，但每一步都能明显提高系统的实用价值。对于做毕业设计或接私活的朋友，不用一下子全部做完，先保证主流程完整、能跑、能演示，再挑一两个亮点功能深入下去，效果会好很多。毕竟这类系统的核心价值不是技术数量，而是把预约这件“小事”真正做顺。