企业官网建设流程全解析

1. 项目概述

先交代一下背景：电脑维修门店每天接到的需求，无非是“帮我看看这台电脑为什么这么卡”“我要配一台能跑3D建模的机器”“翻盖坏了想换屏”。问题本身不复杂，但真正让店主头疼的是——这些需求没有统一入口，用户微信打电话轮流轰炸，维修工出工没计划，商家报价靠嘴传，最后账目还要手工对。忙起来一片混乱，漏单、错单、客户等不及跑了，几乎每周都在上演。

所以这个项目的目标很明确：做一个以预约为主线的多角色管理平台，把“用户提交需求 -> 管理员派单 -> 维修工接单处理 -> 商家提供配件报价 -> 用户确认付款评价”这条链路完整跑通。角色划分为用户、维修工、商家、管理员四类，每个人在系统里看到的东西、能做的事，都严格区分开。

分享这个项目，是因为它足够典型。它不是那种单页面炫技Demo，而是一个有真实业务逻辑、有状态流转、有权限控制的完整系统。不管你是想练手全栈开发的学生，还是门店老板打算把自己的生意数字化，或者只是对多角色系统设计感兴趣的开发者，这个项目的拆解思路和实现细节，都可以直接拿去用。

先放一张项目耗时参考：我实际从零开发到上线，前后用了一个半月左右。每天大概四五个小时投入，技术栈选的是前端Vue、后端Spring Boot、数据库MySQL和Redis，部署用一台普通云服务器。后面每一部分的选型理由，我会在对应章节详细说明。

2. 整体设计与角色权限拆解

2.1 四类角色的边界划分

做多角色系统，第一件事不是写代码，而是把每个角色的权限边界画清楚。我见过太多项目，一开始角色就三个，写着写着发现还需要第四个，然后开始给用户表加字段加角色判断，改到最后面目全非。所以我在需求阶段就花了大量时间梳理这个问题。

这个系统里四类角色，各自的核心诉求完全不同：

• 用户：核心诉求是“快速提交需求、看到进度、不被坑”。用户不需要知道维修工是谁，不需要看到商家报价的底价，只需要知道机器什么时候能修好、要花多少钱。
• 维修工：核心诉求是“接到靠谱的活、按时上门、不被客户放鸽子”。维修工最关心的是任务的时间地点、故障描述是否清楚、配件是否到位。
• 商家：核心诉求是“有稳定的配件订单渠道、报价能被合理采用”。商家看到的应该是配件需求清单，而不是完整的用户个人信息，毕竟有些用户不愿意被推销骚扰。
• 管理员：核心诉求是“掌握全局状态、避免失控”。管理员要能看到所有订单、所有角色、所有结算，还要能处理异常（比如维修工临时请假、用户投诉）。

权限设计就基于以上诉求做了矩阵。

这张矩阵表我建议每个做多角色系统的朋友都先画一遍。画完之后你会发现，很多模糊的地方一下子就清楚了。比如维修工能不能看到用户的电话号码？按矩阵是“不可见详细”。实际操作中，维修工需要联系电话才能上门，所以我在具体功能上做了一层脱敏——维修工看到的是中间四位打星号的号码，只有点击“确认接单并上门”时，系统才临时开放完整号码。这样既保证流程顺畅，又防止维修工私下留存用户信息。

2.2 为什么采用“用户-订单-任务-配件”四层业务模型

很多初学者设计表结构时，习惯把业务直接挂在用户表下面，比如“用户表 + 订单表 + 配件表”，商家和维修工共用一张用户表，靠role字段区分。这样确实能跑通，但后面统计和流转会出现大量if-else。

我采用的是四层拆分。用户表只存账号和基础资料；订单表存一次完整的服务请求，比如“用户A要求给台式机升级固态硬盘”；任务表则存具体的执行单元，比如“维修工B上门拆机”“维修工C负责装系统”；配件表存商家报价的配件清单。订单和任务是一对多关系，一个订单可以拆成多个任务，分别派给不同的人。

为什么要这么拆？举一个真实场景：用户报修“电脑不开机”，管理员接到之后发现故障描述不清晰，先派一个维修工上门检测。检测结果是内存条坏了，需要更换。这时候就要追加一个购买配件的任务给商家，同时维修工还要等配件到了之后再上门一次。前后两次上门，加上一次配件采购，就是三个不同任务。如果这些全堆在订单表里，那订单表要炸。

四层模型还有一个好处，就是统计口径清晰。月底算维修工绩效时，不用去订单表里模糊匹配，直接从任务表按完成时间过滤就行。算商家配件利润时，从配件表按订单时间范围汇总即可。每个对象只负责各自领域内的数据，避免跨领域扯皮。

2.3 技术选型与为什么这么选

前端选了Vue + Element UI，后端Spring Boot，数据库MySQL存储主数据，Redis做会话和缓存。这套组合不算新潮，但胜在稳定与效率。

Vue的原因大家都能理解，组件化开发在管理员后台那种大量表单和表格的场景特别好用。Element UI虽然被吐槽过重，但毕竟是成熟方案，表格排序、分页、表单校验都现成，省了我大量造轮子的时间。

Spring Boot就不多说了，Java生态在后端确实稳，尤其面对这种体量不大的管理系统，基本零维护成本。我唯一想提醒的是，一定要用MyBatis-Plus，能把大部分单表CRUD写好的时间直接砍掉一半。配置设备推荐和价格计算这种相对复杂的查询，再手写SQL也来得及。

MySQL和Redis的配合值得说两句。MySQL存一切结构化数据，Redis主要放三样东西：登录会话Token、设备配置推荐的缓存结果、预约时间段锁。前两个好理解，第三个是预约系统最容易出问题的点。用户选了下午3点到4点这个时间段，在用户确认前，这个时间段应该被临时锁定，否则两个用户同时选中就会撞车。用Redis的SETNX命令做分布式锁，过期时间设为10分钟，正好覆盖从选中到确认的完整操作窗口。用户超时未确认，锁自动释放，其他用户才能预约这个时间段。这个小机制解决了我之前用纯MySQL做预约时遇到的并发冲突问题，实测下来非常可靠。

3. 核心需求分析与流程引擎设计

3.1 配置文件推荐模块的规则拆解

“电脑设备配置推荐”是这个系统里最容易被当成噱头，但实际最有技术含量的模块。因为配置推荐不是简单罗列几套方案，而是要根据用户输入的预算、用途、品牌偏好，动态生成合理搭配。同样的预算，拿来打游戏和拿来剪视频，CPU和显卡的投入比例完全不同。

我把推荐逻辑拆成三层规则：

第一层是场景分类。用户提交需求时，先在表单里选择主要用途：办公、游戏、设计、编程、家用影音。这个场景选择直接决定后续各组件的权重分配。办公场景CPU权重高，显卡权重几乎为零；游戏场景显卡权重拉到最高，内存和CPU也相应提升；设计场景显卡和内存并重，因为渲染和实时预览都要吃显存和内存；编程场景CPU核心数和内存容量优先，大内存跑虚拟机、编译、容器都有明显体验提升；家用影音则均衡分配，不必追求单点性能。

第二层是预算切分比例。我通过大量调研电商平台和线下渠道报价，总结了一套初期可用的比例模板，再通过后续真实配件价格数据逐步校准。游戏机预算比例大致是CPU 20%、显卡35%、主板12%、内存10%、硬盘8%、电源10%、散热5%。设计机则是CPU 25%、显卡30%、主板10%、内存15%、硬盘8%、电源7%、散热5%。办公机CPU占比可以放到30%，显卡只在预算充足时加上一张廉价亮机卡。

第三层是价格校验与组装。所有配件价格加起来必须落在用户预算的正负5%区间内。超了就逐级降配，低了就推荐同系列更高一档的CPU或显卡。每套配置生成后，系统会同步展示整机预估功耗和所需电源功率，避免出现配件配了一堆，电源带不动的低级失误。

这套规则我建议你务必在数据库里存成可配置表，不要把规则写死在Java代码里。因为配件价格每月都在变，商家报价也会浮动，如果每次调价都要改代码发版，那运维成本太高。我设计的方案是t_part_price表里存配件的品类、型号、当前报价、权重标签，规则引擎启动时一次性加载进内存，后台管理页面可以直接编辑。每天凌晨用定时任务校准一次价格基线，管理员看到的价格永远是最新的。

3.2 预约流程的状态机设计

预约系统最核心的就是状态流转。用户提交需求后，系统的状态不能是简单一个字段“进行中”，那样后续退款、投诉、结算都会变成一团乱麻。我设计的状态机共有八个状态，每个状态之间的迁移条件非常明确。

八个状态分别是：待审核、待派单、待上门、维修中、待付款、待评价、已完成、已取消。用户提交需求后，默认进入待审核。这个审核动作由管理员完成，主要目的是过滤垃圾需求——比如用户填的预算明显低于市场价、故障描述完全空白，管理员有权限打回让用户补充信息。审核通过后进入待派单，管理员根据用户填写的地址和小区的收件范围，圈定候选维修工列表，派单给最合适的那个。

维修工收到任务通知后，有两种操作：接受或拒绝。接受则状态跳转为待上门，这时维修工的电话对用户可见。拒绝则任务回到待派单池，由管理员重新分配。这是个很实用的设计，不然硬派给一个正在忙的维修工，反而耽误用户时间。

维修工到达现场开始检修，把状态切换为维修中。检修结束后，维修工在App端提交维修结果，填写实际更换的配件和人工费用，系统生成待付款账单推送给用户。用户确认账单并在线支付后进入待评价状态。用户评价完成，整个订单状态变为已完成。任何一端在过程中主动放弃，比如用户申请取消、维修工报备异常，订单进入已取消状态，同时记录取消原因，供管理员事后回溯。

为了保证状态机不被人为搞乱，我在后端代码里做了一个状态迁移校验表，其实就是一个Map，key是当前状态，value是可迁移到的新状态列表。每次状态更新时先去查这个表，迁移关系不合法就直接抛出异常。这个方法虽然简单，但比在每个Service方法里写一堆if判断要清晰得多。

3.3 预约时间段的碰撞处理

这个系统涉及“预约”，就必然有时间段的概念。硬件维保店工人少，一天能跑的单子有限，时间段如果不锁好，客户约了同一个人同一个时间，就必然有一方要落空。我的处理方案是：时间段数据放在专门的时间轴表里，维修工每天按固定班次开放预约，每个时间段默认30分钟。用户选择时间段时，前端只能看到未被锁定和被预留的时段。

真正考验技术的地方在“防超卖”。我用了Redis分布式锁配合MySQL唯一索引双保险。用户在某个时段提交预约时，后端先尝试SETNX锁定时间段，锁住了再插入订单记录。订单表里（维修工、时段、日期）三个字段联建唯一索引，如果插入时出现DuplicateKeyException，说明这个时段已经被人占了。为什么需要双保险？因为Redis在极端情况下可能主节点故障导致锁丢失，数据库唯一索引的兜底能保证无论如何数据都不会重复。实际运营中也确实遇到过Redis宕机的场景，唯一索引挡住了脏数据，可见这个设计不是过度设计。

4. 实操实现：从数据库建模到核心接口代码

4.1 数据库表结构设计实践

数据库表我总共建了11张，核心业务表是6张。每张表的字段设计都有值得说的地方，我挑最有代表性的三张展开。

用户表t_user，除了常规的账号密码手机号之外，我额外加了一个user_type字段和belong_shop_id字段。user_type依然区分四种角色，belong_shop_id是商家或维修工所属的门店ID，这样管理员可以按门店维度去筛数据。密码字段存的是BCrypt加密后的哈希值，不是明文，也不是简单的MD5。BCrypt每次加密结果都不同，安全性远高于MD5和SHA系列，防止彩虹表暴力破解。登录时用BCrypt的matches方法校验，成本因子设置为10，兼顾安全性和登录速度。

订单表t_order，核心是order_status、user_id、assignee_id、appointment_time这四个字段。其中appointment_time存的是一个JSON字符串，包含开始时间和结束时间。有人可能会问为什么不拆成两个datetime字段，我解释一下：因为这个预约时间在不同角色眼里的语义不同，用户看到的是“下午3点到4点”，维修工看到的是“15:00-16:00（预计1小时）”，管理员看到的是“该时段已被占用，建议顺延”，一个JSON结构能覆盖这三种展示需求，而且订单量大起来之后，按JSON字段做筛选在MySQL 8.0以上可以用JSON_CONTAINS函数，性能尚可。

配件表t_part，字段包括part_name、part_category、part_price、in_stock、part_image_url。重点关注的是part_category，这个字段存的是“CPU、GPU、主板、内存、硬盘、电源、散热器、机箱”这种层级分类的枚举字符串。为什么不用关联表？因为配件分类是固定集合，不需要频繁扩展，用枚举字符串反而查询更快，写入更简单。

MySQL建表时我用的字符集是utf8mb4，排序规则是utf8mb4_unicode_ci。用utf8mb4是因为它支持完整的Unicode，包括emoji和生僻字，比如用户维修备注里写“主机风扇🌀异响”，如果库里存的只是utf8mb3（MySQL的utf8其实是3字节），这个emoji就会变成乱码，甚至直接写入失败。这是很多人容易踩的坑，我早期项目就因为这个丢过用户提交的备注内容。

加索引的时候，我遵循一个原则，就是查询能覆盖就覆盖，不要为了理论上可能用到的查询乱加索引。实际最频繁的查询是“查询某个用户的所有订单”“查询某个维修工的待接单任务”“按时间段查询可派单维修工”，所以我给t_user表的id加了主键索引，给t_order表加了user_id和assignee_id两个普通索引，再给appointment_time字段加了普通索引。where条件里还经常用到order_status过滤，但我没有给order_status单独建索引，因为枚举值数量很少，选择性太低，索引优化器根本不会走，反而白白增加写入开销。

4.2 核心功能模块的接口实现

后端按照常用分层方式拆包：controller、service、mapper、entity。每个模块的接口设计遵循一个非常原始的套路——开一个Restful API入口，内部调用Service层处理业务逻辑，Mapper层只做SQL交互，entity只承载表的ORM映射。这种分层方式在老手眼里很基础，但新项目没有历史包袱时，基础就是最稳的。

我选三个最核心的接口，把代码逻辑讲清楚。

第一个是设备配置推荐接口，POST /api/config/recommend。请求体长这样：

{ "budget": 6000, "usage": "game", "brandPreference": null, "needMonitor": false }

Service层的实现逻辑是这样的：先加载配置规则里当前场景的组件权重表，然后根据预算算出各组件的预算金额。用预算金额去t_part_price表里筛选候选配件，候选条件是该品类价格小于等于组件预算的1.15倍，这样留出一些浮动空间。全部候选拉出来之后，做一个简单的选型匹配——在满足兼容性的前提下，尽量选价格靠近预算上限的。最后校验总价是否在预算的±5%区间内，不在就降档循环调整。整个逻辑用Java代码写大约是200行，核心就是循环匹配和价格校验，不存在高深的算法。

第二个是预约提交接口，POST /api/order/appointment。这个接口内部要做三步：第一步查Redis锁，看目标时段是否可用；第二步写入t_order表，状态初始为待审核；第三步异步通知管理员，新订单待审核。三步走完之后，如果Redis锁没抢到，直接返回“当前时段已被预约，请选择其他时段”。写库成功但异步通知失败时，不需要回滚订单，因为管理员登录后台能看到全部订单，通知只是辅助提醒。

第三个是订单状态更新接口，PUT /api/order/status。这个接口有一个特别容易被忽略的参数：expectStatus和nextStatus。调用方必须同时传期望的当前状态和要变更为的目标状态，后端先比对当前状态，一致才执行更新，否则返回状态冲突。这个设计被很多开发者认为是多此一举，但恰恰是它挡住了并发请求下的脏更新。举个例子：用户和维修工同时操作同一个订单，用户点了取消，维修工点了完工，如果只有一个状态字段，最终写库结果由最后执行的SQL决定，逻辑上可能就出现“已取消的订单又完成了”这种怪现象。加了expectStatus做乐观锁，后执行的一方必然失败，从而保护了状态机的一致性。

接口返回格式统一为：

{ "code": 0, "message": "success", "data": {} }

code为0表示成功，非0表示业务异常。这套格式我用了很多年，简单直接，前端axios拦截器对于code非0的情况直接弹错误提示，几乎不需要额外封装自己的错误处理逻辑。

4.3 前端页面的关键交互与实现细节

前端我按角色做了四个独立布局，共用一个路由框架。用户端重点在于表单提交和历史订单，维修工端重点在于任务列表和预约日历，商家端重点在于配件报价单和订单查询，管理端则是权限最高的一站式后台。

用户提交需求表单时，有几个细节我处理得比较精细。一个是配置推荐表单里，预算用了滑块加数字输入框的双控件，滑块方便快速调整，数字框可以精确输入，两个控件双向绑定同一个变量。一个是用途选择用了卡片式单选，每个选项配一张小图标加一行说明，比普通的下拉选择框直观很多。还有一个是上传图片功能，给用户上传电脑故障照片和电脑序列号照片，前端用el-upload组件，上传前用JavaScript做了大小校验（限制单张不超过5MB）和格式校验（jpg、png、webp），超过大小直接前端拦截，不让请求打到后端占用带宽。

维修工端的预约日历，我用的是fullcalendar这个日历库，每周或每日视图都可以切换。每个时段格子上会显示三种状态颜色：绿色代表可预约，灰色代表人已被约满，红色代表已锁定不可约。维修工不接受派单的时候，可以把对应时段手动置灰，这样管理员派单时系统自动过滤掉这些时段，避免无效派单。

管理端的订单管理表格，数据量实测上万条之后，分页查询有明显卡顿。我的优化方案是后端分页只返回当前页数据，前端表格只绑定当前页数组，不做全量加载。配合El-table的懒加载和虚拟滚动设置，一万条订单数据翻到最后一页也就是200到300毫秒，完全可接受。

5. 常见问题与解决方案实录

5.1 并发抢单导致数据错乱

这是我开发过程中遇到的第一个硬骨头。系统里维修工抢单的功能，在第一时间没有加任何并发控制，直接UPDATE订单表把status从待派单改成已接单。上线测试时我用两个测试账号同时抢一个订单，结果状态更新成功了两条记录。虽然业务上不会两个人同时修一台电脑，但一旦发生，维修工端的展示和通知都会错乱。

解决方案是给订单加一个lock_version字段，更新时用乐观锁机制。每次更新前先SELECT当前版本号，UPDATE时在WHERE条件里带上“版本号等于旧值”，如果受影响行数为0，说明版本号已被别人改过，本次更新无效。代码层面捕获这个条件后，直接返回“手慢了，订单已被接走”。这个方案不需要引入额外的分布式锁中间件，实现成本极低，实测能挡住99%以上的并发冲突场景。

5.2 配置推荐结果与商家实际报价不一致

配置推荐模块上线后，用户确实能收到一套看起来合理的主机配置单，但点进商家配件报价页面时，发现系统推荐的是RTX 4060，商家报价清单里最接近的却是RTX 4060Ti，差了小一千元。这个问题出在推荐引擎没有对接商家实时库存和报价数据，用的是一周前缓存的价格。

我的修复方案是：推荐动作触发的同时，异步拉取商家最新配件表，商家改价或下架配件时，通过消息队列推送变更事件到推荐引擎，引擎收到事件后重新计算受影响的配置单，并把旧配置自动标记为“价格可能已变动，建议重新推荐”。如果用户已经下单，则系统拦截支付前确认环节，让用户重新选择。这个机制上线后，因为价格问题被投诉的单量直接降到了零，所以提醒做类似系统的朋友，推荐算法固然重要，但数据新鲜度永远是用户体验的生命线。

5.3 多角色权限越权的防护

多角色系统因为权限判断写漏，导致用户能看到维修工手机号、商家能看到用户家庭住址的事，太容易发生了。开发时接口多了，随手漏掉一行鉴权代码，线上排查就要花几个小时。

我的防护方案有三层。第一层是Spring Security的注解鉴权，每个Controller方法上加@PreAuthorize("hasRole('USER')")这类注解，从入口处就拦截不合法的角色访问。第二层是数据范围过滤，在Service层查询时强制加一个当前用户的数据范围条件。比如维修工查询订单列表，SQL条件里必然带上assignee_id = 当前登录用户ID，这个条件不是前端传的，而是后端从SecurityContext的当前登录用户信息里取出来的，前端无法伪造。第三层是响应字段脱敏，用户信息实体类上加了Jackson注解，凡是标记为脱敏的字段在序列化到维修工端和商家端时，自动输出掩码后的字符串，只有管理员端点配置了白名单，可以看到完整数据。

这三层下来之后，我再也没有被权限问题困扰过。建议所有开发多角色系统的人，不要等到被甲方投诉了再补权限，而是在第一版设计时就把数据范围规则画进表结构里，后面会省下大量返工时间。

5.4 消息通知不及时导致订单流失

老版本的系统通知依赖管理员每隔几十分钟手动刷新后台看有没有新订单，用户体验当然不好。后来我接了一个WebSocket推送通道：订单状态发生任何变化时，后端向相关角色推送一条WebSocket消息，前端收到后弹提示框并播放提示音。

WebSocket接入要注意断线重连机制。我在前端用了一个心跳组件，每30秒发送一次ping，服务器返回pong。如果超过60秒没收到pong，就判断连接已断开，自动重连。这个机制看起来不起眼，但实际使用中确实遇到过维修工在工地信号差、WebSocket断开的情况，如果没有心跳重连，维修工就会一直收不到新单提醒，直到自己手动刷新页面才发现。

5.5 常见问题速查表

我把运营期间被问到最多、排查过程中踩过的坑整理成一张表，直接看比翻阅代码快得多。

6. 项目带来的影响与后续扩展建议

这个系统在我实际运营的电脑维修门店里跑了三个月，相当于是从纸上谈兵变成了每天处理真实订单的工具。我拿试运行期间的数据做过一次对比：接入系统前，每天电话和微信接单大概十几单，一半以上要反复沟通地址和时间；接入后，用户在线提交需求，管理员统一审核派单，平均每一单从提交到维修工接单的时间缩短了大概70%。因为时间冲突导致的上门扑空几乎不再出现，唯一一次还是因为维修工个人临时有事，但这个流程里管理员可以提前在后台改派，影响被控制到了最低。

商家端的报价入口也带来了实际收益。以前配件询价要一家一家打电话比价，现在用户提交配置需求后，系统自动把配置推荐单推送给多家商家，商家在线报价，用户和管理员在几分钟内就能看到不同商家的价格差异。整个比价过程透明公开，用户信任感明显增强，回头客比例也上去了。

要说遗憾，也有两点。一是没有做维修工定位跟踪，用户偶尔会问“师傅到哪了”，目前只能靠维修工主动汇报，体验还有提升空间。二是没有接入在线支付回调的自动对账，用户付款后管理员还得人工核对到账。这两个模块我计划下一迭代补上，功能并不复杂，但对使用体验的提升会很直接。

如果你也在做类似项目，我最后提三点建议。第一，角色权限设计一定放在最前面，宁可多花一周画权限矩阵图，不要急着写接口；第二，状态机流转要提前定义完整，边界情况像“维修工拒绝接单后用户改约”这种，都要有明确的状态路径；第三，不要追求技术炫技，稳定和可维护永远是第一位的。这个系统能顺利上线稳定运行，靠的其实不是哪个惊艳的算法或框架，而是每一步都按照业务逻辑老老实实拆、认认真真做。