基于Python和Flask的电子点菜系统开发实战

相信不少刚入门Python的朋友都面临过同一个困惑：语法学了、爬虫会写了Linux系统安装Python也折腾过好几遍，但一到“做个完整的项目”就卡住了。做点菜系统，恰恰是综合程度比较高、离实际业务又近的练手项目。

本文要聊的，就是一套基于Python的电子点菜系统从零搭建过程。它能解决餐饮店纸质菜单更新慢、前台下单靠吼、营业数据难统计的痛点，特别适合学完Python基础想做完整Web项目的人参考，也适合餐饮行业有定制需求的技术爱好者。我会把架构设计、数据库表结构、核心接口逻辑、还有实际踩过的坑一并讲透，不是那种只给demo不给理由的文章。

1. 为什么电子点菜系统适合用Python来实现

1.1 从一沓手写菜单引发的需求梳理

先交代一下背景。2023年底，一个开小龙虾馆的朋友找我聊，说他店里高峰期服务员要跑前跑后记菜名，经常出现“菜上重了”“客人催了半天发现单没传后厨”的情况。他想让我帮忙搞个微信里能扫码点餐的玩意儿，预算几乎为零。

那时候我第一反应是这需求不难，但真正动工前我理了一遍业务流程，发现“电子点菜”根本不是做一个“能下单的网页”那么简单。它背后至少牵扯四类角色：顾客（浏览菜品、加购、下单）、前台收银（核验订单、处理优惠）、后厨（查看已下单菜品、标记出餐）、店长（维护菜品、查看营业报表）。

这四类角色的诉求完全不同：顾客要快、要直观；后厨要稳定、不能漏单；收银要能处理异常；店长要数据。所以技术方案不能只搞一个“能跑就行”的小网页，得把权限、流程、异常处理都设计进去。

1.2 技术选型：为什么是Python而不是Node.js或Java

说句实在话，如果给大厂做高并发外卖系统，我会选Java或Go。但朋友的小龙虾馆，日单量峰值也就几百单，后端逻辑主要围绕“菜单管理+订单流转+简单的统计报表”转，这时候Python的优势就非常明显：

• 开发效率高。同样是搭一套REST API，用Flask或FastAPI几十行就能把路由和参数校验写完，Java要配一堆依赖和配置文件。
• 生态契合数据分析。餐饮店后续要做“哪些菜卖得好”“一周营业额趋势”，Python的pandas、matplotlib直接无缝衔接，不用另起一套技术栈。
• 招人或自己维护成本低。Python人才基数大，坏代码找人接手也容易。

我最终选型是：后端用Flask + SQLAlchemy + SQLite（开发环境）/ PostgreSQL（生产），前端用Jinja2模板 + Bootstrap，扫码点餐页用轻量Vue.js（CDN引入）。这套组合的好处是，单文件就能启动整个系统，朋友店里的老电脑跑起来也毫无压力。

提示：如果你只想做个课程设计或者demo，SQLite完全够用，别一上来就整MySQL/PostgreSQL，那是给多用户并发环境准备的。课程设计答辩时老师问你“为什么用SQLite”，你可以理直气壮地回答：单机版系统不需要独立的数据库服务，部署成本更低、文件即数据、备份直接复制文件即可。

2. 系统架构与数据库表设计，先把地基打牢

2.1 三端一API的整体结构

系统的物理结构并不复杂，一个Flask应用同时充当Web服务端和API服务端。但逻辑上要把三端彻底分开：

共享同一个用户体系，用role字段区分三类后台用户（cashier、kitchen、admin）。顾客不登录，靠session_id维持购物车状态，下单时留手机号便于通知取餐/上菜。

这种设计的核心思路是：不让顾客感知到“后台”的存在，顾客端页面是纯展示+交互的薄客户端，所有校验和状态流转都在服务端完成。这样即使前端被绕过，直接调API，也拿不到越权数据。

2.2 数据表：少一张表，后面每个功能都得打补丁

数据库我设计成六张核心表，每张表的取舍都经历过实际业务的“毒打”，这里直接给大家看最终版：

sql复制-- 菜品分类表
CREATE TABLE category (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    name VARCHAR(50) NOT NULL,
    sort_order INTEGER DEFAULT 0,
    is_active BOOLEAN DEFAULT TRUE
);

-- 菜品表
CREATE TABLE dish (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    category_id INTEGER NOT NULL REFERENCES category(id),
    name VARCHAR(100) NOT NULL,
    description TEXT,
    price DECIMAL(10,2) NOT NULL,
    image_url VARCHAR(255),
    monthly_sales INTEGER DEFAULT 0,  -- 月售量，列表页展示用
    is_active BOOLEAN DEFAULT TRUE,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

-- 桌台表
CREATE TABLE table_seat (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    table_no VARCHAR(20) NOT NULL UNIQUE,
    qr_code VARCHAR(255),
    status VARCHAR(20) DEFAULT 'idle'  -- idle/occupied
);

-- 订单主表
CREATE TABLE orders (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    order_no VARCHAR(32) NOT NULL UNIQUE,
    table_id INTEGER REFERENCES table_seat(id),
    customer_phone VARCHAR(20),
    total_amount DECIMAL(10,2) NOT NULL,
    status VARCHAR(20) DEFAULT 'pending',  -- pending/confirmed/cooking/served/completed/canceled
    remark TEXT,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    paid_at DATETIME
);

-- 订单明细表
CREATE TABLE order_item (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    order_id INTEGER NOT NULL REFERENCES orders(id),
    dish_id INTEGER NOT NULL REFERENCES dish(id),
    dish_name VARCHAR(100) NOT NULL,  -- 冗余字段，防止菜品改名/删除后历史订单查不到
    price DECIMAL(10,2) NOT NULL,     -- 下单时价格快照
    quantity INTEGER NOT NULL DEFAULT 1,
    status VARCHAR(20) DEFAULT 'pending'  -- 单菜品出餐状态
);

-- 营业流水表
CREATE TABLE daily_report (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    stat_date DATE NOT NULL,
    total_orders INTEGER,
    total_revenue DECIMAL(10,2),
    avg_order_amount DECIMAL(10,2)
);

这里有两个字段是新手最容易忽略的，我吃过大亏，专门强调一下：

• order_item里冗余了dish_name和price。干餐饮的老手都懂，菜价会变，菜品会下架。如果不做快照，三个月后老板想查“这个月酸菜鱼卖了多少份”，结果发现酸菜鱼已经从菜单删了，关联查询直接扑空。
• monthly_sales放菜品表里。这属于典型的用空间换时间，虽然可以实时SELECT SUM(quantity) FROM order_item WHERE dish_id=...算月售，但顾客端菜单页每刷一次就算一遍全店菜品的聚合，数据库压力大，放一张表字段里更新是更务实的做法。

2.3 订单状态机：一张状态图理清所有流转

订单状态一开始我设计得过于简单，就pending/completed两种，结果上线没两天就出问题。客人下单后想加菜，后厨已经开始做了，加进去的菜和服务员口头报的混在一起，根本分不清哪道做了哪道没做。

后来我把状态改成六级，并且允许一个订单内的不同菜品有各自独立的出餐状态：

• pending：顾客已提交，待确认（一般自动确认）
• confirmed：收银员已确认
• cooking：后厨开始制作某菜品
• served：某菜品已上桌
• completed：整单完结（客人结账）
• canceled：整单取消

在后厨端页面，按order_item.status分组显示“待做”“制作中”“已上桌”，后厨只需点按钮把菜品状态从pending推进到cooking再到served即可。顾客扫码能看到自己那桌每个菜的实时进度，催菜问题少了八成。

3. 核心功能的分步实现，从接口到页面手把手过一遍

3.1 后端的路由设计：一个Flask应用管全套

路由设计上，我按照“顾客端API”“商户端页面”“统计报表API”三组划分，避免所有接口混在一起改起来头疼。下面是核心路由的清单：

python复制# 顾客端API
GET    /api/menu                    # 返回所有分类下的在售菜品
POST   /api/order                  # 提交订单
GET    /api/order/<order_no>        # 查询订单状态
POST   /api/order/<order_no>/items # 订单加菜

# 商户端页面（登录后访问）
GET    /admin/dashboard            # 收银台/总览
GET    /admin/orders?status=pending # 订单列表（可按状态筛选）
GET    /admin/kitchen              # 后厨看板
POST   /admin/order/<order_id>/status  # 更新订单状态

# 统计报表
GET    /api/report/daily?date=2024-01-15   # 日报
GET    /api/report/dish_sales?days=7       # 菜品销量TOP10

菜单接口的返回结构长这样，前端拿到就能直接渲染：

json复制{
  "code": 0,
  "data": [
    {
      "id": 1,
      "name": "特色小龙虾",
      "category": "招牌必点",
      "price": 88.00,
      "monthly_sales": 126,
      "image_url": "/static/img/dish_1.jpg"
    }
  ]
}

3.2 下单接口的实现：事务是必须的，不是可选项

下单是整个系统最核心的写操作，它同时要改三处数据：orders插入主记录、order_item插入明细、table_seat把桌台状态改成occupied。这三步必须在一个事务里完成，否则就会出现“桌台占了但订单没生成”这种脏数据。

python复制from flask import request, jsonify
from app import db
from models import Order, OrderItem, TableSeat, Dish

@app.route('/api/order', methods=['POST'])
def create_order():
    data = request.get_json()
    table_id = data.get('table_id')
    items = data.get('items')  # [{"dish_id": 1, "quantity": 2}, ...]
    remark = data.get('remark', '')

    if not table_id or not items:
        return jsonify({'code': 400, 'msg': '参数不完整'}), 400

    # 校验桌台状态
    table = TableSeat.query.get(table_id)
    if not table or table.status != 'idle':
        return jsonify({'code': 400, 'msg': '该桌台不可下单'}), 400

    order_no = generate_order_no()
    total_amount = 0
    order_items = []

    try:
        # 先算总价，校验菜品的在售状态和库存
        for item in items:
            dish = Dish.query.get(item['dish_id'])
            if not dish or not dish.is_active:
                return jsonify({'code': 400, 'msg': f'菜品{item["dish_id"]}不存在或已下架'}), 400
            amount = float(dish.price) * item['quantity']
            total_amount += amount
            order_items.append(OrderItem(
                dish_id=dish.id,
                dish_name=dish.name,
                price=dish.price,
                quantity=item['quantity']
            ))

        order = Order(
            order_no=order_no,
            table_id=table_id,
            total_amount=total_amount,
            remark=remark,
            status='pending'
        )
        order.items = order_items

        # 桌台标记为占用
        table.status = 'occupied'

        db.session.add(order)
        db.session.commit()
        return jsonify({'code': 0, 'data': {'order_no': order_no, 'total_amount': total_amount}})
    except Exception as e:
        db.session.rollback()
        # 日志记录异常
        app.logger.error(f'下单失败: {e}')
        return jsonify({'code': 500, 'msg': '服务器开小差了'}), 500

注意：db.session默认是自动开启事务的，只要在commit()之前有任何一步报错，执行rollback()就能把前面所有操作撤销。这是防止“数据只改了一半”的标准写法，千万不能偷懒不写try-except。

3.3 前端页面：顾客扫码看到的那个界面

顾客端页面是用Jinja2模板+原生JS写的，核心思路是服务端渲染首屏，客户端异步交互。这样兼顾了SEO（对菜单搜索友好）和交互体验。

菜单页用了一个非常简单的递归渲染，分类作为手风琴菜单，菜品卡片展示图片、名称、月售、价格：

html复制{% for cat in categories %}
<div class="category-section">
  <h3>{{ cat.name }}</h3>
  <div class="dish-grid">
    {% for dish in cat.dishes %}
    <div class="dish-card" data-id="{{ dish.id }}" data-name="{{ dish.name }}" data-price="{{ dish.price }}">
      <img src="{{ dish.image_url }}" alt="{{ dish.name }}">
      <div class="dish-info">
        <h4>{{ dish.name }}</h4>
        <p class="sales">月售 {{ dish.monthly_sales }}</p>
        <p class="price">¥{{ dish.price }}</p>
        <button class="btn-add" onclick="addToCart(this)">加入清单</button>
      </div>
    </div>
    {% endfor %}
  </div>
</div>
{% endfor %}

购物车逻辑用JS维护一个数组，存在localStorage里，页面刷新不丢。提交订单时，把table_id（从二维码参数里取）+items数组POST到/api/order。

这里想提醒一点：扫码点餐页的二维码内容要设计好。我不建议把整个URL写死，因为未来换域名或加参数都得重新印二维码。我是把桌台ID和店铺ID编进二维码的，类似https://yourdomain.com/scan?tid=12&shop=1001，扫码页先解析参数、再调API获取店铺信息并渲染。这样换域名只需要改服务端配置，不用重新印码。

4. 实际部署和上线过程中遇到的三个典型问题

4.1 并发下单导致订单号重复

第一次测试时我是单线程用浏览器一单一单下，没发现问题。等到店里真实高峰期，两个服务员同时操作，订单号就出现重复了。

排查链路是这样的：先看日志发现IntegrityError: UNIQUE constraint failed: orders.order_no，然后在本地用两个终端同时跑下单脚本复现。最后定位到generate_order_no()用的是time.strftime('%Y%m%d%H%M%S')，同一秒内生成的两个订单号必然相同。

解决方案也不复杂，用UUID的短字节拼接时间戳：

python复制import uuid

def generate_order_no():
    return time.strftime('%Y%m%d') + uuid.uuid4().hex[:10].upper()

这样既保留了日期可读性，又几乎不可能重复。核心教训是：并发问题在开发环境很难暴露，设计订单号等唯一标识时，默认就不能用时间戳这种“大概率唯一”的方案。

4.2 后厨端页面不同步

后厨端最初用Jinja2服务端渲染，但会出现一个很烦人的问题：后厨A打开看板，后厨B操作了某个订单状态，A的页面上不刷新什么都看不到。解决办法有两个方向：轮询和WebSocket。

我最终选了轮询，理由很现实：Flask自带WebSocket支持需要装额外库（flask-socketio），而餐厅后厨的浏览器环境普遍一般，轮询实现简单、出错概率低，每5秒请求一次/admin/api/orders?status=pending更新看板，对服务器压力完全可以接受。

后厨看板的接口直接返回HTML片段，前端用fetch拉回来替换tbody：

javascript复制setInterval(() => {
  fetch('/admin/api/kitchen_board')
    .then(res => res.text())
    .then(html => {
      document.getElementById('kitchen-board').innerHTML = html;
    });
}, 5000);

提示：轮询接口返回HTML片段而不是JSON再JS渲染，是为了减少前端模板维护成本。如果以后要同时供多个端使用，再拆JSON不迟，项目初期别过度设计。

4.3 跨域问题：顾客端和后台不在同一个端口

开始调试时，顾客端跑在localhost:5000，后台页面在另一个端口，前端要请求/api/order接口，直接被浏览器的CORS策略拦截。这个问题的本质是浏览器出于安全考虑，默认不允许不同源（协议、域名、端口任一不同）的页面跨域请求，防止我随便访问其他网站的接口。

解决办法是在Flask应用上挂CORS支持：

python复制from flask_cors import CORS

app = Flask(__name__)
CORS(app)  # 开发环境先全部放行，生产环境要指定来源

不过这里要特别提醒：CORS生产环境不能是CORS(app)裸写，必须限定白名单域名，否则任何恶意网站都能往你的点餐API发请求。正确的姿势是：

python复制CORS(app, resources={r"/api/*": {"origins": ["https://yourdomain.com", "http://localhost:5000"]}})

5. 系统怎么跑起来：完整的环境搭建与启动流程

很多初学Python的朋友卡在“代码有了但跑不起来”，这里我把环境搭建从头说一遍，已经熟悉的人可以直接跳到下一节。

5.1 Python环境准备

我强烈建议Windows用户先配置好Python环境变量，不然命令行敲python会提示找不到命令。如果你是从官网安装的Python，安装包第一屏有一个“Add Python to PATH”复选框，必须勾上。

Linux用户装Python更简单，Ubuntu/Debian系直接：

bash复制sudo apt update
sudo apt install python3 python3-pip python3-venv -y

安装完可以用python3 --version验证。最好再装一个虚拟环境管理依赖，避免不同项目之间的包版本打架：

bash复制python3 -m venv venv
source venv/bin/activate  # Windows用 venv\Scripts\activate

5.2 安装依赖并初始化数据库

Flask应用的项目目录结构我习惯这样组织：

code复制restaurant/
├── app.py               # 入口文件
├── models.py            # 数据模型
├── routes/
│   ├── customer.py      # 顾客端API
│   ├── admin.py         # 商户端页面
│   └── report.py        # 报表接口
├── templates/
│   ├── customer/
│   ├── admin/
│   └── base.html
├── static/
├── config.py            # 配置
└── requirements.txt

requirements.txt内容如下，版本号按我实测稳定版本锁定：

code复制flask==3.0.0
flask-sqlalchemy==3.1.1
flask-cors==4.0.0

安装一条命令：

bash复制pip install -r requirements.txt

初始化数据库表（在Python shell里执行）：

bash复制python

python复制>>> from app import app, db
>>> with app.app_context():
...     db.create_all()

5.3 启动第一个版本

bash复制python app.py

看到* Running on http://127.0.0.1:5000就说明起来了。浏览器访问http://127.0.0.1:5000/demo/menu就能看到测试菜品页。

如果启动时提示ImportError: No module named flask，说明当前Python环境没装上依赖，检查一下是不是忘了先pip install -r requirements.txt，或者虚拟环境没激活。

实测下来这套环境在Windows 10/11、Ubuntu 20.04/22.04上都能顺利跑通，不需要其他额外组件。

6. 从“能跑”到“好用”：报表统计和体验优化

6.1 营业日报：用Python的数据能力反哺老板决策

点菜系统不只是把纸质菜单电子化，最大的隐藏价值是数据沉淀。店长后台我加了一个日报接口，实现很简单，就是按天分组聚合订单表：

python复制from sqlalchemy import func
from datetime import date

@app.route('/api/report/daily', methods=['GET'])
def daily_report():
    stat_date = request.args.get('date', date.today().isoformat())
    result = db.session.query(
        func.count(Order.id),
        func.sum(Order.total_amount),
        func.avg(Order.total_amount)
    ).filter(Order.created_at.like(f'{stat_date}%'), Order.status == 'completed').all()

    count, total, avg = result[0]
    return jsonify({
        'code': 0,
        'data': {
            'date': stat_date,
            'total_orders': count,
            'total_revenue': float(total or 0),
            'avg_order_amount': round(float(avg or 0), 2)
        }
    })

更实用的其实是菜品销量排行，它直接指导老板哪些菜该做活动、哪些菜该下架：

python复制@app.route('/api/report/dish_sales')
def dish_sales():
    days = int(request.args.get('days', 7))
    since = date.today().isoformat()  # 简化版按当天算
    rows = db.session.query(
        OrderItem.dish_name,
        func.sum(OrderItem.quantity).label('total_qty')
    ).join(Order).filter(
        Order.status == 'completed',
        Order.created_at >= since
    ).group_by(OrderItem.dish_name).order_by(
        func.sum(OrderItem.quantity).desc()
    ).limit(10).all()

    return jsonify({'code': 0, 'data': [{'dish_name': r[0], 'quantity': r[1]} for r in rows]})

我朋友看了这个榜单，把月售前3的菜放在菜单首页“招牌推荐”，次月那几道菜的销量又涨了两成。这就是数据系统比纸质菜单值钱的地方。

6.2 购物车和加菜体验的细节

顾客端体验上有两个细节值得提：

1. 重复扫码vs新开桌。顾客第一单提交后离开页面，再扫码进入，如果桌台状态是occupied而且订单未完成，系统应该提示“您有进行中的订单”，而不是让客人再下一单占一次桌。
2. 加菜的场景。聚餐中途加菜很常见，我设计成订单主表加菜接口，新增的菜品跟原订单关联，结账时统一计算。加菜接口要判断订单是否已完成，完成状态不能再加。

python复制@app.route('/api/order/<order_no>/items', methods=['POST'])
def add_items(order_no):
    order = Order.query.filter_by(order_no=order_no).first()
    if not order:
        return jsonify({'code': 404, 'msg': '订单不存在'}), 404
    if order.status in ('completed', 'canceled'):
        return jsonify({'code': 400, 'msg': '当前订单状态不可加菜'}), 400

    data = request.get_json()
    for item in data.get('items', []):
        dish = Dish.query.get(item['dish_id'])
        if not dish or not dish.is_active:
            return jsonify({'code': 400, 'msg': f'菜品{item["dish_id"]}不可用'}), 400
        order.items.append(OrderItem(
            dish_id=dish.id, dish_name=dish.name,
            price=dish.price, quantity=item['quantity']
        ))
        order.total_amount += float(dish.price) * item['quantity']

    db.session.commit()
    return jsonify({'code': 0, 'data': {'order_no': order_no, 'total_amount': order.total_amount}})

6.3 菜单更新不用重启服务

传统小店改个价格，要重新印刷菜单。电子点菜系统天然解决这个问题，但如果菜单数据是写死在代码里的，那还不如纸质菜单。我在商户端做了菜品管理页面，支持增删改查，保存后即时生效。

这里有个小坑：Flask默认的DEBUG模式下改代码会自动重启，但改数据库内容是走SQLAlchemy的，根本不需要重启服务。如果发现改了库里数据页面上没变化，优先检查浏览器缓存和前端渲染逻辑，不要盲目重启。

7. 打包与交付：把Python项目变成朋友店里的正式工具

7.1 开发机跑和实际用是两码事

项目开发完后，不能天天让朋友开终端敲python app.py。要么部署到服务器上，要么用简易方式封装成本地服务。

我两种方式都做了实验：

• 部署到云服务器。用gunicorn启动Flask：

bash复制pip install gunicorn
gunicorn -w 4 -b 0.0.0.0:8000 app:app

然后用Nginx反代到80端口，静态文件交给Nginx处理，动态请求转发给gunicorn。这是比较标准的Python Web部署姿势。

• 本地Windows服务器模式。朋友店里的收银机是Windows，不方便装Linux。我的方案是用pyinstaller把Flask应用打包成exe，收银机开机自启，内网其他设备通过局域网IP访问。

7.2 PyInstaller打包踩坑记录

打包Flask应用有个经典问题：templates和static目录不会被自动包含。需要在spec文件里显式添加，否则打出来的exe运行后页面全是404。

restaurant.spec关键片段：

python复制a = Analysis(['app.py'],
             pathex=[],
             binaries=[],
             datas=[('templates', 'templates'), ('static', 'static')],
             hiddenimports=['flask_sqlalchemy', 'flask_cors'],
             hookspath=[],
             runtime_hooks=[],
             excludes=[])

exe = EXE(..., name='restaurant_system', console=False)

注意datas那行，没有它打包出来的exe就是个残废。hiddenimports也一样，SQLAlchemy的某些引擎模块是动态导入的，PyInstaller检测不到。

打包完成后在命令行执行：

bash复制pyinstaller restaurant.spec

dist目录下会生成restaurant_system.exe，双击就能运行。数据库文件我用的是SQLite，打包后数据库文件会生成在exe同目录下，需要保证该目录可写，否则订单存不上。

提示：如果朋友店里没有外网，扫码点餐功能就需要内网穿透或者局域网IP访问。我用的是路由器端口映射+动态域名解析，简单靠谱，成本为零。

8. 给同样想复刻这个项目的人一些实在建议

做了这套系统，我觉得最难的不是写代码，而是搞清楚业务到底要什么。技术选型、表结构、接口设计都是给真实业务流程服务的，业务想不明白，代码写得再漂亮也是空中楼阁。

如果你想复刻这个项目，我建议按以下顺序推进，而不是上来就写代码：

1. 手工梳理一遍餐馆的点餐流程，找一家熟悉的店观察半小时，画出谁是下单发起方、谁接单、谁制作、谁上菜、谁结账，状态从哪到哪。
2. 先画全部页面原型，不需要工具，白纸画框就行。把顾客端和商户端的每个页面信息列全，再开始建表。
3. 数据库先行，表结构和字段一次设计到位，尤其是冗余字段和状态字段，后期改表成本极高。
4. 先跑通最小闭环：菜单列表→下单→后厨看到→标记出餐→结账。这是系统的骨架，其他功能都是血肉。

我最早犯的错误就是一开始想做很多功能：用户注册、积分、优惠券、多门店、库存管理……结果写了俩星期连下单都没跑通。后来把所有非核心功能砍掉，专注把“从点菜到出餐”的10秒流程做好，才真正交付上线。

目前这套系统在我朋友店里跑了四个月，日处理订单100多单，没出过大问题。中间改过两次需求，一次是加了“口味选择”（辣度/少放葱），一次是加了“整单折扣”入口，都是在原有表结构上加字段或加枚举值完成的，充分证明当初预留扩展的设计是对的。

最后分享一个技巧：给系统加一个“演示模式”，内置一批测试菜品和模拟订单，新人接手或答辩演示时点两下就能看到全流程效果，比看说明文档直观得多。实现也很简单，在Flask CLI里加一个init-demo-data命令，一键填充测试数据就行了。

电子点菜系统的核心价值不在于用了多高级的技术，而在于把一件天天发生的小事做到稳定、顺手。用Python实现它，恰到好处。