基于Python和Django的汽车维修保养管理系统开发实践

“基于Python和Django的汽车维修保养管理系统”，这个标题我太熟悉了，这两年找我聊毕设选题、或者想给自家门店做套管理工具的同行，十有八九都会落到这个组合上。Python生态成熟、Django开箱即用的Admin后台和ORM，恰好匹配“维修保养管理”这种典型的数据增删改查加业务流程流转的场景。整套系统做下来，你既能摸清一个真实管理系统从设计到落地的全过程，又能把Python和Django的知识串成线，项目经历拿出去也站得住脚。

我会把这套系统的完整设计思路、数据库建模、核心业务逻辑实现，以及我实际开发中踩过的坑和总结的排查方法，尽量完整地写出来。文章面向两类人：一是正在做相关课设或毕设的同学，二是确实想给自己门店或朋友门店搭一套简单管理工具、又不想用复杂商业软件的从业者。你不需要有多高深的技术底子，只要跟着把每一层逻辑捋明白，这套系统完全可以自己复现出来。

1. 项目整体设计与技术选型思路

1.1 为什么选择Python和Django这对组合

先聊技术选型。汽车维修保养管理系统，本质就是一个以“客户—车辆—工单—配件”为核心的数据管理系统。它的业务特征很清晰：数据实体多但关系稳定、流程固定但涉及状态流转、管理端功能重而用户端相对简单。这类系统用Python做后端开发非常顺手，因为Python的数据结构、类机制和动态特性，让复杂的业务模型能很自然地转化为代码。

Django在其中的角色更关键。它自带ORM、Admin后台、认证体系和模板引擎，这几个模块正好打在了管理系统的痛点上。ORM省去了大量手写SQL的重复劳动，比如维修工单要关联客户、车辆、技师、配件多张表，Django里一个外键字段加一次查询就能拿到全部关联数据；Admin后台在开发阶段几乎是免费的福利，直接把数据模型的增删改查界面生成出来，调试数据和演示功能都非常方便。

我见过有人非要用Flask甚至原生Python写这类系统，不是说不行，但工作量至少多一倍，而且在表单校验、用户权限、数据库迁移这些环节，你都要自己想办法。Django帮你在底层做完了，你只需要专注业务本身。

1.2 核心需求拆解：从修车场景推导系统模块

任何一个管理系统，第一步都不是写代码，而是把业务流程掰开揉碎。我当时花了两个晚上泡在熟人的维修厂里，盯着他们接车、开单、派工、领料、结算的全过程，才最终理清了系统需要覆盖的角色和状态。

门店里的真实角色有四个：前台接待、车间主管/技师、库管、老板。每个角色看系统的角度完全不同。前台要快速查到老客户的车牌和上次维修记录，开单快；技师要看到派给自己的活和需要的配件明细；库管要清楚每个配件当下库存多少、要不要补货；老板要看到这个月做了多少单、产值多少、哪些项目最赚钱。

对应的系统模块就清晰了：

• 客户管理：记录客户基本信息，关联名下车辆
• 车辆管理：车牌、车型、VIN码、当前里程，一辆车归属一个客户
• 维修工单管理：从接车到完工的主线流程，包含故障描述、检查项、维修项、工时费、完成状态
• 保养管理：保养计划提醒、保养记录查询，按里程或时间触发
• 配件管理：配件库、出入库明细、库存预警
• 员工管理与权限：前台、技师、库管、管理员不同角色看到不同界面
• 统计报表：工单产值、配件消耗、客户到店频次

在立项阶段，你要学会对功能做减法。很多初学者一上来就想着做会员卡余额、微信推送、在线预约，结果系统越做越臃肿，最后的成品却连最基础的工单闭环都没跑通。先把上面七条做到、做完善，这个系统已经能撑起一个真实的门店日常运转了，后续再迭代也不迟。

1.3 Django项目结构拆解

基于上面提到的高内聚低耦合原则，我把Django项目拆成了一个个独立的app。实际项目中，我按照功能边界划分成五个app，每个app只专注一类业务：

text复制car_repair/
├── manage.py
├── config/              # 项目配置
├── apps/
│   ├── customers/       # 客户与车辆管理
│   ├── workorders/      # 维修工单与保养
│   ├── parts/           # 配件库存
│   ├── employees/       # 员工与权限
│   └── dashboard/       # 统计报表

这种结构的维护体验非常好。比如客户模块调整了字段，不会影响到工单模块的代码；工单模块要增加一个状态，也不需要在客户代码里改任何东西。每个app内部的models、views、urls、admin都是独立的，各管各的。

2. 数据库模型设计：把业务关系落地为表结构

2.1 核心表结构规划

数据库设计是整个系统最见功力的环节，表结构设计得合理，后续写逻辑会非常顺；设计得不好，写查询语句的时候你就会不停地想骂人。我按业务主线拆出五组核心表：客户、车辆、工单、配件、员工。

客户表和车辆表是一对多的关系，一个客户可以有多辆车，车牌号是车辆表的唯一标识。工单表是整个系统的串联核心，它同时关联车辆、客户、接车员工、维修技师、保养类型等多个外键。配件表里维护的是配件的基础信息，库存量实时更新，同时通过出入库记录表追踪每一笔变动。员工表除了基本信息之外，还通过Django的Group和Permission机制控制每个角色能访问的模块。

下面是我实际建表时精简后的核心字段结构，贴合“维修保养”这个具体场景：

python复制from django.db import models

class Customer(models.Model):
    name = models.CharField(max_length=50, verbose_name="客户姓名")
    phone = models.CharField(max_length=20, unique=True, verbose_name="联系电话")
    address = models.CharField(max_length=200, blank=True, verbose_name="联系地址")
    created_at = models.DateTimeField(auto_now_add=True, verbose_name="创建时间")

class Vehicle(models.Model):
    customer = models.ForeignKey(Customer, on_delete=models.CASCADE, verbose_name="所属客户")
    plate_number = models.CharField(max_length=10, unique=True, verbose_name="车牌号")
    brand = models.CharField(max_length=30, verbose_name="车辆品牌")
    model_name = models.CharField(max_length=50, verbose_name="车型")
    vin = models.CharField(max_length=17, blank=True, verbose_name="车架号")
    current_mileage = models.IntegerField(default=0, verbose_name="当前里程(km)")
    buy_date = models.DateField(null=True, blank=True, verbose_name="购买日期")

class WorkOrder(models.Model):
    STATUS_CHOICES = [
        ('pending', '待接车'),
        ('inspecting', '检测中'),
        ('repairing', '维修中'),
        ('quality_check', '待质检'),
        ('completed', '已完工'),
        ('delivered', '已交车'),
    ]
    order_no = models.CharField(max_length=20, unique=True, verbose_name="工单号")
    vehicle = models.ForeignKey(Vehicle, on_delete=models.PROTECT, verbose_name="车辆")
    customer = models.ForeignKey(Customer, on_delete=models.PROTECT, verbose_name="客户")
    status = models.CharField(max_length=20, choices=STATUS_CHOICES, default='pending', verbose_name="工单状态")
    description = models.TextField(verbose_name="故障描述")
    inspector = models.ForeignKey('employees.Employee', on_delete=models.SET_NULL, null=True, related_name='inspected_orders', verbose_name="接车员")
    assigned_tech = models.ForeignKey('employees.Employee', on_delete=models.SET_NULL, null=True, related_name='assigned_orders', verbose_name="维修技师")
    labor_fee = models.DecimalField(max_digits=10, decimal_places=2, default=0, verbose_name="工时费")
    total_amount = models.DecimalField(max_digits=10, decimal_places=2, default=0, verbose_name="总金额")
    created_at = models.DateTimeField(auto_now_add=True, verbose_name="创建时间")

工单状态我用了单字段加choices的实现方式，状态流转通过业务代码控制。没有用workflow库，因为这个流程相对线性，六个状态足够覆盖门店日常。你如果真想引入复杂的自动化状态机，反而会把自己绕进去，徒增维护成本。

配件和工单之间是多对多关系，一份工单可以领用多种配件，一个配件也会被多份工单使用。中间表我额外加上了数量和单价字段，这样领料明细一目了然：

python复制class Part(models.Model):
    name = models.CharField(max_length=100, verbose_name="配件名称")
    part_no = models.CharField(max_length=50, unique=True, verbose_name="配件编号")
    stock = models.IntegerField(default=0, verbose_name="当前库存")
    safe_stock = models.IntegerField(default=5, verbose_name="安全库存下限")
    price = models.DecimalField(max_digits=10, decimal_places=2, verbose_name="销售单价")
    cost_price = models.DecimalField(max_digits=10, decimal_places=2, verbose_name="进货成本")

class WorkOrderPart(models.Model):
    work_order = models.ForeignKey(WorkOrder, on_delete=models.CASCADE, verbose_name="工单")
    part = models.ForeignKey(Part, on_delete=models.PROTECT, verbose_name="配件")
    quantity = models.IntegerField(default=1, verbose_name="数量")
    unit_price = models.DecimalField(max_digits=10, decimal_places=2, verbose_name="销售单价")

2.2 保养提醒的数据基础

保养模块不必单独建一堆表，核心是复用车辆和工单数据。每辆车有两个关键维度：当前里程和上次保养的里程/时间。系统只需要在保养记录表里维护每次保养时的里程数、保养时间、保养项目，判断逻辑就可以很简单：当前里程减去上次保养里程，或者当前日期减去上次保养日期，任一达到设定阈值就触发提醒。

保养记录表设计如下：

python复制class MaintenanceRecord(models.Model):
    vehicle = models.ForeignKey(Vehicle, on_delete=models.CASCADE, verbose_name="车辆")
    work_order = models.OneToOneField(WorkOrder, on_delete=models.SET_NULL, null=True, blank=True, verbose_name="关联工单")
    service_date = models.DateField(auto_now_add=True, verbose_name="保养日期")
    service_mileage = models.IntegerField(verbose_name="保养时里程(km)")
    maintenance_type = models.CharField(max_length=30, choices=[('oil', '常规保养'), ('full', '大保养'), ('brake', '刹车保养')], verbose_name="保养类型")
    cost = models.DecimalField(max_digits=10, decimal_places=2, verbose_name="保养费用")
    content = models.TextField(verbose_name="保养内容")

2.3 常见建模误区和我的处理方式

模型设计阶段最容易犯的错，是外键关联用错on_delete参数。比如车辆被删除时，它名下的工单应该怎么处理？工单是财务和业务凭证，绝不能跟着车辆一起级联删除。所以工单关联车辆和客户时，我用了PROTECT，被引用的车辆或客户有工单关联时就不允许删除，最多标记为禁用。但工单关联接车员和技师时，员工离职后工单还需要保留，所以用SET_NULL，员工记录删掉后工单仍存在，只是技师字段留空。

另一个经验是车牌号一定要加unique约束。真实场景里车牌就是一辆车最自然的身份标识，如果不做唯一约束，同一个车牌被录两次，后面查历史工单时数据就乱了。VIN码也建议做唯一约束，但考虑有些车主确实说不清自己的车架号，我把它留成了可空字段。

3. 核心业务模块的开发实现

3.1 用户认证与权限设计

Django自带的认证系统已经覆盖了用户登录、会话管理、密码加密这些基础设施。但管理系统的权限粒度需要自己设计，我采用的是“角色组+视图权限”两层结构。

第一层是基础认证，登录页用Django的LoginView实现，要求未登录用户跳转到登录页，登录成功后按角色跳转到对应首页。第二层是角色组权限，我创建了四个组：admin、front_desk、technician、warehouser。每个组对应的权限表如下：

实现上，我自定义了一个中间件，在每个请求进入视图前判断当前用户属于哪个组、访问的URL前缀是否在允许列表中。这样做的好处是权限逻辑集中管理，新增模块时只需在中间件配置里加一行，不用每个视图都写装饰器。核心代码如下：

python复制class RolePermissionMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        if not request.user.is_authenticated:
            return redirect('login')

        allowed_paths = {
            'admin': ['/dashboard/', '/customers/', '/workorders/', '/parts/', '/employees/'],
            'front_desk': ['/dashboard/', '/customers/', '/workorders/', '/maintenance/'],
            'technician': ['/workorders/', '/maintenance/'],
            'warehouser': ['/parts/',],
        }

        user_groups = request.user.groups.values_list('name', flat=True)
        current_path = request.path
        allowed = any(
            current_path.startswith(prefix)
            for group in user_groups
            for prefix in allowed_paths.get(group, [])
        )

        if not allowed and not current_path.startswith('/admin/'):
            return render(request, '403.html', status=403)

        return self.get_response(request)

3.2 维修工单全流程闭环实现

工单是整个系统的主线，它的流程设计直接决定业务跑不跑得顺。我实现的工单状态流转逻辑如图解：

• 待接车：前台录入客户、车辆、故障描述，生成工单号
• 检测中：技师接单，补充检测结果和维修方案
• 维修中：领用配件，工时和配件费用累加
• 待质检：维修完成，等待质检确认
• 已完工：质检通过，准备交付
• 已交车：客户结算，完成闭环

每个状态的跳转都封装在WorkOrder模型的方法里，不允许视图层直接修改status字段。这样做的目的是把状态校验收拢到模型层，避免出现从“待接车”直接跳到“已完工”这种脏数据。

工单号的生成也值得说一句。直接用数据库自增id当工单号暴露给客户，会泄露门店的接单量，而且位数太短易猜。我用“WO + 年月日 + 当日序号”的格式，例如WO20250115001。生成逻辑是当天首单取001，之后每单自增，用Django的F表达式加事务锁保证并发下不重号：

python复制from django.db import transaction
from django.db.models import F

def generate_order_no(self):
    today_str = datetime.now().strftime('%Y%m%d')
    prefix = f'WO{today_str}'
    with transaction.atomic():
        # 用select_for_update锁定行，避免并发重复
        last_order = WorkOrder.objects.select_for_update().filter(
            order_no__startswith=prefix
        ).order_by('-order_no').first()

        if last_order:
            last_seq = int(last_order.order_no[-3:])
            new_seq = last_seq + 1
        else:
            new_seq = 1

        return f'{prefix}{new_seq:03d}'

费用计算没有放在保存时实时算出总数，而是在每次添加配件或修改工时费时调用recalculate_total方法。这个方法遍历工单关联的所有配件明细和工时费，汇总写入total_amount字段。这样结算页面直接读字段即可，不需要每次都联表聚合查询，性能更好。

3.3 保养提醒功能：用Django命令替代定时任务

保养提醒的实现逻辑不难，难在怎么在对应时间把数据推出来。我选择用Django的自定义management command，配合cron定时执行，而不是引入Celery。理由很简单：保养提醒不是高频任务，一天跑一次足够，Celery的引入会带来额外的消息队列运维负担，对这个量级的项目完全没必要。

我的实现思路是编写一个check_maintenance_due命令，每次运行时扫描所有车辆，计算哪些车需要保养。判断规则设计成双阈值触发：当当前里程距上次保养里程超过5000公里，或距上次保养时间超过3个月，系统就生成一条待办提醒。同时用flag字段记录提醒是否已发送，避免重复提醒。

具体命令代码如下：

python复制from django.core.management.base import BaseCommand
from datetime import timedelta
from django.utils import timezone

class Command(BaseCommand):
    help = '扫描所有车辆，生成到期待保养提醒'

    def handle(self, *args, **options):
        from customers.models import Vehicle
        from workorders.models import MaintenanceReminder

        today = timezone.now().date()
        remind_vehicles = []

        for vehicle in Vehicle.objects.all():
            # 取该车最近一条保养记录
            last_record = vehicle.maintenance_records.order_by('-service_date').first()
            if not last_record:
                # 从未保养过，按购车日期计算
                if vehicle.buy_date:
                    months_gap = (today - vehicle.buy_date).days / 30
                    if months_gap >= 3:
                        remind_vehicles.append(vehicle)
                continue

            mileage_gap = vehicle.current_mileage - last_record.service_mileage
            time_gap = (today - last_record.service_date).days

            if mileage_gap >= 5000 or time_gap >= 90:
                remind_vehicles.append(vehicle)

        for vehicle in remind_vehicles:
            # 使用get_or_create避免重复提醒
            reminder, created = MaintenanceReminder.objects.get_or_create(
                vehicle=vehicle,
                is_handled=False,
                defaults={'remind_reason': f'距上次保养已行驶超5000公里或间隔超3个月'}
            )
            if created:
                self.stdout.write(f'已将车辆 {vehicle.plate_number} 加入保养待办')

部署时只要在服务器上配置一个定时任务，每天上午9点执行一次这个命令，有到期车辆就会自动生成提醒视图的数据源，前台打开系统就能看到“今日待保养车辆”列表。无需额外常驻进程，稳定可靠。

3.4 配件库存的出入库与低库存预警

配件模块管两件事：出入库记录和库存预警。采购入库时增加库存，工单领料时减少库存，这两类操作都必须写操作日志，以便追溯某一天的配件流向。

入库操作我用一个统一的StockIn记录表，字段包括配件、入库数量、入库单价、供应商、操作人、时间。工单领料则是在保存WorkOrderPart的同时执行库存扣减，两件事放在同一个事务里，避免工单保存成功但库存没扣减的不一致问题：

python复制from django.db import transaction

def add_part_to_workorder(work_order, part, quantity):
    with transaction.atomic():
        if part.stock < quantity:
            raise ValueError(f'配件 {part.name} 库存不足，当前剩余 {part.stock}')

        # 创建工单配件明细
        WorkOrderPart.objects.create(
            work_order=work_order,
            part=part,
            quantity=quantity,
            unit_price=part.price
        )

        # 扣减库存
        part.stock = F('stock') - quantity
        part.save(update_fields=['stock'])

        # 重新计算工单总费用
        work_order.recalculate_total()

这里有个细节：库存扣减用了F表达式而非先取后减。原因是并发场景下，两个工单同时领同一个配件，如果各自先取当前库存再减去quantity后存回，可能出现超卖。F表达式是数据库层面的原子操作，更新时直接执行“库存减quantity”，不会出现并发覆盖问题。

低库存预警更简单，每次登录系统后，dashboard首页执行一次聚合查询，筛选stock小于等于safe_stock的配件，列表展示提示补货。我建议阈值不要设死，每个配件单独维护safe_stock字段，常用机油、机滤这类消耗品阈值高一些，冷门配件阈值低一些，这样预警更有针对性。

4. 前端页面与交互设计要点

4.1 用模板继承搭建管理后台框架

Django的模板系统配合Bootstrap，就能做出一套干净整洁的管理后台，不需要额外引入Vue或React。我用的是Django模板继承的方式，做一个base.html作为公共骨架，左侧为导航栏，右侧为内容区，每个功能页面只需继承base并覆盖content块。

html复制{% load static %}
<!DOCTYPE html>
<html lang="zh-cn">
<head>
    <meta charset="UTF-8">
    <title>{% block title %}汽车维修保养管理系统{% endblock %}</title>
    <link href="{% static 'bootstrap/css/bootstrap.min.css' %}" rel="stylesheet">
</head>
<body>
    <div class="container-fluid">
        <div class="row">
            <div class="col-md-2" style="min-height: 100vh; background-color: #212529;">
                {% include 'sidebar.html' %}
            </div>
            <div class="col-md-10 p-4">
                {% block content %}
                {% endblock %}
            </div>
        </div>
    </div>
    {% block extra_js %}{% endblock %}
</body>
</html>

这样设计的核心好处是页面风格统一、维护成本低。如果以后要调整导航结构，只改sidebar.html一个文件就能全站生效。后台系统的前端不该追求花哨，信息清晰、操作路径短才是第一优先。

4.2 关键页面的数据展示与搜索优化

维修工单列表是最常被使用的页面，技师和前台每天打开无数次。我做了三个优化：

第一个是默认只显示当天的工单，避免每日打开系统时拉取全量历史数据，数据量大了之后分页拖慢响应。要查历史记录，可以通过日期筛选或多条件搜索。

第二个是关键字搜索覆盖车牌、客户名、工单号三个字段。Django的Q对象一次搞定，不用写原生SQL：

python复制from django.db.models import Q

keyword = request.GET.get('keyword', '')
if keyword:
    order_list = order_list.filter(
        Q(order_no__icontains=keyword) |
        Q(vehicle__plate_number__icontains=keyword) |
        Q(customer__name__icontains=keyword)
    )

第三个是列表页的状态高亮。用不同颜色的badge区分工单状态，待接车是灰色、维修中是蓝色、已完工是绿色、已交车是深灰，扫一眼就知道当前进度，不用逐行看文字。这种前端细节对日常使用体验的提升非常明显。

4.3 表单校验与用户友好提示

Django的Form和ModelForm自带校验能力，必须充分利用。我用ModelForm自动生成表单，并在Meta里指定fields，避免表单直接接受用户传过来的额外字段。在模板中渲染时，每个字段的errors都展示在对应控件下方，让操作者立刻明白哪里填错。

自定义校验规则的场景也不少。比如手机号格式，我用正则表达式校验11位且以1开头；车牌号校验，我写了一个宽松的正则，匹配常见的新能源绿牌和蓝牌格式。这些校验挂在ModelForm的clean_field_name方法里，不合法时抛出ValidationError并回填到表单：

python复制import re

def clean_phone(self):
    phone = self.cleaned_data['phone']
    if not re.match(r'^1[3-9]\d{9}$', phone):
        raise forms.ValidationError('请输入正确的手机号')
    return phone

def clean_plate_number(self):
    plate = self.cleaned_data['plate_number']
    if not re.match(r'^[京津沪渝冀豫云辽黑湘皖鲁新苏浙赣鄂桂甘晋蒙陕吉闽贵粤青藏川宁琼使领A-Z]{1}[A-Z]{1}[A-Z0-9]{4,5}$', plate):
        raise forms.ValidationError('请输入正确的车牌号')
    return plate

5. 性能优化与数据统计

5.1 避免N+1查询的关键操作

管理系统数据量在几千条级别时，几乎不会感觉到性能问题，但你的代码习惯决定了两三年后数据涨到几十万条时系统还能不能扛得住。

Django ORM最容易出现的问题是N+1查询。比如循环遍历工单列表，每取一条工单的客户姓名，都要发一次查询客户表的SQL，一百条工单就是一百零一条查询，速度指数级下滑。

解决办法是select_related和prefetch_related。对一对一、多对一关系（工单查客户、车辆、员工），用select_related，通过SQL层join一次性取回；对多对多、反向关联（工单查配件明细），用prefetch_related，先查主表再批量查关联表，在Python内存中组装：

python复制order_list = WorkOrder.objects.select_related(
    'vehicle', 'customer', 'inspector', 'assigned_tech'
).prefetch_related(
    'workorderpart_set__part'
).filter(status__in=['inspecting', 'repairing'])

当时我写这段代码前，列表页接口响应耗时大约1.2秒，加了select_related之后直接降到200毫秒以内。这个优化在业务量不大时看不出来，但对培养性能意识非常重要。

5.2 Dashboard统计报表实现

统计报表是老板每天打开系统第一眼要看的东西。我用了一个独立的dashboard页面，聚合展示当日新增工单数、当日营业收入、当月产值趋势、库存预警数量这些关键指标。

Django的ORM聚合函数用起来很顺手。当日营收直接对完成状态的工单做Sum：

python复制from django.db.models import Sum

today_orders = WorkOrder.objects.filter(
    status__in=['completed', 'delivered'],
    created_at__date=date.today()
)

today_revenue = today_orders.aggregate(
    total=Sum('total_amount')
)['total'] or 0

当月产值趋势需要生成一个最近30天的数据序列。我在视图里循环日期范围，每天做一次聚合，数据量不大时这种循环完全没问题。如果想更高效，可以用MySQL的DATE_FORMAT函数按天分组，一条SQL搞定所有天的统计，但可读性会差一些。我更推荐上面这种清晰直观的做法，毕竟管理系统的日数据量远没到需要极致优化SQL的程度。

另外我加了简单的图表展示，用的是ECharts的CDN。模板中把趋势数据以JSON格式传给JavaScript，渲染成折线图。纯前端图表库好处是零后端依赖，数据格式自己控制，不会有大问题。

6. 部署上线与常见问题排查

6.1 部署方案：宝塔面板+Nginx+Gunicorn

项目能在本地跑通只是第一步，交付给客户使用必须部署到正式服务器上。我多次使用宝塔面板+Python项目管理器的方式进行部署，全程不需要长时间操作终端，而且简化了Nginx配置和证书申请。

部署流程总结如下：

1. 服务器安装宝塔面板，在软件商店安装Python项目管理器
2. 创建Python项目，Python版本选3.10或3.11，上传项目代码
3. 安装依赖，通过pip install -r requirements.txt完成
4. 配置Gunicorn启动命令，监听127.0.0.1:8000
5. 在Nginx反向代理配置中，将域名指向127.0.0.1:8000
6. 收集静态文件，运行python manage.py collectstatic
7. 设置MySQL数据库并导入初始表结构，执行python manage.py migrate

部署时最容易漏掉的坑是静态文件服务。Django默认不开启DEBUG时不会主动提供静态文件服务，需要在settings里配置STATIC_ROOT，然后在Nginx里加一条location规则指向它。我见过太多项目在服务器上一跑起来页面全裸奔的案例，基本就是这一步没做对。

6.2 日志配置与定位线上问题

线上和本地是两个完全不同的环境，问题排查必须依赖日志。我在settings里配置了文件日志，按时间每天滚动，日志级别设为INFO，记录请求错误、SQL慢查询、自定义业务异常。线上报错时，先看日志能定位80%的问题：

python复制LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'formatters': {
        'verbose': {
            'format': '{levelname} {asctime} {module} {message}',
            'style': '{',
        },
    },
    'handlers': {
        'file': {
            'level': 'INFO',
            'class': 'logging.handlers.TimedRotatingFileHandler',
            'filename': os.path.join(BASE_DIR, 'logs', 'app.log'),
            'when': 'midnight',
            'backupCount': 7,
            'formatter': 'verbose',
        },
    },
    'loggers': {
        'django': {
            'handlers': ['file'],
            'level': 'INFO',
        },
        'workorders': {
            'handlers': ['file'],
            'level': 'INFO',
        },
    },
}

在那些容易出错的关键操作里（工单创建、库存扣减、费用计算），我用logger.info记录执行过程。这样一旦数据对不上，回看日志就能知道是哪一步出了问题，哪台机器在哪个时间点做了什么操作。

6.3 数据备份策略

管理系统最怕的是数据丢失。我接入项目的第一天就会和客户敲定备份方案：MySQL每天凌晨自动导出到服务器磁盘，保留最近30天，再使用远程备份工具同步到云存储。这个动作看似简单，但往往是门店管理人员最容易忽视的一环。

宝塔面板提供了定时备份数据库的功能，直接配置即可。我自己写了一个shell脚本配合cron执行，逻辑是先导出当天数据，再用时间戳命名文件名，最后只保留最近一个月的备份文件。脚本核心部分如下：

bash复制#!/bin/bash
BK_DIR=/data/backup/mysql
DATE=$(date +%Y%m%d)
DB_NAME=car_repair

mysqldump -u root -p'密码' $DB_NAME > $BK_DIR/${DB_NAME}_${DATE}.sql
find $BK_DIR -name "*.sql" -mtime +30 -delete

6.4 高频问题排查速查表

基于我带过的项目和社区反馈，我把新手最容易遇到的几个问题整理成了速查表，遇到对应报错直接按方案处理：

7. 项目复盘与可扩展方向

系统跑起来之后，我建议你做一次完整的功能走查，以“新员工第一天用这套系统”的视角走一遍所有流程。这一步非常有用，你会发现很多自己写代码时根本注意不到的问题，比如某个按钮放在不合理的位置、某个下拉框选项顺序不符合操作习惯、某个弹窗文案让用户误解了下一步操作。

如果项目还有进一步提升空间，我想到三个值得做的扩展方向。

第一个是微信小程序端。门店老板和技师大多时候不在电脑前，小程序的“今日待办”和“工单进度”页面就非常有用。后端只需要提供一套JSON接口，复用现有的业务逻辑，前端用小程序框架开发，整体工作量可控。

第二个是会员管理和消费记录，如果这个需求存在。可以结合车辆保养记录，给客户推送保养到期提醒。Django的模板邮件或短信接口都能实现，难点在于短信服务需要申请签名和模板，有一定门槛，但技术上并不复杂。

第三个是进销存全面化。目前的配件模块相当于基础进销存，如果门店同时做销售业务，可以给配品增加销售单、供应商对账、采购计划等功能，让整个供应链管理闭环。

我个人在实际操作中最深的一点体会是：这个系统的技术难点不在某个技术点本身，而在如何把一段真实业务场景转化为稳定的数据流程。Django给了你非常好的底层工具，但你得自己去思考工单状态该怎么流转、库存什么时候扣减、提醒条件怎么判定。把这些业务逻辑想明白了，系统自然就立得住。

最后再分享一个小技巧：开发期间记得开启Django的DEBUG=True，配合django-debug-toolbar这个工具，你能直观看到每个页面执行了多少条SQL、耗时多少、哪个操作可以优化。这套组合拳打下来，你在学校或者门店交付的就不再只是“能跑的项目”，而是真正好用、能长期维护的系统。