企业官网建设流程全解析

简介：在汽车售后服务数字化进程中，一套好用的维修管理系统往往能解决门店信息断档、流程割裂、库存账实不符等顽疾。这类系统本质上是以维修工单为线索的企业级管理软件，通过预约开单、派工领料、质检结算、客户回访的闭环流转，把服务顾问、车间主管、配件员、结算员串成一条高效协作链。其背后涉及单体分层架构、RBAC权限模型、状态机流转、统一返回封装、防超卖SQL等通用技术实践，也贴合门店按角色分工的真实作业场景。本文从典型4S店维修管理系统入手，梳理工单从创建到回访的数据链路与关键代码逻辑，分析状态校验、金额计算、看板统计等常用设计思路，并给出二次开发与部署避坑指南。无论你正在选型售后管理系统，还是想参考一个完整的业务项目代码组织方式，都能从中获得可落地的借鉴。

1. 先看清这个系统：4S 店维修管理的核心痛点到底在哪

某个二线城市的 4S 店售后车间，最头疼的不是修车，而是信息断档——接车单在纸上、配件在 Excel 里、结算在财务电脑上，客户问进度要跑三个工位。这套大型汽车 4S 店维修管理系统，就是把维修业务串成闭环：预约开单、派工领料、维修质检、结算回访全走系统，服务顾问、车间主管、配件员、结算员各角色分权操作。它面向三类人：售后经理梳理流程、开发者找业务链路参考、新手学真实项目如何组织。

拆完这份资源，我的直观判断是：价值不在界面，在业务链路完整——每张工单从创建到回访都留状态、留操作人、留时间。下面先拆架构，再讲核心代码、运行步骤、常见坑，最后说怎么按自己门店流程改造。

2. 系统架构与工程结构：一个维修工单的前世今生

2.1 整体定位：不是堆功能，而是按角色组织业务

4S 店维修车间不是只有一个“修车”动作，而是服务顾问、车间主管、配件管理员、质检员、结算员、客服各自负责一段。这套系统的页面就是按这些角色拆开的：服务顾问打开看到预约和开单，车间主管看到待派工队列，配件库看到领料申请，财务看到结算单。这种按角色组织功能的设计，比传统“所有菜单平铺”更贴近门店实际，员工不会迷失在系统里。

实现上它是典型的企业级单体分层架构。后端按 controller / service / mapper 拆包，前端按角色和业务域拆页面，数据库用 MySQL，缓存用 Redis。门店内网部署一台服务器就够了，员工通过浏览器访问，客户如果想查进度，可以另配 H5 或小程序端，复用同一套接口。选单体而不是微服务，是这类系统的合理默认：维修业务的并发压力不大，而开单、领料、结算往往需要在一个事务里完成，单体能把跨表事务管在同一数据源内，出问题好排查，运维也简单。

2.2 工程目录：看代码前先认路

解开源码包后，先别急着点启动类，把工程目录分清楚。后端是一个 Maven/Spring 工程，包结构一般是 controller、service、mapper、entity、config、common 几个部分，common 里放统一返回和异常处理。前端如果是 Vue 系，src 下 views 对应页面，api 封装请求，router 管路由，store 管状态，还有 permission 目录做按钮权限。数据库脚本在 sql 目录，按 sys_、repair_、parts_、settle_ 前缀区分业务域。

我用一个表格描述常见目录和它们的作用，方便按图索骥：

有一点值得注意：后端模块和前端页面基本一一对应。改工单状态时，你能同时定位到前端 views/repair 的按钮事件、api/repair.js 的接口调用、后端 RepairController 与 RepairOrderService。这个“前后端同名对应”的设计，后期维护会少很多找文件的痛苦。

2.3 核心数据关系：五张表串起一次维修

维修业务绕不开这几张主表：维修工单表 repair_order 是主档，记录车牌、车型、客户、服务顾问、当前状态；维修项目表 repair_order_item 记录换件、拆装等作业项；配件出库记录 parts_stock_log 关联工单和配件；结算表 settlement_order 汇总工时费和配件费；回访表 follow_up_record 在结算后生成。这五张表就是一次维修从进厂到出厂的数据链路。

工单状态是这条链路的骨架，常见状态：待接车 → 已开单 → 维修中 → 待质检 → 已质检 → 待结算 → 已结算 → 已回访。系统在每次状态变更时写一条状态流水或更新时间，事后查“这单谁改的、什么时候改的”有据可依。字段设计上也不含糊，create_by、create_time、update_by、update_time 这类审计字段基本都有，为二次开发做操作日志留下钩子。

状态流转不是散落到整个项目里，而是集中在一个 WorkflowService 里做统一校验：当前状态允许哪些操作、操作后落到哪个状态、需要什么角色，都在这一个类里控制。后面想加“反审核”或“撤回”，只需要在这个类里加一条规则，而不是满项目找 if。

2.4 权限模型：从门店到车间的数据范围隔离

用户、角色、菜单是标准的 RBAC 模型：sys_user 用户表、sys_role 角色表、sys_menu 菜单权限表、sys_user_role 关联表。4S 店场景比普通后台多一层组织架构：门店下分机电车间、钣喷车间，车间下再分班组。这套系统的用户挂在 dept 树上，而数据权限按 dept 做隔离。

举例：车间主管登录后只看到自己车间当前维修中的工单，配件管理员只能看到自己仓库的调拨单，服务顾问只能改自己名下创建的工单。实现上是在 Service 查询前根据当前登录人的 dept 范围自动追加数据过滤条件，一般在拦截器或公共 BaseService 里做，避免每个查询方法都手写 where dept_id in (...)。这种设计对门店很重要，不然任何员工都能看到全店产值和成本，迟早出事。

2.5 接口约定：一层 Result 统一所有返回

前后端交互部分，这类管理系统通常会约定一个统一返回结构。常见做法是 Result 包含 code、msg、data 三个字段，code 为 0 表示成功，非 0 表示业务失败或系统异常。这套资源里也看到了同样的约定：

public class Result<T> { private Integer code; private String msg; private T data; public static <T> Result<T> ok(T data) { Result<T> r = new Result<>(); r.code = 0; r.msg = "success"; r.data = data; return r; } }

逻辑说明：所有业务异常由全局 ExceptionHandler 捕获后转成 Result 返回，前端 axios 拦截器统一判断 code，弹错误提示或跳登录。好处是业务代码不需要在每个方法里 try-catch，也方便前端封装公共处理逻辑。参数上 code 是状态码，0 成功、401 未登录、403 无权限、500 系统错误；msg 是给用户看的提示语；data 是业务数据。

2.6 技术选型的一点点反思

有人会问这种系统为什么不用微服务、不用云原生。原因很简单：一个门店的维修业务，日工单量撑死几百单，单台服务器绰绰有余。引入微服务除了让架构显得复杂，对实际运维是大负担——要维护注册中心、网关、日志链路。这类业务系统最核心的诉求是事务一致性、权限清晰、报表准确，单体完全能扛住。技术选型的价值在于匹配场景，而不是堆名词。

3. 核心模块拆解：从开单到结算到回访的完整链路

3.1 工单创建：接车这一下决定后面所有数据

服务顾问接车时录入车牌、车型、里程、客户诉求、故障描述，选择服务类型，保养、维修或者钣喷，系统创建维修工单。创建工单的核心逻辑：

@Service public class RepairOrderServiceImpl implements RepairOrderService { @Transactional(rollbackFor = Exception.class) public RepairOrder createOrder(RepairOrderCreateRequest req) { // 同一车牌存在未完结工单时，不允许重复开单 long pending = repairOrderMapper.countPending(req.getPlateNo()); if (pending > 0) { throw new BizException("该车辆存在未完结工单，请先处理原工单"); } RepairOrder order = new RepairOrder(); order.setOrderNo(generateOrderNo()); order.setPlateNo(req.getPlateNo()); order.setCustomerId(req.getCustomerId()); order.setAdvisorId(req.getAdvisorId()); order.setStatus(RepairStatus.PENDING); order.setEstimatedAmount(req.getEstimatedAmount()); repairOrderMapper.insert(order); statusLogService.log(order.getId(), RepairStatus.PENDING, req.getOperator()); return order; } }

逻辑说明：方法加 @Transactional，因为开单涉及工单主档写入和状态流水写入两步，任一失败都要回滚，避免出现“工单建了但状态没记”的脏数据。开单前先查同车牌有没有未完结工单，这是门店非常实际的防重复开单手段。generateOrderNo 的规则是“门店编码 + 日期 + 三位流水号”，比自增主键更适合电话报单时和客户核对单号。

参数说明：plateNo 是车牌号，用于幂等校验，也用于后续车辆档案关联；customerId 是客户 ID，决定回访电话和短信发给谁；advisorId 是服务顾问 ID，后续派工、绩效、产值统计都挂在这个字段上；estimatedAmount 是预估金额，和最终结算单做对比，门店据此评估估单准确率。如果想支持“预约单转工单”，在 createOrder 入参加一个 appointmentId 参数，预约好的客户信息和诉求直接带入即可。

3.2 派工与领料：车间协同与库存扣减

工单从待接车进入维修中后，车间调度要选择班组和技师，并下发作业项目。配件方面，技师或调度在工单下添加配件需求，配件员审核后扣减库存并生成出库流水。前端派工页提交动作：

async function dispatchAndPick(orderNo, { teamId, mechanics, items }) { const parts = items.map(it => ({ partCode: it.code, qty: it.qty, outboundType: 'WORK_ORDER', sourceNo: orderNo })) const res = await api.post('/repair/dispatch/pick', { orderNo, teamId, mechanics, parts }) if (res.code !== 0) { ElMessage.error(res.msg || '派工或领料失败') return false } // 提交成功后重新拉取工单详情，刷新各角色页面状态 loadOrderDetail(orderNo) }

逻辑说明：派工和领料放在同一个提交动作里，是车间业务的常见做法：调度一次决定“谁来修、用什么料”，减少审批流转次数。提交成功后重新拉取工单详情，是为了让维修技师页面立刻出现待作业项，不需要手动刷新。如果流程要求先派工再领料，可以把两个操作拆成独立接口，但一定要在状态上做校验，不允许未派工先领料。

参数说明：teamId 是班组 ID，按机电、钣金、喷漆区分，后续统计班组工时绩效靠它；mechanics 是技师 ID 数组，一个工单可以多人协作；outboundType 标记出库类型，WORK_ORDER 是工单领料，DIRECT_SALE 是配件零售出库，两种在成本核算时会分账。sourceNo 记录来源单号，后续要退货时可以通过它找到原始出库流水。

扣减库存时，系统用的是带条件的更新语句而不是先查后改：

-- 扣减配件库存，用条件更新防止超卖 UPDATE parts_stock SET stock_qty = stock_qty - #{qty}, update_time = NOW() WHERE part_code = #{partCode} AND stock_qty >= #{qty}

逻辑说明：这条 SQL 是防超卖的关键。并发情况下两个技师同时要领最后一个配件，只有一条更新语句影响行数为 1，另一条影响行数为 0，程序判断影响行数为 0 后提示库存不足。如果改成先 SELECT stock_qty 再 UPDATE，两个请求读到相同的剩余库存，就都会执行成功，库存变负数。配件库存这类高频写操作，必须把校验库存和扣减库存合并成一条原子 SQL。

3.3 质检与结算：金额怎么算才不出偏差

维修完成后进入质检环节，质检员在工单上勾选合格后，系统生成结算单。结算金额 = 工时费 + 配件费 - 优惠金额，其中工时费按工时单价乘工时数计算，配件费取该工单所有领料记录的出库价之和。核心代码：

public SettlementOrder settle(RepairOrder order, SettlementRequest req) { // 状态校验：没有质检通过，不允许结算 if (!RepairStatus.QUALITY_PASSED.equals(order.getStatus())) { throw new BizException("工单未质检通过，不能结算"); } BigDecimal laborAmount = laborPriceService.priceByOrder(order); BigDecimal partAmount = partStockLogService.amountByOrder(order.getId()); BigDecimal discount = req.getDiscount() == null ? BigDecimal.ZERO : req.getDiscount(); if (discount.compareTo(BigDecimal.ZERO) < 0 || discount.compareTo(laborAmount.add(partAmount)) > 0) { throw new BizException("优惠金额不合法"); } BigDecimal total = laborAmount.add(partAmount).subtract(discount); SettlementOrder settlement = new SettlementOrder(); settlement.setOrderId(order.getId()); settlement.setLaborAmount(laborAmount); settlement.setPartAmount(partAmount); settlement.setDiscountAmount(discount); settlement.setTotalAmount(total); settlementMapper.insert(settlement); orderService.transit(order.getId(), RepairStatus.SETTLEMENT_PENDING, req.getOperator()); return settlement; }

逻辑说明：结算前强制校验工单状态，防止“没干活先收钱”的流程漏洞。工时费和配件费分开统计，财务想复核任何一笔都能从明细表查到源头。优惠金额在入参时做范围校验，不能为负数，也不能超过应收总额，堵住乱打折的口子。金额全部用 BigDecimal，不用 double，避免浮点精度差导致对不上账。结算单生成后，工单状态从已质检流转到待结算，收银完成后最终落到已结算。

参数说明：laborAmount 来自工时单价乘以工时数；partAmount 来自该工单领料明细的 sum；discount 是优惠金额，支持满减或卡券抵扣；settlement 表里每个金额字段都单独存，方便以后做产值报表、毛利分析、估单偏差分析。如果要接财务系统，直接用这张表推凭证即可。

3.4 数据看板与统计：老板最关心的数字

维修看板一般展示今日进厂台次、在修台次、完工未交车、总产值、毛利率、平均维修时长。技术实现上，这些统计几乎不会每次刷新都去 count 业务表，而是用一张汇总表配合定时任务或缓存，避免上班高峰所有人都刷新首页时拖垮数据库。每日产值统计的核心 SQL 长这样：

-- 每日维修产值统计（定时任务每日凌晨执行，结果写入统计表） SELECT o.biz_date, COUNT(DISTINCT o.id) AS order_count, SUM(s.total_amount) AS total_amount FROM ( SELECT id, DATE(create_time) AS biz_date FROM repair_order WHERE create_time >= DATE_SUB(CURDATE(), INTERVAL 1 DAY) AND create_time < CURDATE() ) o LEFT JOIN settlement_order s ON s.order_id = o.id GROUP BY o.biz_date

逻辑说明：统计进厂台次用工单表，统计产值用结算表，两条口径不混。如果直接用工单表的预估金额算产值，会把一堆待结算工单虚算进去；如果直接 count 结算表，又可能漏掉当天开了单但还没结算的台次。这个 SQL 的价值在于口径清晰：台次来自工单创建时间，产值来自结算表。定时任务把结果写入统计表后，看板页面只读统计表，白天零延迟。门店场景不需要实时看板，秒级甚至分钟级刷新完全够用。

3.5 客户回访：结算之后闭环才算完成

4S 店售后管理里，回访是售后闭环的最后一环。系统在结算完成后自动创建回访任务，客服人员电话回访后录入结果和满意度。这里用 Spring 事件解耦结算和回访两个动作：

@Component public class SettlementEventListener { @Async @EventListener public void onOrderSettled(SettlementEvent event) { FollowUpTask task = new FollowUpTask(); task.setOrderId(event.getOrderId()); task.setCustomerId(event.getCustomerId()); task.setExpectedTime(DateUtil.addDays(new Date(), 1)); task.setStatus(FollowUpStatus.PENDING); followUpTaskMapper.insert(task); } }

逻辑说明：结算完成后发布事件，监听器创建回访任务，两者互不阻塞。即使回访任务创建失败，也影响不到结算主流程，符合核心链路异步化的思路。回访任务设置预计时间为次日，系统按天扫描到期未回访的任务并在客服工作台提醒。客服回访时勾选结果，满意、一般或者不满意，不满意的自动生成投诉工单转入售后处理，这个闭环对门店服务质量很重要。

参数说明：event.getOrderId() 关联工单，event.getCustomerId() 决定回访拨给谁；expectedTime 是期望回访时间，用来生成提醒；status 从 PENDING 到 DONE 或到 COMPLAINT 分支，客服手动标记完成而不是自动完成，因为回访本质是人工电话动作。

4. 运行与排查：拿到源码后怎么把系统跑起来

4.1 环境准备与启动前提

启动前确认四样东西：JDK、MySQL、Redis、Node。版本以项目 pom 和 package.json 为准，常见组合是 JDK 8 或 17、MySQL 5.7 或 8.0、Redis 5+、Node 14+。不用花太多时间纠结最新版本，稳定比新重要。后端配置文件在 application.yml 或 application-dev.yml，需要改数据库地址、账号、密码和 Redis 地址；前端在 .env.development 或 vite.config.js 里改代理目标。

4.2 标准启动步骤：五步把项目拉起来

按顺序走五步，每一步都有对应说明，避免出现“先启动后建库”那种折腾人的错位：

# 1. 创建数据库并导入初始化脚本 mysql -uroot -p -e "CREATE DATABASE IF NOT EXISTS car_repair DEFAULT CHARSET utf8mb4;" mysql -uroot -p car_repair < sql/init.sql mysql -uroot -p car_repair < sql/data.sql # 2. 启动 Redis，作为缓存和会话存储 redis-server --daemonize yes # 3. 启动后端，Spring Boot 默认端口 8080 cd server mvn spring-boot:run # 4. 启动前端开发服务器 cd web npm install npm run dev # 5. 浏览器访问前端地址，用 data.sql 里的管理员账号登录

步骤 1 里 utf8mb4 必须带上，工单备注里如果客户发了 Emoji 或其他生僻字符，utf8mb3 会直接报错或乱码。步骤 2 用 daemonize 后台启动，避免一直占着一个终端。步骤 3 启动后看到 Tomcat started 才算成功，如果报 Error creating bean，多半是数据库没连上或 Redis 没起。步骤 4 的 npm install 失败时，换成国内镜像源再试。步骤 5 的初始账号密码直接查 data.sql 的 sys_user 表，不用猜。

提示：第一次启动如果后端报 Access denied，先检查 MySQL 账号密码是否写进了 application.yml，而不是急着改代码。

4.3 演示数据准备：跑通流程前先造两条工单

登录系统后如果页面是空的，别慌，先在数据库插一张测试工单和对应客户，把流程跑通再往里填真实数据。这里给一条最小可用的插入语句：

-- 造一条测试工单，保证从开单到结算每个页面都有数据可看 INSERT INTO repair_order (id, order_no, plate_no, customer_id, advisor_id, status, estimated_amount, create_time) VALUES (9001, 'D00120250101001', '测试A1234', 1, 1, 'PENDING', 800.00, NOW());

逻辑说明：order_no 采用业务单号而不是自增 ID，方便在接口日志里搜；customer_id 和 advisor_id 先填 1，前提是 data.sql 里已存在对应客户和员工记录；status 填 PENDING 保证工单列表里有数据，又不会影响库存。插入后刷新工单列表，能看到这张单就说明数据库连接和列表接口都正常。下一步从接车按钮开始走一遍完整流程，会发现系统的业务套路其实很顺。

4.4 部署到内网服务器的注意点

如果要给店里真正用，前端打包后放在 Nginx，后端 jar 包用 systemd 守护，数据库和 Redis 独立装。Nginx 反代 /api 到后端端口，前端静态资源同域部署，避免开发和演示时跨域导致 cookie 丢失的老问题。给一个常见 Nginx 配置片段：

server { listen 80; server_name your-server-ip; location / { root /opt/car-repair/dist; try_files $uri $uri/ /index.html; } location /api/ { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }

逻辑说明：前端用 history 路由时必须配 try_files，否则刷新页面会 404。所有 /api 开头的请求反代到后端 8080，保持同域，cookie 不会丢。如果前端用的是 hash 路由，try_files 可以省，但地址会带 #，给店里的员工用不太好看，建议 history 加 try_files。

4.5 踩坑记录：我在这个项目上遇到的五个典型问题

接下来把我在拆解和复现过程中常见的五个问题列出来，每条按现象、原因、解决三个层次说明。

问题一：登录成功后接口大量 401。现象是登录页能进，但进入系统后每几秒被弹回登录页。原因是前端访问后端时的端口或域名不一致，cookie 没带上；开发环境最常见的翻车是前端 5173、后端 8080 直接跨域请求。解决方式是开发模式用 Vite 代理或给后端加跨域配置，生产模式走 Nginx 同域反代。从那以后我每次搭前后端项目，第一件事就检查代理和 cookie domain。

问题二：导入数据库脚本报语法错误或中文乱码。现象是导入 init.sql 或 data.sql 时报错，页面中文显示问号。原因大多是 MySQL 默认字符集不是 utf8mb4，或建库时没带字符集参数。解决是建库时统一用 utf8mb4，并用 mysql 命令行导入。

问题三：领料时提示库存不足，但库存列表明明有货。现象是配件页面显示库存 8 件，提交领料却提示不足。原因是页面展示读的是缓存或汇总表，扣减校验读的是 parts_stock 明细表，两边存在延迟。解决是页面展示允许秒级延迟，扣减必须强一致；检查库存缓存过期策略。

问题四：看板产值和结算报表对不上。现象是首页看板显示今日产值 10 万，结算报表导出只有 8 万。原因是看板统计包含了待结算或已取消工单的数据。解决是看板按结算表且只统计已结算状态，子查询加状态过滤。

问题五：改了前端页面不生效，刷新还报 404。现象是本地修改代码后，部署到 Nginx 刷新某个子页面 404。原因是 history 路由没配 try_files。解决是 Nginx 加 try_files $uri $uri/ /index.html。这几个问题几乎覆盖了跑一个单体管理系统的大半坑。

5. 二次开发改造：把系统改成符合自己门店的流程

5.1 状态机抽成配置表，别在代码里写死

这套工程源码结构规整，接口约定统一，很适合直接作为二次开发起点。我给这套系统做改造时，第一个建议是把状态流转规则从 Service 里的硬编码抽成配置表。现在“已开单可以派工、维修中可以变更项目、已质检不能改派”这类规则散在多个 if 里，门店每调整一次流程，就要改代码重新发版。抽一张 repair_status_flow 配置表，字段包括当前状态、下一状态、允许角色、操作按钮，前端按钮按表动态渲染，后端用统一 FlowService 校验流转。以后调整流程只需改配置行，不用动代码。

5.2 三个最值得改的方向

结合 4S 店实际业务，我列三个改造方向，每个都对应明确的表或接口：

预约转工单是门店高频需求：客户打电话预约保养，到店后不要再录一遍车辆信息。实现上就是在开单接口里加一个 appointmentId 参数，创建工单时带出客户和车辆档案，再把预约状态标记为已到店。微信进度推送则需要对接公众号模板消息，状态流水表已经是现成的，监听状态变更事件发消息就行。挂账月结适合政企客户，结算时不强制收现，生成应收单后月底统一对账。

5.3 改造验证：走一遍完整链路再上线

改完任何流程，我习惯先做一笔完整冒烟：从建单、派工、领料、质检、结算到回访，全程走一遍；再做一笔反向用例，尝试在未质检时结算，应该被拦截。全链路过完再导真实数据。从那以后我每次改这类业务系统，都强制自己先把状态流转图在纸上画出来，确认每个状态都有出口再动代码，这个习惯帮我避开了很多“流程走到一半卡住”的坑。希望帮到你。

本文还有配套的精品资源，点击获取