简介一套基于PHP与MySQL的汽车维修及零配件管理系统源码面向中小型汽修企业、院校毕设开发者与初级技术人群覆盖预约登记、维修进度跟踪、零配件出入库、客户档案与权限控制等场景可帮助快速搭建可运行的B/S管理后台。压缩包共346个文件大小13.9MB以49个php后端脚本、47个js交互逻辑、23个css样式与16套字体文件为核心另有140个png和12个jpg用于界面资源sql与db文件便于导入数据库mp4演示视频可辅助快速上手。系统功能模块划分清晰前端内置多套主题样式如style.default.css、fullcalendar.css等配合报表统计与权限管理设计适合作为课程设计、毕业设计或企业内部系统二次开发的参考模板。目前已有488人浏览学习对于需要掌握PHPMysql增删改查及维修行业业务流程的读者这份资源具有较好的参考价值。1. 从车进厂到钱到账这套PHP系统到底在修什么一家中小型汽修店最乱的时候往往不是修车的时候而是月底对账的时候。前台手写的维修工单、库管本子上涂改的零配件出入库记录、财务问技师这个月提成怎么算——三套数据凑不到一块少则几百块多则几万块的账就对不上。php汽车维修管理系统_零配件管理系统这个标题背后要解决的就是把这套线下的“接车、派工、领料、结算、盘点”流程装进一套PHP MySQL的应用里让每一笔零配件流向都挂到工单上让每个状态变化都能追溯操作人。适合两类人看一类是汽修门店或售后负责人想弄明白这套系统应该有哪些模块、数据怎么流转另一类是PHP开发工程师需要知道这种业务系统从建表到写状态机、从库存扣减到报表联查的完整落地路径。2. 拆清模块与数据表维修单、零配件库存和客户档案2.1 工单表的字段取舍主单、明细、状态分开落库这类系统最常见的错误是把维修项目、零配件、工时费用全部塞进一张大表里。字段越宽统计越痛苦。通常我会拆成两个层级repair_order主表记录这台车进厂之后的核心上下文repair_item明细表记录这次维修里具体做了哪些项目、消耗了哪些零配件。CREATE TABLE repair_order ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, order_no VARCHAR(32) NOT NULL COMMENT 工单号如 RO20250612001, customer_id INT UNSIGNED NOT NULL COMMENT 客户ID, vehicle_id INT UNSIGNED NOT NULL COMMENT 车辆档案ID, mileage INT UNSIGNED DEFAULT 0 COMMENT 进厂里程, status TINYINT NOT NULL DEFAULT 0 COMMENT 状态机0接车 1派工 2维修中 3待结算 4已结算 5已交车 6已作废, master_tech_id INT UNSIGNED DEFAULT 0 COMMENT 主修技师, receive_user_id INT UNSIGNED NOT NULL COMMENT 接车员/开单员, estimate_amount DECIMAL(10,2) DEFAULT 0.00 COMMENT 预估费用, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_status (status), KEY idx_order_no (order_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT维修工单主表;status字段是整个系统的骨架后面所有权限控制和结算都依赖它。接车员建单时只能写0技师开工才允许推进到2这一条约束在数据库层就要配合应用层一起做避免有人绕过界面直接改库。明细表的关键在于item_type字段它决定了这行记录是“维修项目”“零配件”还是“工时费”。三种类型在计价和成本上逻辑完全不同零配件有采购成本和销售价工时费只有价格没有库存。建表时不要为了省事统一叫name和price后面算毛利时会后悔。CREATE TABLE repair_item ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, order_id BIGINT UNSIGNED NOT NULL, item_type TINYINT NOT NULL COMMENT 1维修项目 2零配件 3工时费, item_name VARCHAR(100) NOT NULL, part_id INT UNSIGNED DEFAULT 0 COMMENT 零配件IDitem_type2时有效, qty INT NOT NULL DEFAULT 1, sale_price DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 销售单价, cost_price DECIMAL(10,2) NOT NULL DEFAULT 0.00 COMMENT 成本单价工时费填0, KEY idx_order_id (order_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT维修工单明细表;提示cost_price在生成工单时就要从配件表快照过来不能结算时才去查配件表因为采购价是波动的事后核算时工单成本必须保持历史一致性。2.2 零配件模块的库存流水表设计库存表只存当前量零配件管理模块的落地核心是“流水为账”。part表只保存配件当前库存数量和价格信息任何出入库操作都必须同时写一条stock_flow流水记录。这样做的直接好处是任何一笔库存差异都能通过流水表反查出来而不是看着库存表里的数字干瞪眼。CREATE TABLE part ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, part_no VARCHAR(50) NOT NULL COMMENT 配件编码/SKU, part_name VARCHAR(120) NOT NULL, unit VARCHAR(10) DEFAULT 个, stock_qty INT NOT NULL DEFAULT 0, safety_stock INT NOT NULL DEFAULT 5 COMMENT 安全库存预警线, purchase_price DECIMAL(10,2) NOT NULL DEFAULT 0.00, sale_price DECIMAL(10,2) NOT NULL DEFAULT 0.00, UNIQUE KEY uk_part_no (part_no) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT零配件库存表; CREATE TABLE stock_flow ( id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, part_id INT UNSIGNED NOT NULL, order_id BIGINT UNSIGNED DEFAULT 0 COMMENT 关联工单出库时必填, flow_type TINYINT NOT NULL COMMENT 1采购入库 2工单出库 3盘点调整 4退货出库, qty_change INT NOT NULL COMMENT 正数入库负数出库, before_qty INT NOT NULL, after_qty INT NOT NULL, created_by INT UNSIGNED NOT NULL COMMENT 操作人ID, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, KEY idx_part_flow (part_id, created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT零配件库存流水表;工单结算时系统把各维修项目中的零配件同步生成一条flow_type2的出库流水order_id指向工单主表。以后对账只需要按order_id反查流水就知道一辆车修完用了哪些配件、谁经手的、当时库存前后余量是多少。这套模式在库存类系统里被反复验证比“用一个字段去记出入库次数”靠谱得多。2.3 建表时的3个典型坑引擎、时间字段、外键很多PHP新手会把建表写成ENGINEMyISAM在低并发时没感觉到了两个工单同时要扣同一个配件库存时MyISAM 不支持行锁会出现幻读和超卖。时间字段要显式声明默认值。created_at DATETIME DEFAULT CURRENT_TIMESTAMP在 MySQL 5.7 及以上版本可用避免程序里漏传时间导致插入失败。如果用的PHP框架自带时间戳维护那表里也可以不写默认值但要保证所有 insert 都走了同一个入口。外键约束能不用就不用。特别是stock_flow.order_id指向repair_order.id一旦加了外键要作废旧工单时会被流水表挡住改动成本太高。索引配合应用层判断就够了。下表列出各表之间的引用关系和逻辑建数据字典时直接照抄表名主要外联字段关联目标说明repair_ordercustomer_idcustomer客户表一车一档按客户找历史维修记录repair_itemorder_idrepair_order一个工单对应多条维修明细repair_itempart_idpart仅item_type2时使用stock_floworder_idrepair_order工单出库时关联作废工单要同步处理3. 用PHP把维修工单跑起来状态机与零配件出库扣减3.1 工单状态机的6个节点与权限边界这套系统的逻辑不是CRUD而是状态流转。一个工单从建单到交车状态的每一步都对应一个操作角色如果把状态机写成一坨if堆在控制器的update方法里后面每个需求改动都要翻半天。我一般会在PHP里单独建一个OrderStatus类把可流转路径集中管理。class OrderStatus { const RECEIVED 0; // 已接车 const ASSIGNED 1; // 已派工 const REPAIRING 2; // 维修中 const PENDING 3; // 待结算 const SETTLED 4; // 已结算 const DONE 5; // 已交车 const CANCELED 6; // 已作废 private static array $transitions [ self::RECEIVED [self::ASSIGNED, self::CANCELED], self::ASSIGNED [self::REPAIRING, self::CANCELED], self::REPAIRING [self::PENDING, self::CANCELED], self::PENDING [self::SETTLED, self::REPAIRING], self::SETTLED [self::DONE], self::DONE [], self::CANCELED [], ]; public static function canTransit(int $from, int $to, string $role): bool { if (!in_array($to, self::$transitions[$from] ?? [], true)) { return false; } // 权限边界只有收银/店长能结算只有技师能开工 $roleMap [ self::PENDING [cashier, manager], self::REPAIRING [tech, manager], ]; return !isset($roleMap[$to]) || in_array($role, $roleMap[$to], true); } }状态机的核心价值在于把“状态变化合法吗”这个问题的判断集中在一处。以后要让“已交车”支持回退到“待结算”只需要改$transitions数组不需要去到处找散落的if status 5。$roleMap这段就是在做权限边界控制。技师只能把工单从“已派工”推到“维修中”不能碰“待结算”接车员能建单但不能做结算。这样即使前端页面被直接调用接口后端的canTransit还是能拦下来。3.2 出库扣减的PHP实现先锁行再扣库存工单进入“已结算”之前要先完成零配件出库。出库的PHP逻辑不能只是UPDATE part SET stock_qty stock_qty - 1必须按“查询并锁行 → 校验库存 → 更新 → 写流水”的顺序执行。public function deductStock(int $partId, int $orderId, int $qty, int $operatorId): void { $pdo $this-getPdo(); $pdo-beginTransaction(); try { // 1. 锁定配件行防止并发扣减 $stmt $pdo-prepare( SELECT id, stock_qty FROM part WHERE id ? FOR UPDATE ); $stmt-execute([$partId]); $part $stmt-fetch(); if (!$part || $part[stock_qty] $qty) { throw new \RuntimeException(零配件库存不足); } // 2. 扣减库存 $pdo-prepare( UPDATE part SET stock_qty stock_qty - ? WHERE id ? )-execute([$qty, $partId]); // 3. 写库存流水 $pdo-prepare( INSERT INTO stock_flow (part_id, order_id, flow_type, qty_change, before_qty, after_qty, created_by) VALUES (?, ?, 2, ?, ?, ?, ?) )-execute([ $partId, $orderId, -$qty, $part[stock_qty], $part[stock_qty] - $qty, $operatorId ]); $pdo-commit(); } catch (\Throwable $e) { $pdo-rollBack(); throw $e; } }SELECT ... FOR UPDATE这一句是整个方法的关键。它把idpartId这一行锁住直到事务提交或回滚其他会话的同一条SQL会阻塞等待。这样两个工单同时进来时第二个工单只能在第一个写完流水后才能读到最新的库存值。流水表里before_qty和after_qty不是为了看着好看是为了方便对账时恢复任何一个历史时间点的库存快照。如果只记一个qty_change审计或回滚时还得重新推算。3.3 并发场景两个工单抢同一个配件上面锁行方案能应对绝大多数单店场景但有一个边界如果业务量上来门店同时开的工单多了两个技师同时领同一个型号的机油滤芯FOR UPDATE会让第二个请求等待用户体验会稍有延迟但不会出错。更高并发时常见做法是把“预占库存”和“实扣库存”拆开接车开单时先锁定对应配件数量结算时确认出库。但这对中小型门店管理系统的成本而言回报不高还会引入“取消工单后如何释放预占”的复杂逻辑。先用事务锁行就够了。提示一定不要用UPDATE part SET stock_qty stock_qty - 1 WHERE stock_qty 0这种原子扣减来代替完整事务。它能防止负库存却无法记录流水等于把“哪个工单消耗的”这个关键信息丢掉了。PHP错误处理在这个环节也要注意捕获到库存不足异常时要给前端返回明确的错误编号而不是通用的“服务器错误”。一般我会在异常里带上业务码例如PDOException包装成BusinessException(10010, 配件库存不足)前端才能弹窗提示用户去确认库存或生成采购单。4. 零配件库存的4个必要参数安全库存、预警线与盘点容差4.1 安全库存与预警线怎么算零配件管理不能只做“记一笔库存”而是要能提前告诉门店什么该补货了。part.safety_stock的价值就是预警线。安全库存的计算方式很多对汽修门店来说最实用的是安全库存 近30天日均消耗量 × 采购在途天数 × 1.5。如果系统还没积累数据就用历史订单里同类配件的平均月销除以30。SELECT part_id, part_no, part_name, stock_qty, ROUND(SUM(IF(flow_type2, ABS(qty_change), 0)) / 30, 2) AS daily_consume, ROUND(SUM(IF(flow_type2, ABS(qty_change), 0)) / 30 * 3 * 1.5, 2) AS suggest_safety FROM stock_flow JOIN part ON part.id stock_flow.part_id WHERE created_at DATE_SUB(NOW(), INTERVAL 30 DAY) GROUP BY part_id HAVING stock_qty suggest_safety;这条SQL把“实际库存低于建议安全库存”的配件直接筛出来。*3表示采购周期按3天算不同门店可以根据供应商实际到货速度调整这个数字。stock_qty suggest_safety用了HAVING后再嵌套一次的原因是MySQL不允许HAVING里直接引用同一层的别名实际项目里可以再包一层子查询让语法更稳妥。4.2 盘点容差盘盈盘亏怎么修正每月盘点时账面库存和实物数几乎不可能完全相等。问题在于差异怎么处理。如果不设置容差前天盘一个昨天盘一个每笔差异都要走审核流程库管会崩溃。常见做法是盘点差异在容差范围内默认按报损报溢处理直接生成一条flow_type3的流水超过容差才需要主管审批。参数名推荐默认值说明stocktake_tolerance1%差异率 ABS(账面数-实盘数)/账面数stocktake_max_qty5 件单品差异超过5件必须审批apply_way1 自动调整0需审批1自动调整实现时维护一张stocktake盘点单记录每个配件的账面数、实盘数和盘盈盘亏数量确认后调用库存调整接口这时的qty_change填正数代表盘盈入库填负数代表盘亏出库order_id置0flow_type填3。4.3 成本核算移动平均法与先进先出的取舍零配件价格在波动同一个滤芯月初进货价30元月中可能变成32元。库存账面上的purchase_price怎么维护直接决定维修毛利准不准。汽修行业最常用的是移动平均法每次采购入库后重新计算平均成本。优点是实现简单、SQL一条语句更新即可缺点是无法精确到批次。如果要做精确的批次追溯就要在stock_flow上增加batch_no字段出库时按先进先出规则从最早批次扣减。这对配件批次有严格要求的场合比如轮胎的日期批次是必要的但对普通滤芯、机油、刹车片反而增加操作负担。我的建议是普通汽修门店用移动平均法4S店售后或连锁维修中心用先进先出。4.4 预警通知的落地cron脚本怎么查有了预警线还要有触达手段。在Linux服务器上配置一条cron让系统每隔半小时跑一次低库存检查脚本*/30 * * * * /usr/bin/php /var/www/repair/cron/stock_alert.php /var/log/stock_alert.log 21stock_alert.php内部先执行4.1里的低库存SQL再把结果逐条写入一张alert_message队列表由后台的CLI进程读取队列表并推送。这样做的好处是报警查询本身只花了很少的时间在MySQL上如果库存量很大推送消息慢也不会阻塞门店的ERP操作流程。这就是典型的php队列思路业务进程只负责生产消息消费进程负责发送。5. 报表联查把维修毛利、技师提成和呆滞件算清楚5.1 维修毛利联查避免汇总结果对不上维修毛利 工单收费金额 - 零配件成本 - 工时成本。联查时要格外注意repair_item表里item_type3的工时费只有sale_price没有cost_price所以工时成本需要额外计算技师绩效。常见做法是单独维护一张tech_bonus_rule表按维修项目类型设定提成比例报表联查时再把提成费用计算进去。SELECT DATE_FORMAT(o.created_at, %Y-%m) AS month, SUM(i.sale_price * i.qty) AS revenue, SUM(IF(i.item_type 2, i.cost_price * i.qty, 0)) AS part_cost, SUM(i.sale_price * i.qty - IF(i.item_type 2, i.cost_price * i.qty, 0)) AS gross_profit FROM repair_order o JOIN repair_item i ON i.order_id o.id WHERE o.status IN (4, 5) GROUP BY DATE_FORMAT(o.created_at, %Y-%m) ORDER BY month DESC;WHERE o.status IN (4, 5)只统计已结算和已交车的工单避免把还在维修中的单子计入营收。IF函数在SUM里做条件累加比先查出全量明细再在PHP里循环求和要高效得多尤其在工单量过万时SQL聚合的优势就出来了。5.2 技师提成统计按工单明细分组提成统计的难点在于同一张工单可能关联多个技师如果只按master_tech_id分组会漏掉协助技师的提成。常见做法是在repair_item上加一个tech_id字段表示这条维修项目是哪位技师完成的主修技师和协修技师分开落库。SELECT t.real_name AS tech_name, SUM(i.sale_price) AS work_fee, SUM(i.sale_price) * 0.3 AS bonus FROM repair_item i JOIN repair_order o ON o.id i.order_id JOIN user_tech t ON t.id i.tech_id WHERE i.item_type 1 AND o.status 5 AND o.created_at BETWEEN 2025-06-01 AND 2025-06-30 GROUP BY i.tech_id;这里的提成比例直接用0.3硬编码实际项目建议放进配置表或tech_level字段里因为同一位技师在不同项目上的提成可能不同。筛选o.status 5而不是4是为了避免已结算但还没交车就提前算提成万一车辆返修还要冲红。5.3 呆滞件识别90天没有出库的零配件呆滞件是汽修门店资金占用的大头。识别方法很直接在流水表里近90天没有任何flow_type2出库记录的配件列出来做促销或退回供应商。SELECT p.part_no, p.part_name, p.stock_qty, p.sale_price, p.stock_qty * p.sale_price AS occupy_amount FROM part p LEFT JOIN stock_flow f ON f.part_id p.id AND f.flow_type 2 AND f.created_at DATE_SUB(NOW(), INTERVAL 90 DAY) WHERE p.stock_qty 0 GROUP BY p.id HAVING COUNT(f.id) 0 ORDER BY occupy_amount DESC;把所有“有库存、近90天无人问津、且积压资金高”的配件按占用金额排序排在前面的是最应该处理的呆滞件。跑完这几条SQL月底对账时财务只需要输出三张表维修毛利润表、技师提成表、呆滞件清单整个闭环就完整了。本文还有配套的精品资源点击获取
