简介这是一套基于Django的4S店客户管理系统项目源码面向Python/Django/Vue学习者及需要完成毕业设计、课程设计或工程实训的学生。系统覆盖售后申请、审核、查询、安排、处理等完整环节区分用户、管理员、员工三类角色分别实现售后与车辆信息添加、订单/用户/售后安排管理、售后处理与查询等功能具备清晰的业务闭环。压缩包共370个文件以Vue前端组件、Python后端源码、SVG/JPG/PNG等静态资源为主另含SQL数据库脚本、依赖清单及安装/运行bat脚本整体容量约11.47MB结构规整便于快速部署和二次开发。当前已有1819人学习/下载适合作为Web全栈实战参考。内含可直接运行的源码、数据库文件和文档结合配置文件备份、前端页面组件等素材可辅助理解Django与Vue前后端交互逻辑、数据库表结构设计以及项目打包运行流程为独立开发类似管理系统提供有价值的参考。1. Django 做 4S 店客户管理到底在管理什么一个 4S 店的日常不是卖车那一下子而是销售顾问整天围着客户转线上留资的、进店看车的、试驾完犹豫的、谈好价格又反悔的每一条线索都得有人跟进、有记录、有下一步动作。传统做法是记在 Excel 和微信聊天记录里客户一多就乱哪个销售跟的单、客户卡在哪个环节、这个月成交率是多少全凭一张嘴。这套基于 Django 的 4S 店客户管理系统就是把“潜客→跟进→试驾→成交→售后”这条链路由表格变成一套可查询、可统计的数据闭环。后端用 Django 做接口和业务逻辑前端用 Vue 做操作页面既覆盖了毕设要求的 Python 后端功力又能演示前后端分离的项目结构。适合两类人一是正在做毕业设计的 Python 方向学生想找一个能跑通完整流程的实战源码二是刚入行做业务系统的开发想看看 Django 的多模块项目里用户、客户、跟进、订单之间是怎么解耦又怎么关联的。2. 项目骨架怎么拆Django 模块划分与三个必坑的配置项2.1 为什么选 Django Vue而不是纯 Django 模板4S 店客户管理系统的核心操作其实很常规新增客户、改状态、记跟进、查订单、看统计。这类系统用 Django 自带的模板系统也能做admin 后台甚至可以免费送你一套管理界面但有两个问题一是模板页面做不出销售看板那种交互效果二是答辩时考官盯着问“前后端怎么分离的”如果你回答“模板渲染的”技术亮点直接少一半。所以这个项目把 Django 当成纯后端 API 来用前端用 Vue 单独维护。Django 负责三件事数据建模、RESTful 接口、权限校验Vue 负责展示和交互。拆开的代价是你得同时维护两套代码、处理跨域、管理 token一个人做毕设容易顾此失彼。我的建议是Vue 只写登录页、客户列表页、跟进记录页、统计看板这四个核心页面其余数据维护类的功能全部交给 Django admin。admin 不是摆设它是你批量录入测试数据的利器也是答辩时展示“Django 自带后台”的加分项。2.2 建项目与创建 app我把哪些模块拆成了独立 app初始化项目时我习惯把配置目录命名为 config业务代码全部收敛到一个 apps 包下这样根目录不至于散落一堆 app 文件夹。下面是创建命令# 1. 创建 Django 项目配置目录叫 config django-admin startproject config . # 2. 创建独立的业务 app按业务边界拆分 python manage.py startapp apps/user python manage.py startapp apps/customer python manage.py startapp apps/followup python manage.py startapp apps/order python manage.py startapp apps/dashboard这里说明一下拆分的逻辑。apps/user 负责登录认证和员工账号虽然没有写太多业务字段但它是 JWT 鉴权的基础apps/customer 是客户主表包括基本信息和当前销售状态apps/followup 记录每一次跟进动作比如电话、微信、试驾、到店apps/order 存放成交订单金额、付款状态、交车日期都在这里apps/dashboard 不做数据存储只负责聚合统计接口比如按周统计成交量、按来源统计线索量。拆成五个 app 不是炫技而是为了让你在答辩时能讲清楚“高内聚、低耦合”这句话每个 app 都有自己的 models、views、serializers改订单逻辑不会动到客户逻辑。需要注意一个细节startapp 的路径写法直接传 apps/user 是可行的Django 会以 apps 作为父包。但创建完成后你需要在 apps 目录下放一个空的init.py同时把 config/settings.py 里的 INSTALLED_APPS 写成带完整路径的应用名比如 apps.customer而不是 customer。2.3 settings 配置的经验值数据库、时区、静态文件与跨域settings.py 是整个项目最容易翻车的地方。很多毕设源码下载下来跑不起来一半问题都出在配置漏项或者配置冲突上。我这里给一份经过验证的配置骨架# config/settings.py from pathlib import Path BASE_DIR Path(__file__).resolve().parent.parent INSTALLED_APPS [ django.contrib.admin, django.contrib.auth, django.contrib.contenttypes, django.contrib.sessions, django.contrib.messages, django.contrib.staticfiles, rest_framework, corsheaders, apps.user, apps.customer, apps.followup, apps.order, apps.dashboard, ] MIDDLEWARE [ django.middleware.security.SecurityMiddleware, django.contrib.sessions.middleware.SessionMiddleware, corsheaders.middleware.CorsMiddleware, # CORS 中间件必须放在 CommonMiddleware 之前 django.middleware.common.CommonMiddleware, django.middleware.csrf.CsrfViewMiddleware, django.contrib.auth.middleware.AuthenticationMiddleware, django.contrib.messages.middleware.MessageMiddleware, django.middleware.clickjacking.XFrameOptionsMiddleware, ] TIME_ZONE Asia/Shanghai USE_TZ True DATABASES { default: { ENGINE: django.db.backends.mysql, NAME: car4s, USER: root, PASSWORD: your_password, HOST: 127.0.0.1, PORT: 3306, OPTIONS: {charset: utf8mb4}, } } CORS_ALLOWED_ORIGINS [ http://localhost:5173, http://127.0.0.1:5173, ] REST_FRAMEWORK { DEFAULT_PAGINATION_CLASS: rest_framework.pagination.PageNumberPagination, PAGE_SIZE: 10, DEFAULT_AUTHENTICATION_CLASSES: ( rest_framework_simplejwt.authentication.JWTAuthentication, ), }逐条说几个关键参数。TIME_ZONE 配成 Asia/Shanghai 只是第一步USE_TZ 保持 TrueDjango 在数据库里存的一律是 UTC 时间输出到前端时才转成上海时间这个机制后面会专门说坑。DATABASES 我建议直接用 MySQL不要用 SQLite 凑合因为毕设答辩现场很可能要求你换电脑演示MySQL 的库可以通过 dump 文件迁移SQLite 的库文件一换环境就各种路径报错。CORS_ALLOWED_ORIGINS 只允许 Vue 开发服务器的两个地址别图省事写成 CORS_ALLOW_ALL_ORIGINSTrue答辩时考官问“跨域怎么处理的”你能说清楚具体允许了哪些源比一句“我全放开了”体面得多。3. 数据库建模与 ORM 查询客户、跟进、订单三张核心表的关联3.1 客户表Customer字段设计与选择理由客户是这套系统的数据核心所有功能都围绕它展开。建模的时候不要一味堆字段而是要站在销售的业务视角想一条客户记录需要支撑哪些动作筛选高意向客户、按来源统计、跟进时看到客户预算和意向车型。下面是我在项目里实际使用的客户表模型# apps/customer/models.py from django.db import models class Customer(models.Model): 客户主表每个进过线的潜在客户占一行 STATUS_CHOICES [ (new, 新建线索), (intention, 高意向), (bargaining, 议价中), (deal, 已成交), (lose, 战败), ] SOURCE_CHOICES [ (online, 线上留资), (store, 进店), (referral, 转介绍), (old_customer, 老客户增购), ] name models.CharField(客户姓名, max_length32) phone models.CharField(手机号, max_length20, uniqueTrue) gender models.CharField(性别, max_length1, choices[(M, 男), (F, 女)], blankTrue, default) status models.CharField(当前状态, max_length16, choicesSTATUS_CHOICES, defaultnew, db_indexTrue) source models.CharField(线索来源, max_length16, choicesSOURCE_CHOICES, defaultonline, db_indexTrue) car_model models.CharField(意向车型, max_length64, blankTrue, default) budget models.DecimalField(预算范围, max_digits10, decimal_places2, nullTrue, blankTrue) note models.TextField(备注, blankTrue, default) created_at models.DateTimeField(创建时间, auto_now_addTrue) updated_at models.DateTimeField(更新时间, auto_nowTrue) class Meta: db_table customer ordering [-updated_at] def __str__(self): return f{self.name}({self.phone})字段选择上说明几个理由。phone 加 unique 约束是为了防止销售重复录入同一个手机号代码里再做一层 get_or_create 兜底比单纯靠人去判断靠谱得多。status 用 CharField 加 choices而不用 IntegerField因为可读性更好序列化输出时直接能用查询也直观比如 filter(statusintention)。budget 用 DecimalField 而不用 FloatField是因为价格计算不允许浮点误差这是一个很细节但答辩时能加分的点。created_at 用 auto_now_add 并且不允许手动改updated_at 用 auto_now每次保存自动刷新方便按更新时间排序。3.2 跟进记录FollowUp与订单Order的外键关系客户表只是线索池真正体现业务深度的是跟进记录。一个客户可以被销售跟进多次所以这是一对多关系而订单则是客户成交后的产物一个客户理论上可以下多台车的订单但业务上更常见的是一个客户对应一单。这两张表的外键设计直接决定删除行为和级联逻辑# apps/followup/models.py class FollowUp(models.Model): FOLLOW_TYPE [ (phone, 电话), (wechat, 微信), (test_drive, 试驾), (store, 到店), ] customer models.ForeignKey( customer.Customer, related_namefollowups, on_deletemodels.CASCADE, verbose_name关联客户, ) follow_type models.CharField(跟进方式, max_length16, choicesFOLLOW_TYPE, defaultphone) summary models.TextField(跟进内容, max_length500) next_time models.DateTimeField(下次跟进时间, nullTrue, blankTrue) created_at models.DateTimeField(跟进时间, auto_now_addTrue) class Meta: db_table followup ordering [-created_at]# apps/order/models.py class Order(models.Model): customer models.ForeignKey( customer.Customer, related_nameorders, on_deletemodels.PROTECT, # 订单保护客户不允许随便删 verbose_name成交客户, ) car_model models.CharField(成交车型, max_length64) order_amount models.DecimalField(成交金额, max_digits12, decimal_places2) pay_status models.CharField( 付款状态, max_length16, choices[(unpaid, 未付款), (partial, 部分付款), (paid, 已付款)], defaultunpaid, ) delivery_date models.DateField(交车日期, nullTrue, blankTrue) created_at models.DateTimeField(下单时间, auto_now_addTrue) class Meta: db_table order ordering [-created_at]这里最关键的是 on_delete 参数的选择。FollowUp 的 customer 外键用了 CASCADE意思是删除一条客户记录时这个客户的所有跟进记录自动删除这是合理的跟进记录是客户的附属数据客户都没了跟进记录留着没有业务意义。但 Order 的 customer 外键用了 PROTECT这是血泪经验换来的订单涉及成交金额、交车时间属于不能丢的业务凭证。如果订单外键也设成 CASCADE删除客户时会把订单连带删掉成交数据瞬间归零这在真实业务里是不可接受的。PROTECT 的效果是只要这个客户名下存在任意一张订单Django 就会抛 ProtectedError禁止删除客户必须先把订单处理掉。3.3 常用 ORM 查询与删除对象的正确姿势模型建好之后真正的业务逻辑都体现在查询上。这里列几个我在项目里反复用到的 ORM 片段它们覆盖了条件查询、分组统计、删除操作# 业务一销售顾问今天要跟进的高意向客户 from datetime import date from django.db.models import Count from apps.customer.models import Customer today_customers Customer.objects.filter( status__in[intention, bargaining], updated_at__datedate.today(), ).order_by(-updated_at) # 业务二按线索来源统计潜客数量用于前端看板 source_stats ( Customer.objects .values(source) .annotate(totalCount(id)) .order_by(-total) ) # 业务三清理 2025 年之前的战败客户连同跟进记录一起删 lose_customer Customer.objects.filter( statuslose, created_at__lt2025-01-01 ).first() if lose_customer: lose_customer.delete()关于删除对象这里有三个容易被忽略的点。第一QuerySet 是惰性的filter 执行后并没有真正发出 SQL只有遍历或者调用 .first()、.delete() 这些求值动作才会触达数据库所以上面第三个例子先调 .first() 再 delete()是安全的写法。第二customer.delete() 会触发 CASCADE 级联删除把 followups 一并清掉但因为 Order 外键是 PROTECT如果客户名下有订单这一行会直接抛异常你在代码里需要捕获 ProtectedError 然后提示“请先处理该客户的订单”。第三SQLite 下删除记录后自增 id 不会回退新增客户会接着用被删掉的最大 id 加一这是正常现象不要以为是 bug。如果想让 id 连续只能在迁移数据时重建表毕设里没有必要。4. 登录鉴权与 Vue 联调从 JWT 到客户列表分页接口4.1 基于 JWT 的登录流程与 token 存储前后端分离之后Django 自带的 session 认证就不能直接用了因为前端不是浏览器渲染的模板session 的 cookie 机制跨域之后非常别扭。这个项目用的是 JWT具体实现是 rest_framework_simplejwt 这个库它提供了现成的登录接口省去手写 token 签发逻辑。路由配置如下# config/urls.py from django.contrib import admin from django.urls import path, include from rest_framework_simplejwt.views import TokenObtainPairView, TokenRefreshView urlpatterns [ path(admin/, admin.site.urls), path(api/auth/login/, TokenObtainPairView.as_view(), nametoken_obtain_pair), path(api/auth/refresh/, TokenRefreshView.as_view(), nametoken_refresh), path(api/customers/, include(apps.customer.urls)), ]默认的 TokenObtainPairView 接收 username 和 password返回两个 tokenaccess 是短期令牌默认 5 分钟过期refresh 是用来换新 access 的长期令牌。前端拿到 access 后每次请求在 Authorization 头带上 Bearer token后端通过 JWTAuthentication 校验身份。access token 的过期时间在 settings.py 的 SIMPLE_JWT 配置里可以调我一般把 ACCESS_TOKEN_LIFETIME 改成 60 分钟避免演示到一半突然 401。token 存哪里是个值得纠结的问题localStorage 最简单刷新页面不丢但存在 XSS 风险sessionStorage 关标签页就丢内存变量一刷新就没。毕设场景建议用 localStorage你可以把 XSS 风险作为答辩时的“后续优化方向”说出来而不是踩这个坑。4.2 客户列表页的接口设计与分页参数客户列表页是 Vue 端最核心的页面需要支持分页、按状态筛选、按手机号搜索。Django REST framework 的 ViewSet 能快速生成标准接口配合分页类自动返回页码结构。先看序列化器# apps/customer/serializers.py from rest_framework import serializers from .models import Customer class CustomerSerializer(serializers.ModelSerializer): status_display serializers.CharField(sourceget_status_display, read_onlyTrue) class Meta: model Customer fields [id, name, phone, gender, status, status_display, source, car_model, created_at, followup_count]注意这里我没有直接在序列化器里写 followup_count serializers.IntegerField(sourcefollowups.count)虽然这样能返回跟进次数但它会在每个客户上额外执行一次 count SQL分页返回 10 条就多 10 条查询是典型的 N1 问题。正确的做法是在 ViewSet 里用 annotate 提前聚合# apps/customer/views.py from rest_framework import viewsets from rest_framework.permissions import IsAuthenticated from django.db.models import Count from .models import Customer from .serializers import CustomerSerializer class CustomerViewSet(viewsets.ModelViewSet): queryset Customer.objects.annotate( followup_countCount(followups) ).order_by(-updated_at) serializer_class CustomerSerializer permission_classes [IsAuthenticated] def get_queryset(self): qs super().get_queryset() status self.request.query_params.get(status) keyword self.request.query_params.get(keyword) if status: qs qs.filter(statusstatus) if keyword: qs qs.filter(phone__icontainskeyword) return qs这里有几个参数要说明。annotate(followup_countCount(followups)) 在数据库层面用 LEFT JOIN GROUP BY 把每个客户的跟进次数一次性算出来比序列化器里逐个 count 快一个量级。get_queryset 里的 keyword 参数用的是 icontains大小写不敏感手机号场景下可能用不上但合法。permission_classes [IsAuthenticated] 表示这个接口必须携带有效 token 才能访问如果你在浏览器里直接打开 /api/customers/ 看到的是 401 而不是 JSON不要慌这是预期行为。4.3 Vue 端 axios 封装与接口调用前端这边的关键不只是调用接口而是把 token 注入、401 跳转、错误提示这些横切逻辑收敛在一个文件里。我通常会封装一个 request.js// src/utils/request.js import axios from axios const request axios.create({ baseURL: http://127.0.0.1:8000/api, timeout: 10000 }) // 请求拦截器自动注入 JWT request.interceptors.request.use(config { const token localStorage.getItem(access_token) if (token) { config.headers.Authorization Bearer ${token} } return config }) // 响应拦截器统一处理 401 request.interceptors.response.use( response response, error { if (error.response?.status 401) { localStorage.removeItem(access_token) window.location.href /login } return Promise.reject(error) } ) export default request登录接口和客户列表接口的调用方式如下// src/api/customer.js import request from /utils/request export async function login(username, password) { const { data } await request.post(/auth/login/, { username, password }) localStorage.setItem(access_token, data.access) localStorage.setItem(refresh_token, data.refresh) return data } export function fetchCustomers(params) { return request.get(/customers/, { params }) }fetchCustomers 的 params 对象里可以传 page、page_size、status、keyword。DRF 的 PageNumberPagination 默认使用 page 参数指定页码page_size 需要额外设置如果你不传 page_size它就用 settings.py 里的 PAGE_SIZE10。前端翻页时把页码传给接口然后从 response.data 里取 count 和 resultscount 是符合条件的总条数results 才是当前页的客户数组。这里有个容易错的地方response.data 的结构是 { count, next, previous, results }Vue 模板里遍历的是 data.results不是 data 本身。5. 避坑毕业设计最常见的六个翻车现场5.1 时间少 8 小时今天创建的客户统计成 0现象前端看板“今日新增客户”显示 0但数据库里明明有当天记录。原因USE_TZTrue 时Django 在数据库里存的是 UTC 时间。如果你用 date.today() 去过滤 created_at__date拿到的是本地日期而数据库里的日期字段是按 UTC 存的两者错位 8 小时导致过滤结果为空。解决查询时用 Django 的 timezone 工具函数获取本地日期from django.utils import timezone today_start timezone.localdate() # 返回 Asia/Shanghai 时区的今天 customers Customer.objects.filter(created_at__datetoday_start)如果数据已经入库直接用 date.today() 查出来的可能就是空的这个坑在答辩前最容易出现因为考官很可能让你当场演示“今日数据”。另外前端拿到的 created_at 是 ISO 8601 带时区的字符串Vue 里直接用会导致显示时间比预期晚 8 小时你需要在序列化器里格式化或者前端用 dayjs 转成本地时间。5.2 跨域配置写了还是报 CORS现象axios 请求发出去了后端日志也能看到请求但浏览器就是报 “Access-Control-Allow-Origin” 错误。原因corsheaders 这个 app 加了CORS_ALLOWED_ORIGINS 也写了但中间件顺序不对。CorsMiddleware 必须放在 CommonMiddleware 之前否则浏览器预检请求OPTIONS被 CommonMiddleware 拦截响应头上没有 CORS 字段。解决检查 MIDDLEWARE 列表把 corsheaders.middleware.CorsMiddleware 放在 django.middleware.common.CommonMiddleware 上面一行。如果前端换过端口比如从 5173 改成 5174记得同步更新 CORS_ALLOWED_ORIGINS。开发阶段也可以直接把前端接口代理到 Django 端口但那就绕过了跨域不是真联调还是建议开着跨域测。5.3 删除客户把订单也删了级联方向写反现象在 admin 后台删掉一条客户记录结果订单列表里对应的成交单也没了。原因Order.customer 外键的 on_delete 误用了 CASCADE。Django 的级联删除是跟着外键走的订单外键指向客户CASCADE 意味着删客户时连坐订单。解决把订单表的外键改成 on_deletemodels.PROTECT。这个坑之所以严重是因为它不报错静默地把数据带走了等你发现时订单已经没了。PROTECT 会在删除时抛出 ProtectedError你在代码里 catch 一下提示“该客户存在订单不能删除请先处理订单”。跟进记录保留 CASCADE因为子记录跟着主表走是合理的。从那以后我设计外键时都会先问自己一句这个数据删了业务凭证还在吗5.4 SQLite 换成 MySQL 之后中文乱码现象开发时用 SQLite 一切正常部署时换成 MySQL迁移后中文全变成问号。原因MySQL 建库时没有指定字符集默认可能是 latin1Django 连接时虽然传了 charsetutf8mb4但数据库本身字符集不对写入就丢了。解决建库时显式指定字符集CREATE DATABASE car4s DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;同时在 settings.py 的 DATABASES OPTIONS 里保持 charset: utf8mb4。如果你已经建错库了先把数据导出drop 掉重建再导入。这一步不是 bug是环境初始化顺序问题但几乎每个从 SQLite 切 MySQL 的人都会撞上一次。5.5 ORM 惰性求值循环查询让页面卡了几秒现象客户列表页接口耗时从 200ms 变成 3s刷新越久越慢。原因序列化器里写了 sourcefollowups.count每返回一个客户就执行一条 count SQL。分页 10 条就是 10 条额外查询如果前端再循环展示每个客户的订单数查询次数直接翻倍。ORM 的惰性求值是个黑匣子不打印 SQL 你根本看不到这些隐式查询。解决用 annotate 在 ViewSet 层面对查询集做聚合返回的字段已经是计算好的数字序列化器只负责透传。这个坑的排查方法很简单把 Django 的 DEBUG 打开看页面加载时底层跑了多少条 SQL。如果发现 SQL 数量超过 20 条基本可以断定有 N1 问题。5.6 前端拿到 status 是 intention而不是“高意向”现象客户列表下拉框显示的是英文值不是中文状态名。原因序列化器默认返回的是数据库里存的值即 choices 的 key不是 label。前端拿到 statusintention直接渲染就成了英文。解决在序列化器里显式加一个字段返回展示文本class CustomerSerializer(serializers.ModelSerializer): status_display serializers.CharField(sourceget_status_display, read_onlyTrue) class Meta: model Customer fields [id, name, phone, status, status_display, source, created_at]get_status_display 是 Django 模型自带的方法会在 choices 里查 key 对应的 label。前端下拉框显示 status_display选中后提交 status 本身这样展示和存储分离后端不用改表结构。这个细节不解决答辩演示时客户状态那一列全是英文非常掉价。6. 从能跑到能答辩构建产物收编与关键路径验证6.1 把 Vue 构建产物交给 Django前后端联调通过之后最后的演示形态有两种一种是开发模式同时开两个服务Vue 跑 5173 端口Django 跑 8000 端口答辩时用浏览器访问 Vue 开发服务器另一种是把 Vue 构建成静态文件交给 Django 统一服务只开一个 8000 端口。我推荐第二种因为现场演示最怕的就是端口冲突、依赖安装失败。操作路径如下# 在 frontend 目录下执行构建 cd frontend npm run build # 构建产物在 frontend/dist 目录把它配置到 Django 的静态文件搜索路径里 python manage.py collectstatic --noinputsettings.py 里需要加上STATICFILES_DIRS [ BASE_DIR / frontend / dist, ]collectstatic 会把 dist 里的 index.html 和 JS/CSS 资源收到 STATIC_ROOT 指向的目录Django 后面就能直接伺服这些文件。注意 index.html 里的静态资源引用路径要写成相对路径或者 /static/ 前缀否则部署到子目录时资源 404。6.2 答辩前必过的四条验证路径构建完成不代表系统可用我会强制自己走一遍四条关键路径第一登录接口输入正确的用户名密码能拿到 token刷新页面后 localStorage 里的 token 还有效接口请求没有 401第二客户列表分页把 PAGE_SIZE 调成 5翻到第二页数据不重复、总数正确第三删除保护选一个有订单的客户尝试删除系统提示无法删除而不是报 500第四时间统计查看“今日新增客户”数量和数据库里当天记录数一致不差 8 小时。这四条路径每一条都对应一个真实的踩坑点走完它们基本能覆盖项目 80% 的演示场景。最初我做这套系统时也是先看别人拆好的源码再自己改数据库、加字段、接前端中间翻过车也踩过坑。到后来我每次拿到一个新环境跑完迁移部署之后都会强制自己走一遍这四条验证路径没有一次是白走的。希望帮到你。本文还有配套的精品资源点击获取