Django与Flask混合开发：新能源S店保养管理系统实战

前阵子帮本地一家新能源品牌的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_activeVehicle车辆档案customer外键、vin、plate_number、battery_no、warranty_end_dateMaintenanceItem保养项目库name、category三电/常规、price、mileage_intervalAppointment预约记录customer、vehicle、appointment_time、statusWorkOrder保养工单appointment外键、status、advisor、technician、total_amountWorkOrderLog工单状态日志work_order外键、from_status、to_status、operatorSparePart配件表part_no、name、stock_qty、priceStockRecord出入库记录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_deletemodels.PROTECT, verbose_name车主 ) vin models.CharField(VIN, max_length17, uniqueTrue) plate_number models.CharField(车牌号, max_length10, uniqueTrue) brand models.CharField(品牌, max_length30) model models.CharField(车型, max_length50) battery_no models.CharField(电池编号, max_length30, blankTrue) total_mileage models.IntegerField(当前里程km, default0) 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_deletemodels.PROTECT, related_namework_order ) vehicle models.ForeignKey(Vehicle, on_deletemodels.PROTECT) advisor models.ForeignKey( User, on_deletemodels.PROTECT, related_nameadvisor_orders, verbose_name服务顾问 ) technician models.ForeignKey( User, on_deletemodels.SET_NULL, nullTrue, blankTrue, related_nametechnician_orders, verbose_name技师 ) status models.CharField(状态, max_length20, choicesSTATUS_CHOICES, defaultreceived) total_amount models.DecimalField(总金额, max_digits10, decimal_places2, default0) finished_at models.DateTimeField(nullTrue, blankTrue) created_at models.DateTimeField(auto_now_addTrue)这套模型设计的关键是外键关系不要图省事全部用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(nameservice_advisor).exists() or user.is_superuser login_required user_passes_test(is_advisor) def confirm_appointment(request, pk): appointment get_object_or_404(Appointment, pkpk) appointment.status confirmed appointment.save() return JsonResponse({code: 0, msg: 预约已确认})权限装饰器用起来确实简洁但要注意一点Django自带的Permission模型是基于Model层面的增删改查权限无法精确控制“技师只能改自己的工单”。所以我额外加了一层行级过滤逻辑在查询接口里用filter(technicianrequest.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(forder_{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, }, roomforder_{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(parentsTrue, exist_okTrue) 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_DIRSDjango生产环境默认只收集每个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(pkpk) 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店系统上线第三周因为误删数据恢复过一次没有备份的话那一天的工单就真的找不回来了。