前阵子帮本地一家新能源品牌的S店把保养业务从“微信群接龙+纸质工单”整顿成了线上管理系统。这个系统本质上就是一个基于Python的Web管理平台：主业务用Django，辅助实时服务用Flask，把预约、接车、派工、施工、质检、结算和保养提醒全部串成了一条线。如果你正在学Django、Flask，或者正打算给门店类业务做一套轻量管理系统，这篇经验应该能帮你省掉不少弯路。
先说清楚，这里说的“S店”不是传统燃油车那种大而全的4S店，而是很多新能源品牌采用的“服务中心”形态，销售、交付、保养维修、配件这些职能都混在一栋楼里，人员不算多，但业务链条一点都不短。这套系统不是那种动辄几十个微服务的大型项目，而是强调“小而全、能落地、好维护”，正好能发挥Django和Flask各自的优势。
1. 项目整体设计与技术选型
1.1 业务需求拆解：S店保养到底要管什么
很多没接触过门店业务的人容易把保养系统想简单了，以为就是“登记一下谁来保养”。实际上门店运营里最耗人的是信息不同步：客户来了没人知道车之前修过什么，技师干完活没人同步配件用量，服务顾问还要手工记下一堆纸质单据，月底对账更是头疼。
所以在做需求拆解时，我先把整个保养生命周期梳理成几个核心节点：客户发起预约、服务顾问确认接车、技师施工并记录项目、质检员检查、客户结算、交车离店，最后是系统按里程或时间自动生成回访提醒。这七个节点串起来就是一条完整的状态流转线，系统里必须有一个主表能跟踪每条工单走到哪一步。
新能源车还要额外处理三电系统相关的检查项。传统燃油车保养是换机油机滤，新能源车保养则以电池组健康检查、驱动电机检测、电控系统诊断为主，再加上空调滤芯、刹车片、轮胎、冷却液这类常规项目。所以保养项目表需要区分“三电检测”和“常规保养”两大类，方便后续做统计报表和提醒策略。
除了业务主流程，还有几个配套模块不能少：客户档案、车辆档案、配件库存、保养项目库、预约记录、工单记录。听起来很多，但真正做完后你会发现，核心其实只有一张工单表和几张基础资料表，业务复杂度主要来自状态之间的流转关系，而不是表数量。
1.2 为什么是“Django主业务 + Flask辅助服务”，而不是二选一
这是整个项目被问得最多的问题。直接说结论：Django做核心业务系统，Flask做独立辅助服务，两边通过同一个MySQL数据库协作，这是我在这个项目里觉得最顺手的技术组合。
Django这边的优势非常明显：自带Admin后台、自带认证和权限体系、ORM模型迁移工具完善。像“服务顾问批量确认预约”“管理员维护保养项目库”这种偏后台管理的工作，Django Admin开箱即用，半小时就能搭出一个能给门店员工用的管理界面，不用自己写一堆重复的增删改查页面。
那Flask用来干什么？我把它部署成独立服务，专门提供三类能力：面向门店大厅大屏的工单状态实时推送、面向客户预约小程序的轻量API接口、以及保养数据周报统计接口。用Flask是因为它对WebSocket的支持比Django的Channels配置简单得多，几行代码就能跑起来，进程独立部署，即使Flask服务挂了，Django主业务也不会受影响。
有人会说“Django也能做这些，为什么要引入第二种框架”。道理是对的，但实际开发中还要考虑团队熟悉度和迭代效率。我当时的团队对Flask更熟，而且辅助服务本身逻辑很薄，用Django写还要处理一堆中间件和settings配置，反而是负担。技术选型不是越统一越好，而是让每个模块用最小成本解决问题。
1.3 项目目录结构与运行架构
项目实际落地是双进程架构。Django进程跑在8000端口，负责门店后台管理、客户档案、工单流转、配件管理；Flask进程跑在5010端口，负责WebSocket推送和大屏展示接口。前端页面通过Nginx做反向代理，把不同路径转发到不同后端服务，静态文件由Nginx直接托管。
project_root/ ├── manage.py ├── config/ # Django项目配置 │ ├── settings.py │ └── urls.py ├── apps/ │ ├── accounts/ # 用户、角色、权限 │ ├── customers/ # 客户与车辆档案 │ ├── appointments/ # 预约模块 │ ├── workorders/ # 工单模块 │ ├── parts/ # 配件库存 │ └── reminders/ # 保养提醒 ├── internal_flask/ # 辅助Flask服务 │ ├── app.py # 主要API │ ├── socket_server.py # WebSocket推送 │ ├── models_sqlalchemy.py │ └── uploads/ # 附件上传目录 └── static/ # 静态资源这个目录结构保持了Django的App划分习惯，Flask代码独立放在internal_flask目录里。实践下来有两个好处：一是主业务代码和辅助服务代码互不干扰，改Flask不会影响Django项目结构；二是Flask服务可以单独打包部署到另外一台机器上，适合以后业务量大了做拆分。
2. 数据库设计与核心业务表
2.1 核心表结构：从业务对象到数据模型
我在设计数据库表时坚持一个原则：每个业务对象只建一张主表，所有状态变化放到字段里管理，不轻易做冗余表。真正需要的日志表只有工单状态变更日志，其余都通过created_at和updated_at字段跟踪。下面这套核心表是我的最终方案，在实际项目中可以直接参考。
| 表名 | 职责 | 关键字段 |
|---|---|---|
| CustomerProfile | 客户档案 | name、phone、is_active |
| Vehicle | 车辆档案 | customer外键、vin、plate_number、battery_no、warranty_end_date |
| MaintenanceItem | 保养项目库 | name、category（三电/常规）、price、mileage_interval |
| Appointment | 预约记录 | customer、vehicle、appointment_time、status |
| WorkOrder | 保养工单 | appointment外键、status、advisor、technician、total_amount |
| WorkOrderLog | 工单状态日志 | work_order外键、from_status、to_status、operator |
| SparePart | 配件表 | part_no、name、stock_qty、price |
| StockRecord | 出入库记录 | part外键、change_type、qty、work_order外键 |
需要注意Vehicle表里的battery_no和warranty_end_date字段。电池是新能源车最贵的部件，保养时需要核对电池编号与档案是否一致，质保截止日则直接决定三电检测和分析报告的生成逻辑，这两个字段在传统车辆管理系统中没有，属于新能源业务的特有需求。
2.2 Django ORM 模型的落地实现
模型代码我用了Django原生的ORM，没有引入其他抽象层。关键设计是外键删除策略：客户和车辆使用PROTECT保护，工单与预约关联使用OneToOneField，配件出入库使用SET_NULL。这样不会因为误删一条基础资料导致整串业务数据消失。
# apps/workorders/models.py from django.db import models from django.contrib.auth.models import User class Vehicle(models.Model): customer = models.ForeignKey( 'customers.CustomerProfile', on_delete=models.PROTECT, verbose_name='车主' ) vin = models.CharField('VIN', max_length=17, unique=True) plate_number = models.CharField('车牌号', max_length=10, unique=True) brand = models.CharField('品牌', max_length=30) model = models.CharField('车型', max_length=50) battery_no = models.CharField('电池编号', max_length=30, blank=True) total_mileage = models.IntegerField('当前里程km', default=0) warranty_end_date = models.DateField('质保截止日') def __str__(self): return f'{self.plate_number} {self.model}' class WorkOrder(models.Model): STATUS_CHOICES = ( ('received', '已接车'), ('working', '施工中'), ('inspecting', '待质检'), ('pending_pay', '待结算'), ('delivered', '已交车'), ('revisited', '已回访'), ) appointment = models.OneToOneField( 'appointments.Appointment', on_delete=models.PROTECT, related_name='work_order' ) vehicle = models.ForeignKey(Vehicle, on_delete=models.PROTECT) advisor = models.ForeignKey( User, on_delete=models.PROTECT, related_name='advisor_orders', verbose_name='服务顾问' ) technician = models.ForeignKey( User, on_delete=models.SET_NULL, null=True, blank=True, related_name='technician_orders', verbose_name='技师' ) status = models.CharField('状态', max_length=20, choices=STATUS_CHOICES, default='received') total_amount = models.DecimalField('总金额', max_digits=10, decimal_places=2, default=0) finished_at = models.DateTimeField(null=True, blank=True) created_at = models.DateTimeField(auto_now_add=True)这套模型设计的关键是外键关系不要图省事全部用CASCADE。我见过太多项目因为删除客户导致关联车辆、工单、预约全被级联删除，一删就是几百条记录，根本找不回来。PROTECT策略虽然偶尔会挡住删除操作，但从数据安全和业务恢复角度看，强烈建议使用PROTECT或SET_NULL。
2.3 保养工单的状态流转设计
工单状态的流转是整个系统的业务核心。我把七个业务节点映射成六种状态：已接车、施工中、待质检、待结算、已交车、已回访，其中“待回访”由系统提醒任务触发，不占用工单主流程。状态流转只允许顺序前移，不允许跳转或回退，特殊情况下由管理员手动修正。
状态变更我单独建了WorkOrderLog表，每次状态变化都记录操作人、操作时间和前后状态。这个日志表有两个实际价值：一是门店经理能查到每台车为什么在某一步停了一整天，避免责任不清；二是后续做统计分析时，可以算出每个工单在各状态节点的停留时长，定位流程瓶颈。
状态流转的逻辑最好放在Django的信号里，而不是散落在各个视图函数中。我在每个状态更新操作之后，统一调用一个状态变更服务函数，向日志表和Flask推送服务发通知。这样维护起来思路非常清晰：业务操作只负责更新工单字段，状态机逻辑全部收敛到一个位置。
3. 关键功能实现与实操记录
3.1 RBAC权限控制：别让技师打开结算页面
这套系统有四个角色：管理员、服务顾问、技师、客户。管理员管理基础数据和用户；服务顾问负责预约确认、接车开单、结算交车；技师只能查看和更新自己负责的工单施工状态；客户通过小程序端口查看预约进度和历史记录。Django的Group加Permission机制完全够用，不需要引入第三方库。
角色控制的核心不是前端隐藏按钮，而是后端接口的真实校验。我做的第一版只在页面模板里用if user.is_technician判断显示内容，后来发现技术人员直接通过URL访问接口就能越权操作，非常危险。后来统一在后端视图函数入口做权限校验，服务顾问和技师的所有操作都必须过权限检查。
from django.contrib.auth.decorators import login_required, user_passes_test def is_advisor(user): return user.groups.filter(name='service_advisor').exists() or user.is_superuser @login_required @user_passes_test(is_advisor) def confirm_appointment(request, pk): appointment = get_object_or_404(Appointment, pk=pk) appointment.status = 'confirmed' appointment.save() return JsonResponse({'code': 0, 'msg': '预约已确认'})权限装饰器用起来确实简洁，但要注意一点：Django自带的Permission模型是基于Model层面的增删改查权限，无法精确控制“技师只能改自己的工单”。所以我额外加了一层行级过滤逻辑，在查询接口里用filter(technician=request.user)限定数据范围，避免技师看到店里所有工单的敏感信息。
3.2 后台数据实时推送到前端：Django与Flask各显身手
门店大厅有一块大屏，实时展示当前每台车的维修进度，客户等待时扫一眼就知道自己的车到哪一步了。这个需求本质上就是热搜词提到的“后台有数据前端推送”场景。最初我考虑用Django Channels，但配置ASGI、Redis channel layer确实有点繁琐，而且当时项目里已经有Flask，我就在Flask端用SocketIO实现了一套轻量的WebSocket推送服务。
Django端负责业务数据状态变更，变更后通过requests调用Flask的HTTP接口，把这个工单的状态、车牌号、更新时间推送给Flask。Flask收到后，利用房间机制把消息广播给所有订阅该工单的前端页面。
# internal_flask/socket_server.py from flask import Flask from flask_socketio import SocketIO, emit, join_room app = Flask(__name__) socketio = SocketIO(app, cors_allowed_origins='*') @socketio.on('subscribe_order') def subscribe_order(data): order_id = data.get('order_id') join_room(f'order_{order_id}') def push_order_status(order_id, status, plate_number): socketio.emit('order_status_update', { 'order_id': order_id, 'status': status, 'plate_number': plate_number, }, room=f'order_{order_id}')如果你不想引入Flask，纯粹用Django做这套推送也是可行的，Django Channels的consumer写法类似。但我的实际体验是，在一个已经用Django跑熟的项目里临时加ASGI服务，需要处理Django中间件、session、后台任务调度等一系列兼容问题，新手很容易卡住。把这类独立服务交给Flask，开发效率高很多，这是我推荐这个混合方案的核心理由。
3.3 跨框架共享同一个MySQL数据库的注意点
Django和Flask两个进程连接同一个MySQL数据库，这是整个项目里最容易踩坑的地方。我的做法是：数据库表全部由Django的migrate命令创建和维护，Flask端用SQLAlchemy连接现有表，只是读取和调用存储过程，不直接做复杂的写操作。
Flask端的模型映射用了SQLAlchemy的autoload特性，自动读取表结构生成模型，不用手工维护两份完全一致的表结构定义。但前提是两张框架服务的数据库账号权限要区分开：Django用可写账号，Flask用只读账号再加少量可执行存储过程的权限。这样能避免Flask服务被攻击时直接篡改业务数据。
之前出过一次很尴尬的事：Django模型里给WorkOrder加了一个finish_remark字段，但Flask端SQLAlchemy的模型定义更新不及时，导致Flask接口返回数据时字段对不上，前端大屏显示undefined。后来我强制规定，所有新增字段必须同时更新两边的模型定义，并且在Flask端写单元测试检查字段完整性，这个坑才彻底填上。
3.4 文件上传与附件路径的教训
保养工单中需要上传接车照片、检测报告图片、质检单扫描件，这个需求很常规，但路径问题把我和部署的同事折腾了很久。最初开发时写的是相对路径，比如file.save('uploads/' + filename)，在Windows本地跑得好好的，部署到服务器后发现附件全部保存到了当前工作目录之外，前端怎么都显示不了。
排查后发现两个问题：一是相对路径依赖进程启动时的当前目录，用systemd部署时这个目录不稳定；二是Windows和Linux的路径分隔符不一样，在代码里直接拼'uploads/photos/'这种斜杠，跨平台就出兼容问题。最后统一用pathlib设置绝对路径，上传目录固定在项目根目录下的uploads文件夹，配置里维护一个UPLOAD_DIR常量。
# internal_flask/app.py from pathlib import Path from flask import Flask, request, jsonify BASE_DIR = Path(__file__).resolve().parent UPLOAD_DIR = BASE_DIR / 'uploads' UPLOAD_DIR.mkdir(parents=True, exist_ok=True) @app.route('/api/upload', methods=['POST']) def upload_file(): file = request.files.get('file') if not file: return jsonify({'code': 1, 'msg': '缺少文件参数'}), 400 dest_path = UPLOAD_DIR / file.filename file.save(dest_path) return jsonify({'code': 0, 'url': f'/uploads/{file.filename}'})另外要注意Nginx配置，前端要能访问到附件，必须把/uploads/路径映射到Flask的静态目录。我在部署配置里加了这样一行：location /uploads/ { alias /data/project/internal_flask/uploads/; }。如果不加，附件只能走后端接口下载，静态页面里的图片标签会全部404。
4. 常见问题与排查技巧汇总
4.1 Django静态文件显示不了的排查路径
这个问题属于搜索引擎里的高频词，我自己在项目中也遇到过。在VSCode里写模板，img标签引用static目录中的图片就是显示不出来，页面报404。排查时先看三处：模板有没有加载static标签、settings里STATIC_URL和STATICFILES_DIRS有没有配对、静态文件路径有没有拼错。
最常见的问题是模板里直接写<img src="/static/img/car.png">，虽然能访问，但后续部署时STATIC_URL换掉就全部失效。正确做法是在模板顶部加{% load static %}，然后使用<img src="{% static 'img/car.png' %}">。另一种情况是项目根目录的static文件夹忘了加进STATICFILES_DIRS，Django生产环境默认只收集每个App下的static目录。
# config/settings.py STATIC_URL = '/static/' STATICFILES_DIRS = [BASE_DIR / 'static'] STATIC_ROOT = BASE_DIR / 'collect_static'调试模式下如果还是404，直接用浏览器访问http://127.0.0.1:8000/static/img/car.png看开发者工具返回的错误，能区分是路径问题还是文件不存在问题。实际部署时记得先跑python manage.py collectstatic --noinput把静态文件统一收集到STATIC_ROOT，再由Nginx托管。
4.2 删除对象的坑：CASCADE不是删除，而是灾难
这个教训来自一次客户要求“删掉一条测试数据”。开发同事用的代码是customer.delete()，结果这条客户关联的车辆、预约、工单、出入库记录全被级联删除了。数据库里关联的记录是隔离状态，一旦级联删除，业务数据直接缺失，连恢复到原状的办法都没有。
从那以后我规定了三条铁律：核心业务表统一用PROTECT或SET_NULL作为外键删除策略；执行删除操作前必须确认影响行数；客户、车辆、工单这类关键数据采用软删除，用is_active标志位隐藏而不是物理删除。
# 软删除示例：dfe客户不彻底删除 customer = CustomerProfile.objects.get(pk=pk) customer.is_active = False customer.deleted_at = timezone.now() customer.save()4.3 Flask部署后附件路径与静态资源问题
这套系统最终部署在一台Linux服务器上，用systemd托管Django和Flask两个服务。第一次上线时Flask接口能通，但网页加载不出图片。排查后发现是systemd服务的WorkingDirectory和项目实际路径不一致，导致Flask的UPLOAD_DIR解析到了错误目录。
解决办法是写配置时不依赖当前工作目录，统一从文件位置获取项目路径。Python的__file__配合pathlib足够可靠。部署顺序也建议固定：先跑Django迁移、再启动Flask、最后启动Django主业务，这样数据库就绪后两个服务都能正常连接。
另一个部署细节是Flask建议用gunicorn的gevent worker模式，不要在服务器上用自带的开发模式跑。开发模式的werkzeug在并发请求下性能很差，还容易打印一堆调试日志把磁盘占满。
4.4 前端页面如何绑定网页元素：模板渲染与AJAX的区分
有人问“Flask如何绑定到网页元素”，这个问题我在系统里是这样解决的：使用Jinja2模板做服务端渲染，在HTML里用{{ variable }}输出数据，同时配合AJAX调用API接口做局部刷新。两种方式各有适用场景，项目里也用得很明确：首屏数据和静态列表用模板渲染，实时状态和交互操作走API接口。
模板渲染适合保养项目列表、历史工单这类低频变化的数据，服务端直接拼好HTML返回，页面打开速度快。实时推送场景则必须靠AJAX或WebSocket，后端返回JSON，前端JavaScript负责更新DOM元素。以保养进度为例，前端在页面初始化时通过Jinja2输出工单初始状态，后续所有状态更新全部来自SocketIO推送事件。
<script> const socket = io('http://localhost:5010'); socket.emit('subscribe_order', {order_id: {{ work_order.id }} }); socket.on('order_status_update', function(data) { document.getElementById('status-text').innerText = data.status; }); </script>很多初学者容易混淆服务端渲染和客户端渲染，遇到图表动态更新就把整个页面刷新一遍，性能很差。实际项目里推荐的思路是：页面骨架由模板负责，动态数据用接口或推送负责，互不干扰。这套S店系统上线后，大厅大屏的实时刷新就是靠这种模式和Flask的WebSocket实现的，稳定运行了三个多月，没有出现卡死或断连的情况。
我在整个项目里最大的感受是：技术选型不是越复杂越好，而是把合适的工作交给合适的工具。Django把业务后台管得井井有条，Flask轻巧地扛起了实时推送和API服务，两者配合起来，用半个月的时间把一个门店从纸质流程带到了线上流转。如果你也打算做类似的门店管理系统，建议先把状态流转图画清楚，再动手建模型建表，数据结构定好了，后面写代码就是顺手的事。最后补一个小技巧：不论用什么框架，数据库备份脚本一定要在项目第一天就配好，这台S店系统上线第三周因为误删数据恢复过一次，没有备份的话那一天的工单就真的找不回来了。
