做汽车维修保养管理这块的信息系统我前后接触过好几轮需求。最常见的场景是门店老板用Excel记客户信息、维修工单靠手写、配件库存有没有货全凭老师傅脑内记忆月底对账把前台累够呛。这套Python汽车维修保养服务信息系统就是把客户的车辆档案、维修工单、配件出入库、保养提醒、营收统计串成一条线让前台、技师、老板各干各的活数据在后台自动对齐。这篇复盘不打算贴一张运行截图就完事。我会把整个项目从需求拆解、技术选型、数据库设计到核心模块实现再到调试和试运行阶段踩过的坑完整过一遍。适合两类人看一是自己开店想上管理系统、但不知道从哪里下手的经营者二是准备拿这个方向做练手项目的Python开发者。你会看到我在每个关键环节为什么做这个选择以及真正跑起来之后才发现的问题。1. 需求拆解汽修店真正需要的是什么很多初学者拿到汽车维修保养信息系统这类题目第一反应是做一套增删改查——客户表能加能改能删维修单能录能查然后就完了。真正到门店里待两天你会发现业务流远不是CRUD那么简单一个客户可能有两台车一台在保养周期内一台已经过保维修过程中可能追加项目报价要重新确认配件从下单到出库中间还有采购环节。所以第一步不是写代码而是把业务角色和流程盘清楚。1.1 业务角色与权限边界这套系统的用户分三类管理员通常是老板、员工前台接待和维修技师、车主。三者看到的界面和能做的事情应该完全不一样。管理员管理员工账号、查看全店报表、维护配件信息、处理预约、调整异常工单状态。前台/技师前台负责接车、开单、结算技师负责查看派给自己的工单、填写维修项目和工时、标记完工。建议在员工表上加职位字段或者直接用Django自带的Group权限来区分。车主注册登录后看自己的车辆档案、历史保养记录、待办提醒比如该保养了也可以在线提交预约。一开始我图省事没怎么用Django自带的Group直接在视图函数里判断user.role后来加细分权限需求的时候改得头疼。权限这个东西别自己造轮子Django的auth框架已经封装好Group和Permission虽然配置起来稍微绕一点后面维护省心太多。我自己后面重构项目时把权限全部迁到Group里给前台和技师各建一个组按组分配权限彻底告别到处写if判断的日子。1.2 核心业务流程梳理我梳理业务时习惯先画状态流转图而不是列功能清单。功能清单只能告诉你有哪些页面状态流转才能告诉你数据怎么动。维修保养的核心流程是这样车辆进店 → 前台接车检查记录当前里程、外观状况 → 技师诊断列维修/保养项目清单和预估费用 → 客户确认签字 → 排工位、派工 → 维修/保养施工 → 质检 → 结算 → 离店每一个环节都对应工单上的一个状态值。状态字段设计得好不好直接决定后面统计报表好不好写。这个我后面单独展开。除了主线流程还有一条并行线配件和物料的流转。维修单上的每个项目可能用到配件配件从仓库出库时要扣减库存库存低于阈值要触发采购提醒。这两条线如果不同步就会出现工单显示完成了但库存对不上的尴尬局面。1.3 功能优先级排序功能不是越多越好。我按门店实际使用频率给功能排了个序排在前面的才是核心中的核心工单管理开单、派工、状态流转、结算车辆档案与保养记录客户来店一查车牌就知道历史配件库存入库、出库、库存预警预约管理工位时间冲突处理营收与工单统计报表至于消息推送、短信提醒、在线支付这些第一版完全可以不做。先把核心跑通再考虑锦上添花。有位客户非要在第一版就带上小程序预约功能结果小程序那边拖了两个月核心系统也跟着延期。边界感一定要清晰这个教训比较深刻。2. 技术选型为什么是Django而不是Flask这类项目用Python做框架基本就在Django和Flask之间选。我给这个项目选了Django理由很实在自带Admin后台、自带ORM、自带用户认证和权限体系还提供了现成的数据库迁移工具。Flask虽然轻量灵活但用户注册、权限、Admin这些都要自己搭或者引入第三方库对业务型项目来说起步成本高了一大截。2.1 框架选择的取舍逻辑说句公道话Flask不是不行。我见过用Flask SQLAlchemy做得非常漂亮的项目。但这里有一个现实考量这个系统的功能密度高——用户、车辆、工单、维修项目、配件、库存流水、预约、报表十几个模型互相外键关联。用Django的ORM和Admin模型定义完后台管理页面几乎白送开发效率差一倍都不止。Django的MTV架构对业务系统非常友好Model层直接映射数据库表ORM写查询不用拼SQLTemplate层用原生模板语法渲染页面简单直接View层处理请求和业务逻辑代码组织清晰。唯一的缺点是Django有上手成本需要理解settings配置、URL路由、中间件这些概念。但对一个完整的业务系统来说这些成本是值得的。另一个隐性好处是Django文档和社区资料多遇到问题搜一下基本都有答案对独立开发者来说这一点能省下大量排查时间。2.2 数据库与运行环境数据库选的MySQL 8.0部署在门店的Windows服务器上。开发环境用SQLite部署时切到MySQL——Django的ORM让这种切换成本极低只需要改settings里的DATABASES配置。但有个关键点要注意SQLite对并发写入支持很弱多员工同时操作时容易报database is locked。所以测试环境跑通不代表线上没问题生产环境务必换MySQL或PostgreSQL。Python版本用3.10Django用4.x的LTS版本MySQL连接用mysqlclient。这块踩过一个坑Windows上安装mysqlclient经常编译失败后来直接安装预编译的wheel包才解决。如果你的Windows环境装不上可以改用PyMySQL并修改Django的数据库引擎配置但整体性能上不如mysqlclient建议还是想办法装好。2.3 前端方案模板引擎足够用了这个项目的前端用的是Django模板加Bootstrap 5没有做前后端分离。原因很简单这是门店内部使用的系统并发量很小交互以表单提交为主。Vue、React那套虽然功能强大但需要额外部署Node环境、写接口、处理跨域对一个三五个人使用的内部系统来说纯属增加复杂度反而拖慢交付进度。Bootstrap的优势是响应式做得好员工用平板、手机、电脑都能操作。我在AdminLTE这个开源管理后台模板基础上改的页面它自带侧边栏、导航、卡片、表格样式省去大量写CSS的时间。这套方案的好处是员工培训成本低浏览器打开即用不用装客户端门店老板也觉得页面看起来像那么回事。3. 数据库建模把维修业务翻译成表结构数据库设计是整个系统最重要的一步表结构没设计好后面写功能会写到怀疑人生。我的经验是先画模型关系图再写代码。哪怕只是拿纸笔画一下也比直接对着models.py敲强得多。这里说的建模不是指画ER图那种形式化的输出而是要把业务问题逐条翻译成字段。3.1 核心表结构与关系这个系统的核心表我认为有六张用户表直接继承Django自带的auth_user不要自己另建用户表除非有特殊需求。员工和车主都放这里用role字段区分身份。客户表记录车主的姓名、联系方式、地址、备注和User关联也可以不关联——线下进店的客户不一定要有线上账号。车辆表车牌号、VIN码、品牌型号、年款、发动机号、当前里程、上次保养里程、下次保养里程/日期、保险到期日。一个客户可以有多台车这块是个典型的一对多。工单表关联车辆和客户记录接车时间、当前里程、接待人、维修类型保养/维修/事故、状态、诊断描述、客户确认信息、质检结果、结算金额。工单明细表每条工单下有多个维修项目比如换机油、换机滤、四轮定位关联维修项目表或直接存项目名称、工时费、材料费如果项目用到配件还要关联配件。配件表与库存流水表配件表记录配件名称、编号、适用车型、采购价、销售价、当前库存量、安全库存线库存流水表记录每次入库、出库、盘点调整的变动明细。表之间的关系客户一对多车辆车辆一对多工单工单一对多明细配件和工单明细是多对多。用Django的ForeignKey和ManyToManyField表达即可。这里特别想强调一个容易被忽略的点工单上的金额和配件价格不应该实时去关联表里算。比如配件后来涨价了三个月前那张工单上的价格应该保持不变。所以工单明细表里要冗余存储成交价格字段显示历史单据时直接读这个字段而不是再去查配件当前价格。历史单据的金额必须固化这一点在财务对账时非常重要。3.2 金额与时间字段的坑两个典型的坑提前说清楚第一个金额字段用DecimalField不要用FloatField。Float在Python里是双精度浮点数0.1加0.2这种精度问题在金额计算里完全不能接受。Django的定义方式from django.db import models class WorkOrder(models.Model): total_amount models.DecimalField(max_digits10, decimal_places2, default0)max_digits10表示最多10位数字decimal_places2表示保留两位小数。普通汽修店的单笔金额上千万是不可能的这个精度完全够用。第二个时间字段用DateTimeField别用DateField。工单要记录接车时刻、完工时刻不仅仅是日期。而且Django的DateTimeField配合时区设置可以避免很多时间显示错乱的问题。settings里这样配置USE_TZ True TIME_ZONE Asia/Shanghai这两个设置在Django 4.x里是默认的但很多人忽略USE_TZ的含义——数据库存UTC时间页面显示时转本地时间。如果不想折腾时区可以把USE_TZ设为False数据库直接存本地时间但这样部署到不同时区的服务器上就会出问题。我的建议是保持USE_TZTrue模板渲染时Django会自动按TIME_ZONE转换。3.3 工单状态机的设计工单状态我用字符串常量加choices定义放在模型类里class WorkOrder(models.Model): STATUS_PENDING pending # 待接车 STATUS_CHECKED checked # 已接车/检查中 STATUS_QUOTED quoted # 已报价待确认 STATUS_WORKING working # 维修中 STATUS_QUALITY quality # 质检中 STATUS_SETTLEMENT settlement # 待结算 STATUS_COMPLETED completed # 已完成 STATUS_CANCELLED cancelled # 已取消 STATUS_CHOICES [ (STATUS_PENDING, 待接车), (STATUS_CHECKED, 已接车), (STATUS_QUOTED, 已报价), (STATUS_WORKING, 维修中), (STATUS_QUALITY, 质检中), (STATUS_SETTLEMENT, 待结算), (STATUS_COMPLETED, 已完成), (STATUS_CANCELLED, 已取消), ] status models.CharField(max_length20, choicesSTATUS_CHOICES, defaultSTATUS_PENDING)为什么用字符串而不是数字因为字符串的可读性更好代码里写STATUS_WORKING比写2直观太多数据库里存的也是可读的英文排查问题的时候一眼就能看懂。状态流转控制我单独写了一个service层函数不放在视图里。视图只负责接收请求并调用service状态逻辑可以复用也好写单元测试。比如接车操作就是一个带状态校验的函数只有pending状态可以转为checked如果工单已经进入working就不能再退回pending除非有特殊情况需要手动撤回那要走另一个带权限校验和管理员审批的接口。状态机的核心价值就是让数据流转路径可控不给人乱操作的机会。4. 核心模块实现从预约到结算的完整闭环下面挑几个核心模块讲讲实现思路和关键代码。这些模块连起来就是一条完整的业务闭环客户预约、前台接车开单、技师施工、配件出库、质检结算。4.1 预约管理与工位冲突检测预约模块的逻辑核心不是增删改查而是冲突检测。门店通常有固定数量的工位比如举升机位、四轮定位仪同一时间段不能有两个预约占用同一个工位。我的做法是给预约表加两个字段appointment_time预约时间和duration预计时长单位分钟。提交预约时检查同一天、同一工位是否存在时间重叠的预约from datetime import timedelta def check_slot_available(workstation_id, start_time, duration): end_time start_time timedelta(minutesduration) conflicts Appointment.objects.filter( workstation_idworkstation_id, status__in[pending, confirmed], appointment_time__ltend_time, ).exclude( appointment_time__gteend_time timedelta(minutes1) ) return not conflicts.exists()这段逻辑里最麻烦的是边界情况前一单15:00结束、后一单15:00开始理论上不冲突但如果判断条件写错了系统会误判。我调试时用了一个比较笨的办法——把各种时间组合的测试用例写全包含边界触顶、触底、跨天的情况确认通过之后才放心。工位资源用一张WorkStation表维护字段就是工位名称、类型、是否启用。预约成功后生成关联工单草稿客户到店后由前台确认并正式开单。4.2 工单流转与事务处理工单流转最怕数据不一致——比如工单标记完工了但配件出库记录没生成或者结算了但库存没有扣减。这种跨表操作必须用数据库事务。以完成维修并扣减库存为例from django.db import transaction transaction.atomic def finish_work_order(order_id): order WorkOrder.objects.select_for_update().get(pkorder_id) if order.status ! WorkOrder.STATUS_WORKING: raise ValueError(当前状态不能执行完工操作) # 遍历工单明细扣减配件库存 for item in order.items.select_related(part): if item.part: part Parts.objects.select_for_update().get(pkitem.part.pk) if part.stock item.quantity: raise ValueError(f配件 {part.name} 库存不足) part.stock - item.quantity part.save() StockLog.objects.create( partpart, change-item.quantity, orderorder, log_typeout ) # 更新工单状态 order.status WorkOrder.STATUS_QUALITY order.finished_at timezone.now() order.save()select_for_update()是这里的关键——它在事务里对行加锁防止两个请求同时扣减同一配件的库存。库存扣减最常见的并发问题就是超卖两个工单同时看到库存还剩2件各自扣1件最终库存变成1件而不是0件。加锁之后第二个请求必须等第一个事务提交才能读到最新数据。这个坑我在之前做其他库存系统时踩过一次印象非常深刻。4.3 配件库存与安全预警配件模块看起来简单但库存流水的设计决定了对账是否顺畅。我用了两张表Parts表存配件实时库存快照StockLog表存每次变动的流水。任何出入库操作都同时修改快照和新增流水记录这样万一数据对不上可以通过流水倒推复盘定位是谁在什么时间改的。低于安全库存线时触发预警我用定时任务实现每天早上跑一次查询库存低于安全线的配件列表生成待办消息提醒。第一版用Django的manage.py命令加Windows计划任务后来改成了Celery的定时任务。如果你不想引入Celery就写一个manage.py命令然后用系统计划任务每小时跑一次效果完全一样。少引入一个队列中间件系统反而更稳定我的体会是内部系统能少一个组件就少一个组件。4.4 保养提醒里程与时间双触发保养提醒的算法要同时考虑里程和时间两个维度每5000公里或每6个月哪个先到就提醒。车辆表里存了last_maintenance_km和last_maintenance_date判断逻辑就是current_km vehicle.current_km current_date timezone.localdate() if (current_km - vehicle.last_maintenance_km) 5000 or \ (current_date - vehicle.last_maintenance_date).days 180: # 生成保养提醒 generate_reminder(vehicle)为了防止重复提醒提醒记录表里加了一个status字段每次生成提醒时检查同类型、同车辆、未处理的提醒是否已存在。否则客户一直没到店系统每天生成一条前台还没崩溃数据库先堆满了。提醒推送的入口可以是站内消息也可以是短信接口第一版先做站内消息客户在登录后的首页就能看到。5. 报表统计与查询优化报表是老板最看重的模块但对开发者来说真正有技术含量的是怎么写才不卡。门店规模不大数据量可能就几万条但如果查询写得烂一样能把页面拖到好几秒。5.1 月度营收统计的ORM写法月度营收统计的核心就是按月份分组聚合。用Django ORM写from django.db.models import Sum, Count from django.db.models.functions import TruncMonth monthly_stats WorkOrder.objects.filter( statusWorkOrder.STATUS_COMPLETED, completed_at__year2025 ).annotate( monthTruncMonth(completed_at) ).values(month).annotate( total_incomeSum(total_amount), order_countCount(id) ).order_by(month)TruncMonth是Django的数据库函数作用是把时间截断到月份再分组最终生成的SQL是DATE_FORMAT或者date_trunc效率比在Python里循环统计高得多。顺带说一句老板的报表维度不只是月度营收还有按维修类型分类的占比、按员工计算的工作量、客户到店频次分布。这些报表最好做成独立的统计页每张报表一个视图函数不要塞在一个页面里页面加载会慢。5.2 N1查询问题这是所有Django开发者都会遇到的性能问题。在工单列表页显示每条工单的车牌号和客户名时如果直接访问order.vehicle.customer.nameORM会为每条记录额外执行一次查询——100条工单就是101次查询。解决方法是使用select_relatedorders WorkOrder.objects.select_related(vehicle__customer).all()select_related适用于ForeignKey和OneToOneField通过JOIN一次查出关联数据。如果是多对多关系要改用prefetch_related。刚开始我老是忘写后来养成习惯凡是列表页涉及关联字段的先想想这个页面会循环输出什么需要哪些关联数据提前用select_related或prefetch_related查出来。页面响应从秒级降到毫秒级这个优化性价比极高。再补一个索引建议工单表经常按状态和时间筛选给status和completed_at建联合索引预约表经常按工位和时间筛选给workstation_id和appointment_time建联合索引。Django的Meta类里直接定义class Meta: indexes [ models.Index(fields[status, completed_at]), ]数据量在十万条以内时索引效果不明显但门店系统跑两三年工单和流水数据积累到几十万条很正常。提前把索引建好后面就不用再折腾数据库迁移。6. 常见问题与排查实录项目从开发到试运行我整理了高频问题做成速查表分享出来给后来者参考。问题现象根因分析解决方案SQLite报database is lockedSQLite并发写入能力弱生产环境换MySQL/PostgreSQLWindows安装mysqlclient失败缺少编译工具链下载预编译wheel包安装列表页加载很慢未使用select_related导致N1查询检查ORM语句补上select_related金额对不上FloatField浮点精度丢失全部改用DecimalField工单状态乱跳视图里直接改status没有校验统一走service层的状态流转函数预约时间冲突区间判断边界没处理好用开始小于结束且反向的条件做交集判断库存出现负数并发扣减未加锁事务内使用select_for_update线上时间差8小时USE_TZ配置不一致统一USE_TZTrue加TIME_ZONE设置6.1 库存对不上的排查案例试运行期间遇到过一次典型问题系统里显示某配件库存还有3件但仓库实际只有1件。一开始以为是员工领料没登记后来翻StockLog流水发现某天凌晨有一笔出库记录的数量是负数导致库存越减越多。查代码发现是某条导入路由没有做参数校验前端传进来的数量直接累加到了库存上。把quantity字段的校验补上必须大于0、小于等于当前库存再给库存变动入口加统一审计问题才彻底解决。这个经历让我定下一个规矩所有涉及库存变动的入口都必须调用同一个service函数不要在每个视图里各写一套操作逻辑否则数据迟早出漏洞。6.2 老数据迁移与试运行准备试运行阶段最痛苦的是老数据迁移。门店原来的Excel表格里有三千多条客户和车辆记录清洗、去重、导入花了三天时间。经验是导入前一定先做字段映射文档确认Excel的每一列对应表里的哪个字段日期格式怎么统一、手机号怎么清洗、重复车牌怎么处理。导入脚本先在副本库跑一遍核对完数据数量再进行正式库操作。这一步别赶时间数据错了后面排查的代价远大于导入前多花的一两天。7. 实操后的几点体会7.1 界面简洁比功能多更重要这类业务系统成功与否的标准不是代码多漂亮而是门店员工愿不愿意用。我见过功能很全的系统因为操作路径太长被员工弃用大家又回到Excel的老路。所以设计页面时能少点一次就少点一次接车、开单、结算这些高频操作一定要在一屏内完成。我在接车页面用了大量默认值——车辆信息从档案自动带出常用维修项目支持一键选择就是为了让前台在客户等待的间隙快速完成录入。员工用得顺手数据才养得起来。7.2 状态机是这类系统的灵魂与其花时间堆功能不如先把状态流转的边界条件想清楚——每个状态下能做什么、不能做什么、谁有权限做。这一块想清楚报表好写、权限好控、bug好排查。我见过一些半成品项目工单状态随便改、金额随便调最后统计出来的数据根本没法看。状态机不只是一个字段和一串判断更是业务规则的具象化值得花最多的心思去设计。7.3 第一版就把测试写上如果你准备拿这个题目做练手项目建议第一版就把单元测试写出来重点覆盖状态流转和库存扣减两条核心逻辑。Django的TestCase框架写起来并不麻烦但能保证后续改动不把老功能弄坏。我当时偷懒没写测试后面加功能回归全靠人肉点时间成本非常高而且总有漏测的地方。后来补上测试每次改动跑一遍测试集心里踏实很多。这套系统从需求确认到第一版上线前后大约用了六周。如果你也在做类似的维修保养业务系统希望这篇复盘能帮你少走弯路。核心就一句话先盘业务再定表结构最后才是动手写代码。 
长河君 · 2026/10/21 12:20:12 · 阅读 1.2k 基于Django的汽车维修保养管理系统：从需求到落地的完整复盘
做汽车维修保养管理这块的信息系统我前后接触过好几轮需求。最常见的场景是门店老板用Excel记客户信息、维修工单靠手写、配件库存有没有货全凭老师傅脑内记忆月底对账把前台累够呛。这套Python汽车维修保养服务信息系统就是把客户的车辆档案、维修工单、配件出入库、保养提醒、营收统计串成一条线让前台、技师、老板各干各的活数据在后台自动对齐。这篇复盘不打算贴一张运行截图就完事。我会把整个项目从需求拆解、技术选型、数据库设计到核心模块实现再到调试和试运行阶段踩过的坑完整过一遍。适合两类人看一是自己开店想上管理系统、但不知道从哪里下手的经营者二是准备拿这个方向做练手项目的Python开发者。你会看到我在每个关键环节为什么做这个选择以及真正跑起来之后才发现的问题。1. 需求拆解汽修店真正需要的是什么很多初学者拿到汽车维修保养信息系统这类题目第一反应是做一套增删改查——客户表能加能改能删维修单能录能查然后就完了。真正到门店里待两天你会发现业务流远不是CRUD那么简单一个客户可能有两台车一台在保养周期内一台已经过保维修过程中可能追加项目报价要重新确认配件从下单到出库中间还有采购环节。所以第一步不是写代码而是把业务角色和流程盘清楚。1.1 业务角色与权限边界这套系统的用户分三类管理员通常是老板、员工前台接待和维修技师、车主。三者看到的界面和能做的事情应该完全不一样。管理员管理员工账号、查看全店报表、维护配件信息、处理预约、调整异常工单状态。前台/技师前台负责接车、开单、结算技师负责查看派给自己的工单、填写维修项目和工时、标记完工。建议在员工表上加职位字段或者直接用Django自带的Group权限来区分。车主注册登录后看自己的车辆档案、历史保养记录、待办提醒比如该保养了也可以在线提交预约。一开始我图省事没怎么用Django自带的Group直接在视图函数里判断user.role后来加细分权限需求的时候改得头疼。权限这个东西别自己造轮子Django的auth框架已经封装好Group和Permission虽然配置起来稍微绕一点后面维护省心太多。我自己后面重构项目时把权限全部迁到Group里给前台和技师各建一个组按组分配权限彻底告别到处写if判断的日子。1.2 核心业务流程梳理我梳理业务时习惯先画状态流转图而不是列功能清单。功能清单只能告诉你有哪些页面状态流转才能告诉你数据怎么动。维修保养的核心流程是这样车辆进店 → 前台接车检查记录当前里程、外观状况 → 技师诊断列维修/保养项目清单和预估费用 → 客户确认签字 → 排工位、派工 → 维修/保养施工 → 质检 → 结算 → 离店每一个环节都对应工单上的一个状态值。状态字段设计得好不好直接决定后面统计报表好不好写。这个我后面单独展开。除了主线流程还有一条并行线配件和物料的流转。维修单上的每个项目可能用到配件配件从仓库出库时要扣减库存库存低于阈值要触发采购提醒。这两条线如果不同步就会出现工单显示完成了但库存对不上的尴尬局面。1.3 功能优先级排序功能不是越多越好。我按门店实际使用频率给功能排了个序排在前面的才是核心中的核心工单管理开单、派工、状态流转、结算车辆档案与保养记录客户来店一查车牌就知道历史配件库存入库、出库、库存预警预约管理工位时间冲突处理营收与工单统计报表至于消息推送、短信提醒、在线支付这些第一版完全可以不做。先把核心跑通再考虑锦上添花。有位客户非要在第一版就带上小程序预约功能结果小程序那边拖了两个月核心系统也跟着延期。边界感一定要清晰这个教训比较深刻。2. 技术选型为什么是Django而不是Flask这类项目用Python做框架基本就在Django和Flask之间选。我给这个项目选了Django理由很实在自带Admin后台、自带ORM、自带用户认证和权限体系还提供了现成的数据库迁移工具。Flask虽然轻量灵活但用户注册、权限、Admin这些都要自己搭或者引入第三方库对业务型项目来说起步成本高了一大截。2.1 框架选择的取舍逻辑说句公道话Flask不是不行。我见过用Flask SQLAlchemy做得非常漂亮的项目。但这里有一个现实考量这个系统的功能密度高——用户、车辆、工单、维修项目、配件、库存流水、预约、报表十几个模型互相外键关联。用Django的ORM和Admin模型定义完后台管理页面几乎白送开发效率差一倍都不止。Django的MTV架构对业务系统非常友好Model层直接映射数据库表ORM写查询不用拼SQLTemplate层用原生模板语法渲染页面简单直接View层处理请求和业务逻辑代码组织清晰。唯一的缺点是Django有上手成本需要理解settings配置、URL路由、中间件这些概念。但对一个完整的业务系统来说这些成本是值得的。另一个隐性好处是Django文档和社区资料多遇到问题搜一下基本都有答案对独立开发者来说这一点能省下大量排查时间。2.2 数据库与运行环境数据库选的MySQL 8.0部署在门店的Windows服务器上。开发环境用SQLite部署时切到MySQL——Django的ORM让这种切换成本极低只需要改settings里的DATABASES配置。但有个关键点要注意SQLite对并发写入支持很弱多员工同时操作时容易报database is locked。所以测试环境跑通不代表线上没问题生产环境务必换MySQL或PostgreSQL。Python版本用3.10Django用4.x的LTS版本MySQL连接用mysqlclient。这块踩过一个坑Windows上安装mysqlclient经常编译失败后来直接安装预编译的wheel包才解决。如果你的Windows环境装不上可以改用PyMySQL并修改Django的数据库引擎配置但整体性能上不如mysqlclient建议还是想办法装好。2.3 前端方案模板引擎足够用了这个项目的前端用的是Django模板加Bootstrap 5没有做前后端分离。原因很简单这是门店内部使用的系统并发量很小交互以表单提交为主。Vue、React那套虽然功能强大但需要额外部署Node环境、写接口、处理跨域对一个三五个人使用的内部系统来说纯属增加复杂度反而拖慢交付进度。Bootstrap的优势是响应式做得好员工用平板、手机、电脑都能操作。我在AdminLTE这个开源管理后台模板基础上改的页面它自带侧边栏、导航、卡片、表格样式省去大量写CSS的时间。这套方案的好处是员工培训成本低浏览器打开即用不用装客户端门店老板也觉得页面看起来像那么回事。3. 数据库建模把维修业务翻译成表结构数据库设计是整个系统最重要的一步表结构没设计好后面写功能会写到怀疑人生。我的经验是先画模型关系图再写代码。哪怕只是拿纸笔画一下也比直接对着models.py敲强得多。这里说的建模不是指画ER图那种形式化的输出而是要把业务问题逐条翻译成字段。3.1 核心表结构与关系这个系统的核心表我认为有六张用户表直接继承Django自带的auth_user不要自己另建用户表除非有特殊需求。员工和车主都放这里用role字段区分身份。客户表记录车主的姓名、联系方式、地址、备注和User关联也可以不关联——线下进店的客户不一定要有线上账号。车辆表车牌号、VIN码、品牌型号、年款、发动机号、当前里程、上次保养里程、下次保养里程/日期、保险到期日。一个客户可以有多台车这块是个典型的一对多。工单表关联车辆和客户记录接车时间、当前里程、接待人、维修类型保养/维修/事故、状态、诊断描述、客户确认信息、质检结果、结算金额。工单明细表每条工单下有多个维修项目比如换机油、换机滤、四轮定位关联维修项目表或直接存项目名称、工时费、材料费如果项目用到配件还要关联配件。配件表与库存流水表配件表记录配件名称、编号、适用车型、采购价、销售价、当前库存量、安全库存线库存流水表记录每次入库、出库、盘点调整的变动明细。表之间的关系客户一对多车辆车辆一对多工单工单一对多明细配件和工单明细是多对多。用Django的ForeignKey和ManyToManyField表达即可。这里特别想强调一个容易被忽略的点工单上的金额和配件价格不应该实时去关联表里算。比如配件后来涨价了三个月前那张工单上的价格应该保持不变。所以工单明细表里要冗余存储成交价格字段显示历史单据时直接读这个字段而不是再去查配件当前价格。历史单据的金额必须固化这一点在财务对账时非常重要。3.2 金额与时间字段的坑两个典型的坑提前说清楚第一个金额字段用DecimalField不要用FloatField。Float在Python里是双精度浮点数0.1加0.2这种精度问题在金额计算里完全不能接受。Django的定义方式from django.db import models class WorkOrder(models.Model): total_amount models.DecimalField(max_digits10, decimal_places2, default0)max_digits10表示最多10位数字decimal_places2表示保留两位小数。普通汽修店的单笔金额上千万是不可能的这个精度完全够用。第二个时间字段用DateTimeField别用DateField。工单要记录接车时刻、完工时刻不仅仅是日期。而且Django的DateTimeField配合时区设置可以避免很多时间显示错乱的问题。settings里这样配置USE_TZ True TIME_ZONE Asia/Shanghai这两个设置在Django 4.x里是默认的但很多人忽略USE_TZ的含义——数据库存UTC时间页面显示时转本地时间。如果不想折腾时区可以把USE_TZ设为False数据库直接存本地时间但这样部署到不同时区的服务器上就会出问题。我的建议是保持USE_TZTrue模板渲染时Django会自动按TIME_ZONE转换。3.3 工单状态机的设计工单状态我用字符串常量加choices定义放在模型类里class WorkOrder(models.Model): STATUS_PENDING pending # 待接车 STATUS_CHECKED checked # 已接车/检查中 STATUS_QUOTED quoted # 已报价待确认 STATUS_WORKING working # 维修中 STATUS_QUALITY quality # 质检中 STATUS_SETTLEMENT settlement # 待结算 STATUS_COMPLETED completed # 已完成 STATUS_CANCELLED cancelled # 已取消 STATUS_CHOICES [ (STATUS_PENDING, 待接车), (STATUS_CHECKED, 已接车), (STATUS_QUOTED, 已报价), (STATUS_WORKING, 维修中), (STATUS_QUALITY, 质检中), (STATUS_SETTLEMENT, 待结算), (STATUS_COMPLETED, 已完成), (STATUS_CANCELLED, 已取消), ] status models.CharField(max_length20, choicesSTATUS_CHOICES, defaultSTATUS_PENDING)为什么用字符串而不是数字因为字符串的可读性更好代码里写STATUS_WORKING比写2直观太多数据库里存的也是可读的英文排查问题的时候一眼就能看懂。状态流转控制我单独写了一个service层函数不放在视图里。视图只负责接收请求并调用service状态逻辑可以复用也好写单元测试。比如接车操作就是一个带状态校验的函数只有pending状态可以转为checked如果工单已经进入working就不能再退回pending除非有特殊情况需要手动撤回那要走另一个带权限校验和管理员审批的接口。状态机的核心价值就是让数据流转路径可控不给人乱操作的机会。4. 核心模块实现从预约到结算的完整闭环下面挑几个核心模块讲讲实现思路和关键代码。这些模块连起来就是一条完整的业务闭环客户预约、前台接车开单、技师施工、配件出库、质检结算。4.1 预约管理与工位冲突检测预约模块的逻辑核心不是增删改查而是冲突检测。门店通常有固定数量的工位比如举升机位、四轮定位仪同一时间段不能有两个预约占用同一个工位。我的做法是给预约表加两个字段appointment_time预约时间和duration预计时长单位分钟。提交预约时检查同一天、同一工位是否存在时间重叠的预约from datetime import timedelta def check_slot_available(workstation_id, start_time, duration): end_time start_time timedelta(minutesduration) conflicts Appointment.objects.filter( workstation_idworkstation_id, status__in[pending, confirmed], appointment_time__ltend_time, ).exclude( appointment_time__gteend_time timedelta(minutes1) ) return not conflicts.exists()这段逻辑里最麻烦的是边界情况前一单15:00结束、后一单15:00开始理论上不冲突但如果判断条件写错了系统会误判。我调试时用了一个比较笨的办法——把各种时间组合的测试用例写全包含边界触顶、触底、跨天的情况确认通过之后才放心。工位资源用一张WorkStation表维护字段就是工位名称、类型、是否启用。预约成功后生成关联工单草稿客户到店后由前台确认并正式开单。4.2 工单流转与事务处理工单流转最怕数据不一致——比如工单标记完工了但配件出库记录没生成或者结算了但库存没有扣减。这种跨表操作必须用数据库事务。以完成维修并扣减库存为例from django.db import transaction transaction.atomic def finish_work_order(order_id): order WorkOrder.objects.select_for_update().get(pkorder_id) if order.status ! WorkOrder.STATUS_WORKING: raise ValueError(当前状态不能执行完工操作) # 遍历工单明细扣减配件库存 for item in order.items.select_related(part): if item.part: part Parts.objects.select_for_update().get(pkitem.part.pk) if part.stock item.quantity: raise ValueError(f配件 {part.name} 库存不足) part.stock - item.quantity part.save() StockLog.objects.create( partpart, change-item.quantity, orderorder, log_typeout ) # 更新工单状态 order.status WorkOrder.STATUS_QUALITY order.finished_at timezone.now() order.save()select_for_update()是这里的关键——它在事务里对行加锁防止两个请求同时扣减同一配件的库存。库存扣减最常见的并发问题就是超卖两个工单同时看到库存还剩2件各自扣1件最终库存变成1件而不是0件。加锁之后第二个请求必须等第一个事务提交才能读到最新数据。这个坑我在之前做其他库存系统时踩过一次印象非常深刻。4.3 配件库存与安全预警配件模块看起来简单但库存流水的设计决定了对账是否顺畅。我用了两张表Parts表存配件实时库存快照StockLog表存每次变动的流水。任何出入库操作都同时修改快照和新增流水记录这样万一数据对不上可以通过流水倒推复盘定位是谁在什么时间改的。低于安全库存线时触发预警我用定时任务实现每天早上跑一次查询库存低于安全线的配件列表生成待办消息提醒。第一版用Django的manage.py命令加Windows计划任务后来改成了Celery的定时任务。如果你不想引入Celery就写一个manage.py命令然后用系统计划任务每小时跑一次效果完全一样。少引入一个队列中间件系统反而更稳定我的体会是内部系统能少一个组件就少一个组件。4.4 保养提醒里程与时间双触发保养提醒的算法要同时考虑里程和时间两个维度每5000公里或每6个月哪个先到就提醒。车辆表里存了last_maintenance_km和last_maintenance_date判断逻辑就是current_km vehicle.current_km current_date timezone.localdate() if (current_km - vehicle.last_maintenance_km) 5000 or \ (current_date - vehicle.last_maintenance_date).days 180: # 生成保养提醒 generate_reminder(vehicle)为了防止重复提醒提醒记录表里加了一个status字段每次生成提醒时检查同类型、同车辆、未处理的提醒是否已存在。否则客户一直没到店系统每天生成一条前台还没崩溃数据库先堆满了。提醒推送的入口可以是站内消息也可以是短信接口第一版先做站内消息客户在登录后的首页就能看到。5. 报表统计与查询优化报表是老板最看重的模块但对开发者来说真正有技术含量的是怎么写才不卡。门店规模不大数据量可能就几万条但如果查询写得烂一样能把页面拖到好几秒。5.1 月度营收统计的ORM写法月度营收统计的核心就是按月份分组聚合。用Django ORM写from django.db.models import Sum, Count from django.db.models.functions import TruncMonth monthly_stats WorkOrder.objects.filter( statusWorkOrder.STATUS_COMPLETED, completed_at__year2025 ).annotate( monthTruncMonth(completed_at) ).values(month).annotate( total_incomeSum(total_amount), order_countCount(id) ).order_by(month)TruncMonth是Django的数据库函数作用是把时间截断到月份再分组最终生成的SQL是DATE_FORMAT或者date_trunc效率比在Python里循环统计高得多。顺带说一句老板的报表维度不只是月度营收还有按维修类型分类的占比、按员工计算的工作量、客户到店频次分布。这些报表最好做成独立的统计页每张报表一个视图函数不要塞在一个页面里页面加载会慢。5.2 N1查询问题这是所有Django开发者都会遇到的性能问题。在工单列表页显示每条工单的车牌号和客户名时如果直接访问order.vehicle.customer.nameORM会为每条记录额外执行一次查询——100条工单就是101次查询。解决方法是使用select_relatedorders WorkOrder.objects.select_related(vehicle__customer).all()select_related适用于ForeignKey和OneToOneField通过JOIN一次查出关联数据。如果是多对多关系要改用prefetch_related。刚开始我老是忘写后来养成习惯凡是列表页涉及关联字段的先想想这个页面会循环输出什么需要哪些关联数据提前用select_related或prefetch_related查出来。页面响应从秒级降到毫秒级这个优化性价比极高。再补一个索引建议工单表经常按状态和时间筛选给status和completed_at建联合索引预约表经常按工位和时间筛选给workstation_id和appointment_time建联合索引。Django的Meta类里直接定义class Meta: indexes [ models.Index(fields[status, completed_at]), ]数据量在十万条以内时索引效果不明显但门店系统跑两三年工单和流水数据积累到几十万条很正常。提前把索引建好后面就不用再折腾数据库迁移。6. 常见问题与排查实录项目从开发到试运行我整理了高频问题做成速查表分享出来给后来者参考。问题现象根因分析解决方案SQLite报database is lockedSQLite并发写入能力弱生产环境换MySQL/PostgreSQLWindows安装mysqlclient失败缺少编译工具链下载预编译wheel包安装列表页加载很慢未使用select_related导致N1查询检查ORM语句补上select_related金额对不上FloatField浮点精度丢失全部改用DecimalField工单状态乱跳视图里直接改status没有校验统一走service层的状态流转函数预约时间冲突区间判断边界没处理好用开始小于结束且反向的条件做交集判断库存出现负数并发扣减未加锁事务内使用select_for_update线上时间差8小时USE_TZ配置不一致统一USE_TZTrue加TIME_ZONE设置6.1 库存对不上的排查案例试运行期间遇到过一次典型问题系统里显示某配件库存还有3件但仓库实际只有1件。一开始以为是员工领料没登记后来翻StockLog流水发现某天凌晨有一笔出库记录的数量是负数导致库存越减越多。查代码发现是某条导入路由没有做参数校验前端传进来的数量直接累加到了库存上。把quantity字段的校验补上必须大于0、小于等于当前库存再给库存变动入口加统一审计问题才彻底解决。这个经历让我定下一个规矩所有涉及库存变动的入口都必须调用同一个service函数不要在每个视图里各写一套操作逻辑否则数据迟早出漏洞。6.2 老数据迁移与试运行准备试运行阶段最痛苦的是老数据迁移。门店原来的Excel表格里有三千多条客户和车辆记录清洗、去重、导入花了三天时间。经验是导入前一定先做字段映射文档确认Excel的每一列对应表里的哪个字段日期格式怎么统一、手机号怎么清洗、重复车牌怎么处理。导入脚本先在副本库跑一遍核对完数据数量再进行正式库操作。这一步别赶时间数据错了后面排查的代价远大于导入前多花的一两天。7. 实操后的几点体会7.1 界面简洁比功能多更重要这类业务系统成功与否的标准不是代码多漂亮而是门店员工愿不愿意用。我见过功能很全的系统因为操作路径太长被员工弃用大家又回到Excel的老路。所以设计页面时能少点一次就少点一次接车、开单、结算这些高频操作一定要在一屏内完成。我在接车页面用了大量默认值——车辆信息从档案自动带出常用维修项目支持一键选择就是为了让前台在客户等待的间隙快速完成录入。员工用得顺手数据才养得起来。7.2 状态机是这类系统的灵魂与其花时间堆功能不如先把状态流转的边界条件想清楚——每个状态下能做什么、不能做什么、谁有权限做。这一块想清楚报表好写、权限好控、bug好排查。我见过一些半成品项目工单状态随便改、金额随便调最后统计出来的数据根本没法看。状态机不只是一个字段和一串判断更是业务规则的具象化值得花最多的心思去设计。7.3 第一版就把测试写上如果你准备拿这个题目做练手项目建议第一版就把单元测试写出来重点覆盖状态流转和库存扣减两条核心逻辑。Django的TestCase框架写起来并不麻烦但能保证后续改动不把老功能弄坏。我当时偷懒没写测试后面加功能回归全靠人肉点时间成本非常高而且总有漏测的地方。后来补上测试每次改动跑一遍测试集心里踏实很多。这套系统从需求确认到第一版上线前后大约用了六周。如果你也在做类似的维修保养业务系统希望这篇复盘能帮你少走弯路。核心就一句话先盘业务再定表结构最后才是动手写代码。