这两年帮朋友做的几个小项目里餐厅点餐系统算是被问得最频繁的类型。这次这个“django-flask基于python的餐厅点餐服务系统”很多人第一反应是“为什么要同时用Django和Flask两个框架”。这篇文章就围绕这个点餐系统的实际设计与开发过程展开讲清楚双框架的分工、数据库设计、关键接口实现以及在真实落地时踩过的几个坑。整套系统做的事情不复杂顾客扫码看到菜单点菜下单后厨看到订单开始制作服务员确认上菜最后结账。但把这条链路用代码稳定地跑起来涉及到的细节远比想象中多。Django负责后台管理和数据侧Flask负责对外API和扫码入口两条服务共用同一个数据库各管一段整体架构清晰也方便后续扩展小程序或者App端。如果你正准备做课程设计、毕业设计或者帮小餐饮店搭一套可用的点餐系统这篇文章可以直接当成一份完整的设计参考。我尽量把每一步的选择逻辑和关键代码都写清楚哪怕是第一次接触Django和Flask的读者也能照着做出来。1. 为什么选择Django和Flask双框架组合1.1 两个框架各自适合什么场景Django是“全家桶”型框架自带ORM、Admin后台、表单校验、认证体系适合做数据模型复杂、需要大量管理界面的系统。点餐系统的菜品管理、订单管理、桌台管理、员工账号管理这些天然适合用Django的Admin来完成。我在实际项目中甚至不需要额外写管理后台页面注册好模型改一改list_display和search_fields后台就能直接用。Flask是“轻量级”框架路由简单、依赖少、自由度高适合做纯API服务。点餐小程序端或者H5端请求的接口比如获取菜单、提交订单、查询订单状态用Flask来写非常顺手。路由直接通过装饰器声明返回JSON再加一个JWT校验的装饰器接口层干净利索。有人问“一个项目里同时用两个框架是不是有点多余”。真实情况是服务端确实不需要两个框架处理同一套逻辑但“Django管后台、Flask管接口、共享同一个数据库”这种组合在中小型项目里很常见。本质上是把“管理端”和“C端接口”从物理上拆成了两个服务互不干扰其中一个出问题也不会拖垮另一个。1.2 双框架协作的核心思路所有协作的前提是同一个数据库。Django通过自己的ORM管理数据表结构Flask不重复建表直接用SQLAlchemy连接同一个MySQL库读取和写入。这样两个服务之间的“通信”就不需要走HTTP请求省掉了接口联调的复杂度和延迟。打个比方Django是店里的“收银台电脑”负责录入菜品、统计订单、管理桌台Flask是顾客手机里的“点餐小程序后端”顾客每一次点菜、加菜、催菜实际写进的是同一个账本。账本是共享的两边不会对不上。采用这种协作方式要注意一点数据库表结构统一由Django管理Flask这边只做数据读写不做表结构变更。每次改表结构在Django里跑迁移Flask这边只需要修改对应的模型映射即可。如果两边各自建表字段命名不一致后期的维护成本会直接翻倍。1.3 技术栈总体选型以下是我在这个项目中最终确定的技术组合每项都经过实际验证模块技术选型理由后端管理端Django 4.x自带Adminrest framework按需引入API服务端Flask 2.x轻量灵活接口响应速度快数据库MySQL 5.7关系型数据事务支持成熟接口鉴权PyJWT无状态适配Flask接口扫码点餐端H5网页免安装微信/支付宝内置浏览器直接打开缓存可选Redis菜单缓存、购物车临时存储这套技术组合的优势在于Django负责“重量”部分Flask负责“轻快”部分两者不冲突。即使你后续想单独抽一个Flask服务部署到多台机器上做负载均衡Django这边也完全不受影响。2. 系统模块拆分与数据模型设计2.1 核心业务模块划分餐厅点餐服务系统按角色划分可以拆成三个端顾客点餐端、商家管理端、后厨工作端。三个端共用同一套数据和业务逻辑只是入口和权限不同。顾客点餐端通过Flask提供的API获取菜品分类、菜品列表提交订单后能看到订单状态。商家管理端通过Django Admin完成菜品上下架、价格修改、桌台绑定、订单查看和退款处理。后厨工作端最简单的实现方式是一块挂在厨房的平板或大屏定时请求Flask接口获取新订单也可以用WebSocket做实时推送。这三个端我建议在项目初期就明确好边界不要混在一起写。我最初图省事把后厨查询页面也塞进了Django Admin的订单列表页里结果后厨人员不小心点了编辑把订单状态改乱了。后来把后厨端独立成只读页面只展示新订单和制作状态问题就没了。2.2 数据库表结构设计点餐系统核心表有六张店铺表、桌台表、菜品分类表、菜品表、订单表、订单明细表。如果后续要做会员、积分、优惠券再往上加表和字段。店铺表和桌台表的关联比较关键。一家餐厅有多个桌台每个桌台生成一个独立的二维码二维码内容里写入桌台ID。顾客扫码时Flask接口根据桌台ID判断是哪家店、哪个桌这样一家餐厅只用部署一套系统后续同样的代码可以服务多个门店。菜品表要重点设计好状态字段。菜品状态有“在售”“停售”“估清”今日卖完三类。停售是主动下架估清是当天卖完自动切换。用数字枚举存储0在售、1停售、2估清后台Admin里做成下拉选项分类筛选时也方便。订单表是整个系统的核心字段设计上要预留扩展空间。订单号建议用“时间戳 随机数”生成避免使用自增ID作为对外暴露的订单号。订单状态字段用状态机管理我在后面专门讲。订单金额分“原价金额”“实付金额”“优惠金额”三个字段哪怕现在不做优惠活动也建议留出来后面接优惠券或者会员折扣时就不用改表了。如下是Django侧的核心模型代码基于常见实践整理from django.db import models class Store(models.Model): name models.CharField(max_length64, verbose_name门店名称) address models.CharField(max_length255, verbose_name门店地址) phone models.CharField(max_length20, verbose_name联系电话) status models.BooleanField(defaultTrue, verbose_name是否营业) created_at models.DateTimeField(auto_now_addTrue) class Meta: db_table store verbose_name 门店 verbose_name_plural 门店 class Table(models.Model): store models.ForeignKey(Store, on_deletemodels.CASCADE, verbose_name所属门店) table_no models.CharField(max_length10, verbose_name桌台编号) capacity models.IntegerField(default4, verbose_name用餐人数) qr_code models.CharField(max_length255, blankTrue, verbose_name二维码内容) status models.BooleanField(defaultTrue, verbose_name是否启用) class Meta: db_table table verbose_name 桌台 verbose_name_plural 桌台 class Category(models.Model): name models.CharField(max_length32, verbose_name分类名称) sort models.IntegerField(default0, verbose_name排序) status models.BooleanField(defaultTrue, verbose_name是否显示) class Meta: db_table category verbose_name 菜品分类 verbose_name_plural 菜品分类 class Dish(models.Model): category models.ForeignKey(Category, on_deletemodels.CASCADE, verbose_name所属分类) name models.CharField(max_length64, verbose_name菜品名称) price models.DecimalField(max_digits6, decimal_places2, verbose_name单价) image models.ImageField(upload_todishes/, blankTrue, verbose_name菜品图片) status models.IntegerField(default0, verbose_name状态) desc models.CharField(max_length255, blankTrue, verbose_name描述) created_at models.DateTimeField(auto_now_addTrue) class Meta: db_table dish verbose_name 菜品 verbose_name_plural 菜品订单和订单明细模型我要单独强调一下“金额精度”的问题。价格字段统一用DecimalField不要用FloatField。浮点数在计算机中存储本身有误差虽然几块钱的菜看不出问题但订单汇总时经常出现一分钱差额对账对到怀疑人生。DecimalField搭配decimal_places2在MySQL中映射为decimal类型金额计算就稳定了。class Order(models.Model): STATUS_CHOICES ( (0, 待支付), (1, 已支付), (2, 制作中), (3, 制作完成), (4, 已上菜), (5, 已完成), (6, 已取消), (7, 已退款), ) order_no models.CharField(max_length32, uniqueTrue, verbose_name订单号) store models.ForeignKey(Store, on_deletemodels.CASCADE, verbose_name门店) table models.ForeignKey(Table, on_deletemodels.CASCADE, verbose_name桌台) total_amount models.DecimalField(max_digits8, decimal_places2, verbose_name订单总金额) pay_amount models.DecimalField(max_digits8, decimal_places2, verbose_name实付金额) status models.IntegerField(default0, choicesSTATUS_CHOICES, verbose_name订单状态) remark models.CharField(max_length200, blankTrue, verbose_name备注) created_at models.DateTimeField(auto_now_addTrue) updated_at models.DateTimeField(auto_nowTrue) class Meta: db_table order verbose_name 订单 verbose_name_plural 订单 class OrderItem(models.Model): order models.ForeignKey(Order, on_deletemodels.CASCADE, related_nameitems, verbose_name所属订单) dish models.ForeignKey(Dish, on_deletemodels.CASCADE, verbose_name菜品) dish_name models.CharField(max_length64, verbose_name菜品名称快照) price models.DecimalField(max_digits6, decimal_places2, verbose_name下单时单价) quantity models.IntegerField(default1, verbose_name数量) subtotal models.DecimalField(max_digits8, decimal_places2, verbose_name小计) class Meta: db_table order_item verbose_name 订单明细 verbose_name_plural 订单明细订单明细里存了两个关键“快照”字段dish_name和price。这两个字段看起来冗余但非常必要。菜品名称和价格随时可能被修改历史订单里的菜品名称和下单价格不能被改动否则顾客投诉时没有依据。这是餐饮系统设计里一个很容易被忽略但非常重要的原则明细表必须存快照不能依赖关联查询。2.3 订单状态机的设计订单状态是整个系统流转的核心建议用状态机思维来管理而不是散乱地到处判断状态。状态流转方向如下待支付 - 已支付 - 制作中 - 制作完成 - 已上菜 - 已完成待支付状态下可以取消已支付状态下可以退款制作完成后可以上菜。任何一步逆向往回走都属于异常操作需要在代码里拦截。Django侧写一个事务方法统一处理状态流转而不是在视图里直接改status字段。因为在状态更新之前可能要同步更新库存、记录操作日志、推送消息给后厨这些操作必须在一个事务里完成要么全部成功要么全部失败。我见过一个同学的毕业设计里直接在Admin下拉框里手动改订单状态改完发现库存和报表都乱了就是因为没有做事务和校验。Flask端查询订单状态时直接读Django写入的status字段转换为中文返回给前端。这样两个服务对“状态”的理解完全一致不会出现“Django改了状态Flask不认”的问题。3. Django端后台管理模块的实现要点3.1 项目创建与基础配置Django端建议单独建一个虚拟环境项目名称用backend_admin应用名称用orders、dishes、tables三个模块分开管理。创建命令如下python -m venv venv source venv/bin/activate # Windows下为 venv\Scripts\activate pip install django django-admin startproject backend_admin cd backend_admin python manage.py startapp orders python manage.py startapp dishes python manage.py startapp tablessettings.py里需要配置好MySQL连接。生产环境不建议使用SQLite虽然开发方便但SQLite不支持并发写入点餐高峰时段多条订单同时写入会直接报“database is locked”错误。MySQL配置要在__init__.py里加一段pymysql的适配import pymysql pymysql.install_as_MySQLdb()数据库连接参数建议写到环境变量或者单独的config文件里不要硬编码在settings.py中。至少要把密码和host独立出来方便不同环境切换。3.2 Admin后台的定制清单Django Admin是这套系统最大的生产力工具合理定制能让日常运营效率大幅提升。每个模型都注册到Admin并按实际业务场景配置展示字段。菜品管理页面把“分类”做成侧边筛选栏把“状态”做成顶部筛选“菜品名称”加入搜索栏。这样运营人员每天早晚查看估清菜品、上架新菜品时基本是点两下就能操作完。订单管理页面默认展示列表时不要展示全部字段列表页只显示订单号、桌台、金额、状态、创建时间五个字段。剩余字段放在详情页展示。列表页如果字段太多后台加载速度会变慢运营人员找到目标订单时也费眼。订单详情页要把订单明细用InlineModelAdmin嵌入展示直接在订单详情里看到点了哪些菜、单价多少、数量多少。订单列表的“状态”筛选和“按时间排序”几乎每天都要用。按照实际经验把orders.updated_at添加索引因为运营人员最常看的是“今天新订单”排序效率很重要。数据库表数据量大了之后没有索引的排序会非常慢。3.3 Django端下单逻辑的事务处理顾客通过Flask端提交订单时Flask端会直接往数据库写入订单。但这里有一个坑Django的ORM和Flask的SQLAlchemy虽然操作同一个数据库但Django默认的事务隔离等级和SQLAlchemy不完全一致。Django写入订单并提交事务Flask这边查询订单状态时有可能因为事务隔离级别的问题读不到最新数据。解决办法是Flask端每次请求后都主动关闭数据库连接池中的旧连接或者使用“读已提交”READ COMMITTED隔离级别。SQLAlchemy配置连接时加上pool_pre_pingTrue每次请求连接前先探测一下连接是否有效避免拿到一个已经失效的旧连接。后厨端显示客户下单记录的实时性是这个项目的核心体验点不能做成“顾客下单后后厨刷新页面才能看到新订单”。最简单可靠的做法是Django端通过Celery定时任务每隔几秒向后厨大屏推送一次新订单数量或者用Django Channels跑WebSocket。如果只是课程设计和毕业设计定时轮询完全够用不要过度设计实时架构增加项目复杂度。3.4 Django端登录认证与权限设计后台Admin不能直接暴露给所有员工。按角色划分店长有全部权限普通店员只能查看和修改部分字段。Django Admin虽然没有原生的细粒度字段权限但可以通过重写ModelAdmin的get_form方法根据用户角色动态隐藏某些字段。我的做法是给员工用户分组店长属于manager组服务员属于waiter组后厨属于kitchen组。waiter只能操作订单状态从“制作完成”到“已上菜”不能退款kitchen只能看到新订单和完成制作不能修改价格。这段逻辑在Admin里重写get_queryset即可kitchen组的用户查询订单列表时只返回当前状态为“已支付”和“制作中”的单子其他状态统一隐藏。这个过滤逻辑听起来简单但实际使用中效果非常好可以有效防止误操作。4. Flask端点餐API的设计与实现4.1 API接口清单与流程设计Flask端是整个系统的“门面”顾客扫码后进入的H5页面全部走Flask接口。接口按业务流程分为四组扫码进入、菜单查询、订单操作、订单状态查询。接口路径方法功能说明/api/scan/tablePOST提交桌台二维码内容返回桌台信息和店铺名称/api/menu/listGET获取菜品分类和全部在售菜品/api/cart/addPOST加入购物车存储在后端/本地/api/order/submitPOST提交订单生成订单和订单明细/api/order/queryGET根据订单号查询订单状态和明细/api/order/notifyPOST支付回调接口预留扫描二维码这一步的细节二维码内容建议直接使用URL例如https://xxx.com/table/12H5页面加载后前端解析URL路径中的table_id再调用/api/scan/table提交。不要把桌台ID放在二维码下方暴露给用户也不要只用纯文本因为顾客看到一堆数字会困惑。做成URL的好处是顾客扫码直接进页面体验顺畅自然。4.2 Flask项目结构与数据库映射Flask项目单独建一个flask_api目录与Django项目平行。项目结构如下flask_api/ ├── app.py ├── config.py ├── models.py ├── auth.py ├── api/ │ ├── menu.py │ ├── order.py │ └── table.py └── requirements.txtmodels.py里通过SQLAlchemy映射Django创建的数据表。这里有个关键点SQLAlchemy映射已有数据库表时不需要声明字段的nullable、default等属性只要字段名和类型对应上即可。核心映射代码如下from flask_sqlalchemy import SQLAlchemy db SQLAlchemy() class Category(db.Model): __tablename__ category id db.Column(db.Integer, primary_keyTrue) name db.Column(db.String(32)) sort db.Column(db.Integer) status db.Column(db.Boolean) class Dish(db.Model): __tablename__ dish id db.Column(db.Integer, primary_keyTrue) category_id db.Column(db.Integer, db.ForeignKey(category.id)) name db.Column(db.String(64)) price db.Column(db.Numeric(6, 2)) image db.Column(db.String(255)) status db.Column(db.Integer) class Order(db.Model): __tablename__ order id db.Column(db.Integer, primary_keyTrue) order_no db.Column(db.String(32)) table_id db.Column(db.Integer) total_amount db.Column(db.Numeric(8, 2)) status db.Column(db.Integer) class OrderItem(db.Model): __tablename__ order_item id db.Column(db.Integer, primary_keyTrue) order_id db.Column(db.Integer, db.ForeignKey(order.id)) dish_id db.Column(db.Integer) dish_name db.Column(db.String(64)) price db.Column(db.Numeric(6, 2)) quantity db.Column(db.Integer) subtotal db.Column(db.Numeric(8, 2))这种映射方式看起来简单但要注意字段类型。Django的DecimalField对应SQLAlchemy的NumericDjango的datetime字段对应DateTime。数值类型写错会导致排序和计算错误排查起来费劲。建议建表后先写几个测试数据再用Flask端查询一遍验证字段类型匹配无误再进行下一步。4.3 菜单查询接口的完整实现菜单查询是点击频率最高的接口顾客打开页面就开始请求。菜品和分类在餐厅营业期间其实很少改动所以这个接口非常适合做缓存。在课程设计阶段不引入Redis也可以直接在Flask层加一个内存缓存缓存时间60秒。from flask import Blueprint, jsonify, request from models import db, Category, Dish, Order, OrderItem from datetime import datetime import random import time menu_bp Blueprint(menu, __name__, url_prefix/api/menu) category_cache {time: 0, data: None} menu_bp.route(/list, methods[GET]) def menu_list(): now time.time() if category_cache[data] is not None and now - category_cache[time] 60: return jsonify({code: 0, data: category_cache[data]}) categories Category.query.filter_by(statusTrue).order_by(Category.sort).all() data [] for cat in categories: dishes Dish.query.filter_by(category_idcat.id, status0).all() dish_list [ { id: d.id, name: d.name, price: str(d.price), image: d.image or , desc: d.desc, } for d in dishes ] data.append({id: cat.id, name: cat.name, dishes: dish_list}) category_cache[time] now category_cache[data] data return jsonify({code: 0, data: data})价格字段转成字符串返回避免浮点数误差在JSON序列化时出现“19.900000000000002”这种尴尬情况。Django端的DecimalField在JSON序列化时也会有这个问题建议统一在序列化层处理为字符串前端拿到后正常展示即可。这个细节在实际开发中很容易被忽略前台展示个歪七扭八的小数非常影响顾客信任感。4.4 订单提交接口与并发控制订单提交流程是整个系统里最容易出问题的环节。多个顾客同时下单或者同一个顾客短时间内重复点击提交都会导致重复下单或者超卖。我这里给出两个层面的防护。第一层是前端防重复提交顾客点击“提交订单”按钮后立即置灰按钮同时开启一个5秒的禁止重复提交倒计时。这个操作能过滤掉大部分手滑场景。第二层是后端防重复订单号Flask端生成订单号时加入桌台ID和时间戳、随机数确保唯一。提交订单时先查一下当前桌台是否已有“待支付”状态的订单如果有就不允许再生成新订单直接返回已有订单信息。这个逻辑能有效拦截“顾客把提交按钮当刷新键狂点”的情况。order_bp.route(/submit, methods[POST]) def submit_order(): data request.get_json() table_id data.get(table_id) items data.get(items) remark data.get(remark, ) if not table_id or not items: return jsonify({code: 1, msg: 参数错误}), 400 existing Order.query.filter_by(table_idtable_id, status0).first() if existing: return jsonify({code: 2, msg: 当前桌台有未支付订单, order_no: existing.order_no}), 200 total_amount 0 order_items [] for item in items: dish Dish.query.get(item[dish_id]) if not dish or dish.status ! 0: return jsonify({code: 3, msg: f菜品 {item.get(dish_id)} 已下架}), 400 subtotal dish.price * item[quantity] total_amount subtotal order_items.append({ dish_id: dish.id, dish_name: dish.name, price: dish.price, quantity: item[quantity], subtotal: subtotal, }) order_no generate_order_no(table_id) new_order Order( order_noorder_no, table_idtable_id, total_amounttotal_amount, pay_amounttotal_amount, status0, remarkremark, created_atdatetime.now(), updated_atdatetime.now(), ) db.session.add(new_order) db.session.flush() for oi in order_items: oi[order_id] new_order.id db.session.add(OrderItem(**oi)) db.session.commit() return jsonify({code: 0, order_no: order_no, amount: str(total_amount)})生成订单号的函数推荐用“桌子ID 时间戳 随机三位数”这样一个订单号基本不会重复def generate_order_no(table_id): ts datetime.now().strftime(%Y%m%d%H%M%S) rand random.randint(100, 999) return f{table_id}{ts}{rand}这里有个隐藏bug提示把订单写入和订单明细写入放在同一个事务中执行必须用flush而不是commit。flush把数据写入数据库但未提交这样能拿到自增ID再把明细关联上去最后统一commit。如果不flush直接commitnew_order可能还没有ID明细里的order_id就写不进去。4.5 Flask端JWT认证与权限控制Flask端接口不能全部裸奔菜单查询可以不用登录但订单查询和提交必须验证身份。最简单的方案是给每次请求颁发一个短期JWT token顾客扫码进入页面时前端调用一个免登录的token接口后端临时生成一个绑定桌台ID的token。我用PyJWT签发token有效期设两小时。顾客在这期间加菜、查单都不需要重新扫码。JWT的核心是签名校验用户改一个字符整段token就失效可以放心放在前端传给后端。import jwt from flask import request, jsonify SECRET_KEY 你的签名密钥建议用环境变量 def generate_table_token(table_id): payload { table_id: table_id, exp: datetime.utcnow() timedelta(hours2), iat: datetime.utcnow(), } return jwt.encode(payload, SECRET_KEY, algorithmHS256) def verify_table_token(): auth_header request.headers.get(Authorization, ) token auth_header.replace(Bearer , ) try: payload jwt.decode(token, SECRET_KEY, algorithms[HS256]) return payload[table_id] except jwt.ExpiredSignatureError: return None except jwt.InvalidTokenError: return None提交订单接口在调用verify_table_token后校验token里包含的table_id和请求参数里的table_id是否一致。如果不一致直接拒绝防止顾客篡改桌台号把菜点到别人的桌子上去。5. 前后端联调、常见问题排查与避坑5.1 双服务端口与反向代理配置Django和Flask同时跑在一台服务器上时端口要分开配置。Django跑在8000端口Flask跑在5000端口。前端H5页面访问Flask接口运营人员访问Django Admin。建议使用Nginx做反向代理统一入口server { listen 80; server_name example.com; location /admin/ { proxy_pass http://127.0.0.1:8000; } location / { proxy_pass http://127.0.0.1:5000; } }这样用户访问example.com/就是点餐H5页面访问example.com/admin/就是后台管理端不用记端口号。Nginx配置简单但要注意proxy_pass后的地址不要漏了结尾的斜杠漏了会导致路径拼接错乱。5.2 跨域问题的标准解法H5页面如果部署在Nginx的80端口Flask在5000端口前端请求Flask接口时会发生跨域。最简单的方案是给Flask端安装Flask-CORS统一放开跨域请求。生产环境建议限定域名不要用*全放开。from flask_cors import CORS CORS(app, resources{r/api/*: {origins: your-domain.com}})跨域放开的范围控制在/api/*不要把管理后台接口也放开。管理后台接口如果被跨域访问等于在浏览器控制台里就能直接操作后台安全风险极大。5.3 并发下单导致超卖餐厅点餐系统的“超卖”场景是一个菜品剩余最后一份两个顾客同时提交订单系统同时扣减库存最终都下单成功了。解决方式有两种。方式一用Django Admin后台关闭“菜品管理”里的库存扣减开关不做实时库存管理。小型餐厅的菜基本不存在“限量”问题顶多是估清运营人员手动在后台把菜品状态改成“估清”即可。方式二需要做库存管理时在SQL层面加乐观锁。更新菜品库存的SQL中加入WHERE count 1条件如果更新影响行数为0说明库存不足直接返回“菜品已售罄”。两种方式的取舍要看业务需要如果只是课程设计方式一已经能满足需求。5.4 各种“低频但致命”的隐藏问题整理几个联调中容易踩的坑用表格列出方便对照排查问题现象根因解决方案Flask查不到Django刚写入的数据SQLAlchemy连接池持有旧事务快照配置pool_pre_pingTrue请求结束主动关闭会话菜品价格在前端显示为长小数DecimalField JSON序列化未处理序列化时统一转为字符串提交订单偶尔返回500订单明细未flush拿不到自增ID先flush再写明细统一commit后台修改菜品图片后页面不刷新Nginx缓存静态资源设置反向代理时关闭静态缓存或加版本号两个服务时间相差导致状态错乱服务器时区配置不一致统一使用Asia/Shanghai数据库时区同步设置最后一个时区问题特别容易忽略。Django的settings.py里设置了TIME_ZONE“Asia/Shanghai”但MySQL连接时如果没设置连接时区Django写入的时间戳和SQLAlchemy读出来的时间可能差8小时。在MySQL连接URL里加上?charsetutf8mb4timezone08:00问题马上解决。5.5 支付接口预留与回调幂等如果顾客使用微信或支付宝付款流程要复杂一些。我在课程设计版里预留了“支付回调接口”并未直接对接真实支付平台理由很简单支付需要商户号、证书等资质个人很难直接申请下来。但接口设计上我按标准的支付回调格式预留。支付回调接口必须做“幂等处理”。同一笔支付回调可能因为网络问题被重复推送多次接口接收到回调后先查订单状态如果已经是“已支付”直接返回成功不再重复处理。这个逻辑如果漏掉顾客支付一次订单可能被更新两次后厨可能看到两条相同订单处理起来相当头疼。6. 系统优化与后续扩展建议6.1 菜单缓存与Redis引入基础版里用Flask内存缓存菜单属于单机方案。如果后续要部署多台Flask服务做负载均衡内存缓存就没法共享每台机器各自缓存一份可能出现数据不一致。这时候引入Redis分发缓存把菜单数据缓存到RedisFlask启动时先从Redis拿拿不到再查MySQL并回填。菜单页的响应速度直接影响顾客体验。实测下来不加缓存的接口响应时间约80ms加了Redis后降到15ms内。80ms看起来不多但顾客翻菜单时连续请求十个商品列表差距就很明显了。这个优化性价比非常高。6.2 购物车临时存储的前后端取舍H5点餐页面支持“先加购再统一提交”。如果购物车数据只存在前端顾客切到别的页面再回来购物车信息可能丢失。基础版我建议购物车直接放在前端localStorage提交订单时一次性把商品列表发给后端生成订单。这样Flask端不需要写购物车接口大幅减少工作量对顾客来说体验也顺畅。如果要支持“顾客扫码离店后重新进来恢复购物车”那就需要后端存储可以用Redis的Hash结构key为table_idfield为dish_idvalue为数量。订单提交成功后删除对应key。Redis存储方案的复杂点在于要处理购物车过期时间顾客可能加完菜没下单就走了Redis key加一个30分钟的过期时间即可。6.3 WebSocket实时通知与后厨大屏基础版后厨端用轮询接口实现每3秒请求一次新订单接口。轮询的缺点是延迟高、浪费服务器资源。升级方案是使用WebSocketFlask端使用Flask-SocketIO实现Django端使用Django Channels实现。这两个方案选一个就可以不建议两个一起上。我个人的推荐是如果偏向前端展示Flask-SocketIO就够用后厨大屏用SocketIO客户端接入订单创建时服务端主动emit一个新订单通知后厨端1秒内就能看到。Django Channels的学习成本和部署复杂度更高适合订单量更大、更复杂的场景。6.4 管理后台报表与数据看板Django Admin虽然管理数据方便但做数据统计报表能力偏弱。运营最关心的指标是“今日营业额”“今日订单数”“菜品销量TOP10”。可以在Django里注册一个自定义视图用ORM聚合查询直接渲染成简单的HTML表格功能不多但胜在实用。营业额统计要注意“退款订单”的剔除。统计status ! 6 and status ! 7的订单金额总和才是有效的营业收入。如果直接把全部订单金额加一起退款订单的金额会虚增营业额对账时出入很大。6.5 后续接入小程序端的架构变化如果后续要做微信小程序端Flask接口基本不用大改只需要在小程序里适配登录体系。可以用wx.login拿到用户身份再与Flask的JWT体系对接生成小程序专属token。小程序端和H5端在订单状态流转上逻辑统一但要注意小程序端“支付”流程更规范必须对接微信支付。Django端预留好pay_time字段和transaction_id字段在Order模型上增加两个可空字段即可后续扩展时不用再改表结构。7. 项目部署上线要点7.1 服务器环境与进程守护开发环境下直接python manage.py runserver和python app.py跑服务但上线部署必须换用支持并发的方式。Django端部署使用Gunicorn启动Flask端因为接口很少同样可以用Gunicorn。gunicorn backend_admin.wsgi:application -w 2 -b 127.0.0.1:8000 gunicorn app:app -w 2 -b 127.0.0.1:5000每台服务器上两个进程都要常驻用systemd写两个service文件管理设置开机自启和异常自动重启。部署时很重要的点是先跑一遍Django迁移命令确认表结构与模型一致再启动服务。如果先启动了服务再去迁移可能引发查询时报字段不存在的错误。7.2 数据备份与恢复数据备份是做任何系统都必须做的功课尤其是订单数据。最简单的方式是每天凌晨用crontab调用mysqldump备份整个数据库。mysqldump -uusername -ppassword restaurant /backup/restaurant_$(date \%Y\%m\%d).sql find /backup -name *.sql -mtime 7 -exec rm -f {} \;第二行命令是清理七日前备份避免备份文件堆积占满磁盘。恢复数据时先创建空数据库再导入备份导入之前最好把原库再备份一次防止误操作。7.3 安全加固的几个细节服务器安全不能只盯着代码漏洞部署层面的加固同样影响深远。Django的settings.py里要关闭DEBUG否则接口报错时会把代码路径和SQL信息暴露给用户非常危险。Flask端同样要设置DEBUGFalse并自定义统一的错误处理返回JSON而不是把堆栈信息返回给前端。Admin后台的URL不要用默认的/admin/可以在urls.py里改成一个不易猜测的路径。虽然不能完全防攻击但能挡住大部分扫描程序的无差别试探。后台登录账号也要用强密码最好开启两步验证。Django Admin登录页面本身不具备防暴力破解功能如果密码太简单被爆破的风险不小。写在最后的实操心得做餐厅点餐系统这类业务型项目真正拉开差距的往往不是代码多华丽而是对业务流程的理解深度。比如订单明细存快照、状态机统一流转、支付回调幂等这些细节不亲自做一遍开发看再多文档也很难有体感。如果从零开始做这个项目我的建议是不要一开始就同时写Django和Flask先把Django的数据模型建好、Admin后台能用再单独写Flask的菜单接口和订单接口最后才把两个服务联调起来。渐进式开发能大幅减少排错时间一次只解决一个问题。最后分享一个小技巧整套系统写完后一定要模拟完整流程走一遍——扫桌台码、进菜单页、加购、提交订单、支付回调、后厨出餐、服务员上菜、完成订单。我用脚本模拟了十张桌台同时下单的场景当场发现了三处并发问题都和数据一致性相关。这种压力测试在开发阶段一定不能省等到上线再发现问题就只能看着顾客的订单干着急了。希望这份设计思路和踩坑记录能帮你少走一些弯路。做业务系统稳永远是第一位的。