简介这是一套面向汽车修理厂日常运营场景的数字化管理软件源码适合计算机专业学生、课程设计开发者以及中小型汽修门店的信息化建设者参考。系统围绕客户档案、预约排程、维修订单、配件库存、财务收支、员工绩效与统计报表等模块展开帮助解决手工记账混乱、库存预警滞后、经营数据难以汇总等实际问题。资源包共53个文件约2.66MB以C源码cpp、h为核心配合MFC工程文件dsp、dsw、clw、编译中间产物obj、pch、idb以及Access数据库Car.mdb另含图标、音效与资源脚本构成一套可直接编译运行的完整工程。已有678人学习下载。通过阅读源码读者可掌握基于MFC与ADO数据库访问的桌面管理程序结构理解各功能对话框与数据表的映射关系并借鉴其模块划分与权限控制思路用于二次开发或毕业设计参考。1. 汽修厂老板的账本困局这套管理系统到底能解决什么我见过一个开了八年修理厂的老板接车用粉笔写在白板上配件进出靠微信语音月底对账时发现三辆车修完了没收钱。这不是段子是很多中小汽修门店的真实状态。这套「汽车修理厂汽车修理管理系统」就是冲着这个场景来的——它把接车登记、维修派工、配件领用、结算收款串成一条线让每一辆进厂的车都有迹可循。适合谁用单店或两三个工位的社区修理厂、快修快保店以及想拿一套完整业务系统做二次开发练手的开发者。技术栈上这类系统常见做法是后端用 Spring Boot 或 Python Flask 提供 REST 接口前端用 Vue 或原生 HTML 加模板渲染数据库选 MySQL部署在一台普通云主机或门店内网机器上就能跑。下面我按「能干什么、怎么跑起来、怎么改」的顺序把这份源码拆开讲。2. 系统架构与目录结构从一张工单看数据怎么流转2.1 业务闭环一辆车从进厂到结算经过哪些表先别急着看代码把业务跑通比什么都重要。一辆车进厂前台登记车牌、车型、车主电话、故障描述系统生成一张维修工单状态是「待派工」。车间主管把工单指派给某个技师状态变「维修中」。技师在维修过程中领用配件系统扣减库存并记录领料明细。维修完成后工单转「待结算」前台按工时费加配件费生成结算单收款后状态变「已结算」同时这辆车的维修历史归档下次再来能直接调出。这条链路对应到数据库核心是四张表vehicle车辆档案、repair_order维修工单、part配件库存、order_part工单领料明细。工单表通过vehicle_id关联车辆领料明细表通过order_id和part_id把工单和配件连起来。搞清这个关系后面看任何一段代码都不会迷路。-- 维修工单核心表结构简化版 CREATE TABLE repair_order ( id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL UNIQUE COMMENT 工单号如 RO20240501001, vehicle_id BIGINT NOT NULL COMMENT 关联车辆, fault_desc VARCHAR(500) COMMENT 故障描述, status TINYINT DEFAULT 0 COMMENT 0待派工 1维修中 2待结算 3已结算, technician_id BIGINT COMMENT 指派技师, labor_fee DECIMAL(10,2) DEFAULT 0 COMMENT 工时费, part_fee DECIMAL(10,2) DEFAULT 0 COMMENT 配件费合计, created_at DATETIME DEFAULT CURRENT_TIMESTAMP );字段说明里最关键的是status它驱动了整个系统的页面流转和权限控制。order_no用日期加流水号生成方便前台口头报单号查进度。labor_fee和part_fee分开存是因为结算时经常要按项目打折分开算比混在一起灵活。2.2 目录结构前后端怎么分配置文件在哪拿到源码包先看根目录。这类管理系统常见做法是前后端分离目录大致长这样repair-system/ ├── backend/ # 后端服务 │ ├── src/main/java/... # 控制器、服务、数据访问层 │ ├── src/main/resources/ │ │ ├── application.yml # 数据库连接、端口配置 │ │ └── mapper/ # MyBatis 的 SQL 映射文件 │ └── pom.xml # Maven 依赖 ├── frontend/ # 前端页面 │ ├── src/views/ # 各业务页面接车、派工、结算 │ ├── src/api/ # 接口请求封装 │ └── package.json └── sql/ └── init.sql # 建库建表加初始数据后端如果用的是 Spring Bootapplication.yml里改数据库地址和密码就能连自己的库前端src/api目录下通常有一个request.js里面配了后端接口的基础地址部署时改成实际 IP 或域名。sql/init.sql是救命文件第一次跑必须先执行它否则表都没有登录都进不去。2.3 权限与角色为什么前台看不到成本价系统一般内置三种角色管理员、前台、技师。管理员能看所有数据和报表前台能接车、派工、结算但看不到配件的进价技师只能看指派给自己的工单和领料。这个权限控制在代码里通常靠一个拦截器加角色字段判断实现。// 简化的权限拦截逻辑 public boolean checkPermission(String role, String apiPath) { if (ADMIN.equals(role)) return true; // 管理员放行 if (FRONT.equals(role) apiPath.startsWith(/order)) return true; if (TECH.equals(role) apiPath.startsWith(/task)) return true; return false; // 其余一律拒绝 }这段逻辑看着简单但它是整个系统安全感的来源。参数role从登录后写入 session 或 token 里取apiPath是当前请求路径。实际项目里会做得更细比如前台能改工单但不能删工单这些差异都落在checkPermission的分支里。改权限就是改这里的分支条件比满项目找if靠谱得多。3. 本地跑起来数据库、后端、前端三步走3.1 建库导数据init.sql 里有什么坑第一步永远是数据库。打开sql/init.sql里面通常包含建库语句、建表语句和几条初始数据比如默认管理员账号。执行方式有两种命令行mysql -u root -p init.sql或者用图形化工具打开文件直接运行。# 登录数据库并执行初始化脚本 mysql -u root -p CREATE DATABASE repair_db DEFAULT CHARSET utf8mb4; USE repair_db; SOURCE /path/to/sql/init.sql;这里有个血泪经验字符集一定要用utf8mb4别用utf8。汽修系统里车主姓名、故障描述经常出现生僻字utf8存进去会变问号结算单打出来车主名字是乱码客户当场就不信任你了。另外init.sql里的初始密码通常是明文或简单加密第一次登录后立刻改掉别留着默认账号跑在公网上。3.2 后端启动改配置、装依赖、看日志数据库通了之后进backend目录。如果是 Maven 项目先改application.ymlspring: datasource: url: jdbc:mysql://127.0.0.1:3306/repair_db?useUnicodetruecharacterEncodingutf8mb4 username: root password: 你的密码 server: port: 8080url里的characterEncodingutf8mb4和数据库字符集对应别漏。然后执行mvn clean package打包或者直接在 IDE 里跑主启动类。启动成功的标志是日志最后出现Started Application in x seconds并且没有Communications link failure这类数据库连接报错。# 打包并运行 mvn clean package -DskipTests java -jar target/repair-system-1.0.jar-DskipTests是跳过测试加快打包第一次跑建议加上等系统跑通了再回头跑测试。如果启动报端口占用改server.port就行别去杀进程容易误伤别的服务。3.3 前端启动接口地址别写死前端进frontend目录先npm install装依赖再npm run dev起开发服务器。关键动作是找到接口基础地址的配置通常在.env.development或src/api/request.js里。// src/api/request.js 里的基础地址配置 const baseURL process.env.VUE_APP_BASE_API || http://127.0.0.1:8080; // 开发环境指向本地后端生产环境改成实际服务器地址很多人本地跑不通就是卡在这后端在 8080前端请求却发到了别的端口浏览器控制台一片 404。改完地址重启前端用初始管理员账号登录能看到接车页面就说明整条链路通了。这时候别急着录入真实数据先随便建一辆测试车走一遍完整流程确认工单状态能正常流转。4. 核心模块拆解接车、派工、结算三段代码4.1 接车登记工单号怎么生成才不重复接车是整个系统的入口代码质量直接影响后面所有环节。核心是生成一个唯一工单号并落库。// 工单号生成日期 4位当日流水 public String generateOrderNo() { String datePart LocalDate.now().format(DateTimeFormatter.ofPattern(yyyyMMdd)); // 查询当天已有多少工单加一作为流水号 int todayCount orderMapper.countByDate(datePart); return RO datePart String.format(%04d, todayCount 1); }逻辑说明datePart取当天日期countByDate查当天工单数量加一后补零成四位。参数上%04d保证流水号至少四位当天超过 9999 单才会溢出中小修理厂根本到不了。这里有个并发隐患两个人同时接车可能拿到同一个流水号。常见做法是给order_no加唯一索引插入失败就重试一次或者直接用数据库自增 ID 拼日期更省心。4.2 派工与领料库存扣减必须和工单绑定派工是把工单指派给技师领料是技师从仓库拿配件。这两步必须在一个事务里完成否则会出现「配件领走了但工单没记录」的糊涂账。Transactional // 事务注解保证扣库存和写明细同时成功或同时失败 public void assignAndPickParts(Long orderId, Long technicianId, ListPickItem items) { // 1. 更新工单状态和技师 orderMapper.updateStatusAndTech(orderId, 1, technicianId); // 2. 逐项扣减库存并写领料明细 for (PickItem item : items) { int affected partMapper.reduceStock(item.getPartId(), item.getQty()); if (affected 0) { throw new RuntimeException(配件库存不足 item.getPartId()); } orderPartMapper.insert(orderId, item.getPartId(), item.getQty()); } }Transactional是这段代码的灵魂。reduceStock的 SQL 里带WHERE stock #{qty}条件库存不够时返回影响行数 0直接抛异常回滚整个操作。参数items是技师勾选的配件列表每项含配件 ID 和数量。这样即使中途某个配件不够前面扣掉的库存也会回滚不会出现半截账。4.3 结算收款工时费和配件费怎么算准结算要把工时费和配件费汇总生成最终金额。配件费从领料明细里按当时售价累加工时费按工单上记录的金额取。-- 汇总某工单的配件费 SELECT IFNULL(SUM(op.qty * p.sale_price), 0) AS part_fee FROM order_part op JOIN part p ON op.part_id p.id WHERE op.order_id #{orderId};IFNULL是防止没有领料时返回 null导致前端显示空白。sale_price取的是配件表里的当前售价这里有个细节如果配件调过价历史工单的配件费会跟着变。严谨做法是在order_part表里冗余一个unit_price字段领料时把当时售价存进去结算就按这个存下来的价格算不受后续调价影响。这是很多新手会翻车的地方改起来不难加个字段的事。5. 避坑与常见问题跑不起来先看这几条5.1 启动报数据库连接失败现象后端启动日志里出现Communications link failure或Access denied for user。原因通常是application.yml里的地址、端口、账号密码和实际数据库对不上或者数据库服务根本没启动。解决先用命令行mysql -u root -p确认能连上再核对配置文件里的每一项特别注意密码里有没有特殊字符需要转义。5.2 页面能打开但接口全 404现象前端登录页面正常显示点登录没反应浏览器控制台一堆 404。原因基本是前端接口基础地址配错了或者后端没起在预期端口。解决打开浏览器开发者工具的 Network 面板看请求实际发到了哪个地址和request.js里的baseURL对比改成一致即可。5.3 中文乱码现象录入的车主姓名、故障描述存进数据库变成问号或者页面显示乱码。原因有三处可能数据库字符集不是utf8mb4、连接串没加characterEncoding、前端页面没声明 UTF-8。解决按数据库、连接串、页面三层逐一排查建库时就用utf8mb4最省事。5.4 工单状态卡住不流转现象派工后工单还是显示「待派工」或者结算后状态没变。原因多半是状态更新的 SQL 条件写死了旧状态比如WHERE status 0但实际状态已经不是 0 了。解决检查更新语句的WHERE条件确认它和当前实际状态匹配或者干脆只按id更新状态值由业务代码控制。5.5 配件库存扣成负数现象库存表里出现负库存。原因是扣减时没加库存充足判断或者并发下两个请求同时扣。解决扣减 SQL 必须带WHERE stock #{qty}并在业务层判断影响行数为 0 就抛异常回滚。高并发场景再加数据库行锁或乐观锁版本号。6. 二次开发从改一个字段到加一张报表拿到这套源码最值钱的不是原样跑起来而是按自己门店的规矩改。我一般从三个方向下手按难度递增。第一层改字段和文案。比如工单表想加一个「预计交车时间」字段改动路径是init.sql加列、实体类加属性、Mapper 的 insert 和 update 语句加参数、前端表单加输入框。四步缺一不可漏了哪步都会出现「填了不保存」或「保存了不显示」。这类改动最安全适合先练手熟悉代码结构。第二层加业务规则。比如「结算时必须先确认所有领料都已归还或核销」。做法是在结算接口里加一段校验查order_part表里有没有未核销的记录有就返回错误提示。这类改动要动 Service 层改完务必用测试数据走一遍完整流程别只测单个接口。第三层加报表和统计。修理厂老板最想看的是「这个月修了多少车、哪个技师产值最高、哪些配件周转最快」。加报表的思路是新建一个统计接口用 SQL 聚合查询出数据前端加一个图表页面。下面是一个技师产值的统计示例-- 按月统计各技师完成的工单数和工时费合计 SELECT t.name AS technician, COUNT(o.id) AS order_count, IFNULL(SUM(o.labor_fee), 0) AS total_labor FROM repair_order o JOIN technician t ON o.technician_id t.id WHERE o.status 3 -- 只统计已结算工单 AND DATE_FORMAT(o.created_at, %Y-%m) #{month} GROUP BY t.id, t.name ORDER BY total_labor DESC;status 3是关键过滤条件只算已结算的才算真实产值维修中的工单不能计入。DATE_FORMAT按月份分组前端传2024-05这样的参数就能查指定月份。这个查询在数据量大的时候会慢常见做法是给created_at和status加联合索引。改造时有个习惯我一直保持每次改完数据库结构先手动执行一遍建表语句确认无误再重启后端最后清浏览器缓存刷新前端。这三步走完再测功能能省掉大量「明明改了却没生效」的玄学时间。有次我改了个字段类型没同步改实体类排查了半小时才发现是类型不匹配导致插入静默失败从那以后我每次动表结构都强制走一遍「SQL、实体、Mapper、前端」四件套核对。希望这套拆解能帮你少走点弯路把这份源码真正变成自己门店能用的系统。本文还有配套的精品资源点击获取