基于Python与树莓派构建个性化餐饮收银与库存管理系统

1. 项目概述：当美食家程序员遇上收银机器人

作为一名在代码和厨房之间反复横跳多年的程序员，我常常觉得，最棒的创意往往诞生于两种看似无关的领域的交叉点。比如，一边琢磨着怎么让代码更“美味”（指可读性和可维护性），一边烦恼着下班后去哪个小馆子能快速解决晚餐。正是在这种日常的“分裂”中，我萌生了一个想法：能不能做一个既懂美食，又能高效处理订单的“收银机器人”？这个项目，我称之为“美食家程序员的收银机器人”，它不是一个冰冷的、只会扫码算账的机器，而是一个融合了个人口味偏好、库存智能管理和高效交易流程的个性化解决方案。

简单来说，这个“收银机器人”是一个软硬件结合的小型系统。它的核心目标是：为我个人或小型美食工作室，提供一个高度定制化、自动化程度高，且充满“美食家”情趣的订单与收银管理工具。它要解决的痛点非常具体：当我研发新菜谱、举办小型私厨活动，或者仅仅是管理自己的零食库存时，传统的手写记账、通用收银软件都显得笨重且缺乏情感连接。我需要一个能理解“西班牙海鲜饭的藏红花成本占比”、“手冲咖啡的豆子批次风味记录”，并能快速生成带有个性化备注的账单的工具。

这个项目适合谁呢？首先是有技术背景的美食爱好者，比如像我一样的程序员厨师、烘焙极客；其次是经营小型、个性化餐饮单元的主理人，如私房菜、咖啡工作室、烘焙坊；最后，任何对“用技术赋能生活趣味”这件事感兴趣的朋友，都能从中获得启发。它不追求商业收银系统的庞大全能，而是强调深度定制、数据关联与体验乐趣。接下来，我将从设计思路到代码实现，再到踩坑实录，完整拆解这个“食谱成功法”背后的每一个细节。

2. 核心设计思路：为什么是“美食家”+“程序员”的混合体？

做一个收银系统，市面上成熟的开源或商业方案很多。直接用一个现成的，比如基于平板电脑的POS软件，难道不香吗？在项目启动前，我反复问自己这个问题。最终的答案指向了“控制力”和“表达力”这两个核心需求。通用的解决方案无法满足我对“美食”数据维度的特殊关切。

2.1 从通用收银到个性化美食账本的理念转变

通用收银系统的核心数据模型通常是：商品 -> 价格 -> 数量。这对于便利店卖瓶装水足够了。但对于一个美食家而言，一个“商品”背后的信息是立体的。以我常做的一道“黑松露奶油蘑菇意面”为例，在通用系统里，它可能只是一个售价68元的菜品。但在我的世界里，它包含：

• 成本维度：意大利直面（品牌A）、蘑菇（种类B，当日市价）、黑松露酱（品牌C，用量5克）、奶油（毫升）、帕玛森奶酪（克）。每一项的成本都在浮动。
• 工艺维度：这道菜关联的食谱步骤ID，提醒我烹饪时的关键火候和时间点。
• 风味维度：我可以为它打标签——“浓郁”、“适合配干白”、“秋冬限定”。甚至关联本次使用的黑松露酱的批次编号，以便追溯风味差异。
• 销售维度：不仅是最终售价，还包括它是作为套餐的一部分出售，还是单点，以及对应的折扣策略（例如，配指定酒水打9折）。

你看，一个简单的菜品，在我这里需要变成一个多维度的数据对象。通用POS系统允许你添加备注，但无法结构化地存储、查询和计算这些信息。我的核心设计思路，就是构建一个以“美食项目”为中心，辐射成本、工艺、风味、销售的多维数据模型。收银，只是这个模型在交易时刻的一个快照应用。

2.2 技术栈选型：轻量、灵活与快速原型

明确了“数据模型先行”的思路后，技术选型就需要服务于快速迭代和高度定制。我放弃了从零用C++或Java编写一个桌面应用的想法，那太重了。也放弃了直接修改大型开源POS系统（如Odoo的POS模块），其代码复杂度高，定制成本巨大。

我选择了以下技术组合，它完美契合了“程序员个人项目”的敏捷和“美食家”的细腻需求：

1. 后端核心：Python (FastAPI)

   • 为什么是Python？生态丰富。处理食谱（文本）、成本计算（数值）、图片（如果后续要传菜品图）都能找到成熟的库（如Pandas, Pillow）。代码表达力强，快速实现业务逻辑。
   • 为什么是FastAPI？相比Django或Flask，FastAPI的现代特性（自动API文档、数据验证依赖注入）让我能极快地构建出稳定、自文档化的RESTful API。这对于后期可能扩展的移动端或网页端管理界面至关重要。

2. 数据存储：SQLite + JSON字段

   • 主数据用SQLite：项目初期，数据量小，并发低。SQLite无需单独部署数据库服务，一个文件搞定，备份和迁移极其方便，完美契合个人或小微场景。
   • 扩展属性用JSON：这是关键设计。我在数据库中为“菜品”表设置了一个JSON或TEXT类型的attributes字段。用于存储那些不固定的、结构化的扩展信息，比如{"cost_breakdown": {"pasta": 5.0, "mushroom": 8.0}, "tags": ["浓郁", "秋冬"], "recipe_id": 12}。这样，我无需频繁修改数据库表结构，就能灵活地添加各种“美食家”字段。

3. 前端交互：Streamlit

   • 为什么不是Vue/React？对于一个以管理和操作为主的工具，开发一个完整的SPA（单页应用）耗时耗力。Streamlit是一个为数据科学家设计的工具，它允许我完全用Python脚本创建交互式Web应用。
   • 优势：我可以在几行代码内添加一个菜品下拉选择框、一个数量输入滑块、一个实时计算总价的区域。它自动处理前端渲染和与后端逻辑的交互，让我能专注于业务逻辑和用户体验设计，快速打造出一个可用的“收银机器人”界面。

4. 硬件接口：树莓派 + 扫码枪（可选）

   • 为了增加“机器人”的实体感，我使用树莓派作为主机运行整个程序。通过USB接入一个普通的二维码扫码枪。
   • 工作流：我为每个常用菜品或原料生成一个二维码贴纸。扫码时，扫码枪模拟键盘输入，将二维码内容（如菜品ID）直接“键入”到Streamlit应用的输入框中，从而触发添加菜品的操作。这比用鼠标点击下拉菜单快得多，尤其在忙碌的模拟出餐环节。

这个技术栈的核心思想是最大化开发效率，最小化运维成本，让作为“美食家”的我，能更专注于业务逻辑（菜品、成本、风味）的设计，而不是陷入繁琐的技术实现泥潭。

3. 核心模块拆解与实现细节

整个系统可以划分为四个核心模块：数据管理、收银交易、库存联动和报表分析。下面我逐一拆解其设计要点和关键代码逻辑。

3.1 数据管理模块：定义你的“美食宇宙”

这是系统的基石。我设计了以下几张核心表：

• recipes(食谱表)：记录菜谱的详细步骤、技巧、图片链接。id为主键。

• ingredients(原料表)：记录每一种原料的详细信息，如名称、单位（克、毫升、个）、当前库存、预警阈值、基准单价。这里“基准单价”是一个参考，实际成本可能通过关联采购记录动态计算。

• menu_items(菜品表)：这是核心。字段包括：

  id INTEGER PRIMARY KEY, name TEXT NOT NULL, -- 菜品名 base_price REAL NOT NULL, -- 基础售价 category TEXT, -- 分类，如“前菜”、“主菜”、“甜品” attributes TEXT, -- JSON字符串，存放扩展属性 recipe_id INTEGER, -- 关联的食谱ID FOREIGN KEY (recipe_id) REFERENCES recipes (id)

  其中，attributes字段的JSON结构示例：

  { "cost_ingredients": [ {"ingredient_id": 1, "quantity": 100, "unit": "g"}, {"ingredient_id": 2, "quantity": 200, "unit": "ml"} ], "tags": ["辛辣", "下酒"], "prep_time_minutes": 15, "is_seasonal": true, "pairing_suggestion": "冰镇啤酒" }

• purchases(采购记录表)：记录每一次原料采购，用于计算实际成本。包含原料ID、采购单价、数量、采购日期、供应商。

关键实现逻辑（Python + SQLAlchemy ORM）：

定义MenuItem模型时，如何处理attributes这个JSON字段？我使用SQLAlchemy的JSON类型（如果底层数据库支持，如PostgreSQL）或配合pickle/json模块进行处理。在SQLite中，虽然存储的是TEXT，但可以通过属性方法让它行为像字典。

from sqlalchemy import Column, Integer, String, Float, Text from sqlalchemy.ext.declarative import declarative_base import json Base = declarative_base() class MenuItem(Base): __tablename__ = 'menu_items' id = Column(Integer, primary_key=True) name = Column(String, nullable=False) base_price = Column(Float, nullable=False) attributes = Column(Text) # SQLite中存储JSON字符串 # 将attributes作为字典来访问的属性方法 @property def attrs(self): if self.attributes: return json.loads(self.attributes) return {} @attrs.setter def attrs(self, value): self.attributes = json.dumps(value) # 使用示例 item = session.query(MenuItem).first() print(item.attrs.get('tags', [])) # 获取标签 item.attrs['prep_time_minutes'] = 20 # 设置准备时间 session.commit()

注意：频繁在JSON字段中进行复杂查询（如“查找所有tags包含‘辛辣’的菜品”）在SQLite中效率不高。对于需要高频、复杂查询的JSON属性，应考虑将其拆分为单独的关联表。我的策略是：高频、固定的筛选条件（如category）用独立字段；低频、灵活的描述性信息（如tags,pairing_suggestion）用JSON。这需要在灵活性和性能间取得平衡。

3.2 收银交易模块：流畅的结账体验

收银界面（用Streamlit构建）需要清晰、反应迅速。核心交互流程是：

1. 选择或扫码添加菜品。
2. 实时显示订单列表、单项小计、总价。
3. 支持修改数量、删除菜品。
4. 选择折扣方式（百分比折扣、固定金额减免、关联套餐折扣）。
5. 选择支付方式（现金、电子支付、挂账）。
6. 确认结账，生成订单快照，并触发库存更新。

Streamlit 界面关键代码片段：

import streamlit as st import pandas as pd # 初始化session_state，用于在Streamlit的多次运行间保持状态 if 'order_items' not in st.session_state: st.session_state.order_items = [] # 存储订单项，每个项是字典 # 侧边栏：菜品选择 st.sidebar.header("📋 菜单") # 从数据库加载菜品，这里简化为一个列表 menu_data = fetch_all_menu_items() # 假设这个函数返回菜品列表 menu_names = [item['name'] for item in menu_data] menu_dict = {item['name']: item for item in menu_data} selected_item = st.sidebar.selectbox("选择菜品", menu_names) quantity = st.sidebar.number_input("数量", min_value=1, value=1, step=1) if st.sidebar.button("添加到订单"): item_info = menu_dict[selected_item] # 检查是否已存在相同菜品，存在则增加数量 found = False for oi in st.session_state.order_items: if oi['id'] == item_info['id']: oi['quantity'] += quantity found = True break if not found: st.session_state.order_items.append({ 'id': item_info['id'], 'name': item_info['name'], 'price': item_info['base_price'], 'quantity': quantity }) st.sidebar.success(f"已添加 {quantity} x {selected_item}") # 主区域：显示当前订单 st.header("🛒 当前订单") if st.session_state.order_items: order_df = pd.DataFrame(st.session_state.order_items) order_df['小计'] = order_df['price'] * order_df['quantity'] st.dataframe(order_df[['name', 'price', 'quantity', '小计']]) # 使用st.dataframe进行交互式显示 total = order_df['小计'].sum() st.metric("订单总计", f"¥{total:.2f}") # 折扣和支付 col1, col2 = st.columns(2) with col1: discount_type = st.radio("折扣类型", ["无", "百分比", "固定金额"]) if discount_type == "百分比": discount_value = st.number_input("折扣比例 (%)", min_value=0.0, max_value=100.0, value=10.0) final_total = total * (1 - discount_value/100) elif discount_type == "固定金额": discount_value = st.number_input("折扣金额 (¥)", min_value=0.0, max_value=total, value=5.0) final_total = total - discount_value else: final_total = total with col2: payment_method = st.selectbox("支付方式", ["现金", "微信支付", "支付宝", "挂账"]) if st.button("确认结账", type="primary"): # 调用后端API，创建订单记录，更新库存 order_success = create_order(st.session_state.order_items, discount_type, discount_value if discount_type != '无' else 0, payment_method, final_total) if order_success: st.balloons() st.success("结账成功！订单已保存。") st.session_state.order_items = [] # 清空当前订单 else: st.error("结账失败，请检查库存或网络连接。") else: st.info("订单为空，请从左侧添加菜品。")

这个界面实现了基本的添加、显示、计算和结账功能。st.session_state是Streamlit中用于在用户交互间保持状态的关键。

3.3 库存联动模块：让成本管理自动化

这是体现“程序员”严谨性的部分。每当一笔订单成交，系统需要自动扣减对应菜品的原料库存。这依赖于menu_items表中attributes里存储的cost_ingredients配方清单。

订单创建时的库存扣减逻辑（FastAPI后端）：

from sqlalchemy.orm import Session from models import Order, OrderItem, MenuItem, Ingredient, InventoryLog from schemas import OrderCreate import json def create_order_with_inventory(db: Session, order_data: OrderCreate): """ 创建订单并扣减库存 """ # 1. 创建订单主记录 db_order = Order(total_amount=order_data.final_total, ...) db.add(db_order) db.flush() # 获取order.id # 2. 遍历订单中的每一个菜品项 for item in order_data.items: # 创建订单明细记录 db_order_item = OrderItem(order_id=db_order.id, menu_item_id=item.menu_item_id, quantity=item.quantity, ...) db.add(db_order_item) # 3. 根据菜品ID，找到菜品，并解析其原料配方(attributes->cost_ingredients) menu_item = db.query(MenuItem).filter(MenuItem.id == item.menu_item_id).first() if not menu_item: continue # 或抛出异常 attrs = json.loads(menu_item.attributes) if menu_item.attributes else {} cost_ingredients = attrs.get('cost_ingredients', []) # 4. 根据配方和订单数量，扣减对应原料库存 for ci in cost_ingredients: ing_id = ci.get('ingredient_id') required_qty = ci.get('quantity', 0) * item.quantity # 单个菜品用量 * 订单数量 unit = ci.get('unit') # 找到原料记录 ingredient = db.query(Ingredient).filter(Ingredient.id == ing_id).first() if ingredient: # 检查库存是否充足（这里简化处理，实际需考虑单位换算） if ingredient.current_stock >= required_qty: ingredient.current_stock -= required_qty # 记录库存变更日志，用于追溯 log = InventoryLog( ingredient_id=ing_id, change_amount=-required_qty, reason=f"订单消耗: 订单#{db_order.id}, 菜品#{menu_item.id}", remaining_stock=ingredient.current_stock ) db.add(log) else: # 库存不足，应回滚订单创建，并抛出异常 db.rollback() raise ValueError(f"原料 {ingredient.name} 库存不足。所需: {required_qty}{unit}, 当前: {ingredient.current_stock}{ingredient.unit}") else: # 配方中的原料ID不存在，记录错误但不中断（取决于业务规则） print(f"Warning: Ingredient ID {ing_id} not found for menu item {menu_item.id}") # 5. 所有扣减成功，提交事务 db.commit() return db_order

实操心得：库存扣减的原子性与事务上面的代码将订单创建和库存扣减放在同一个数据库事务中。这是至关重要的。如果先创建订单成功，但在扣减库存时某个原料不足，整个事务会回滚（db.rollback()），订单不会被创建。这保证了数据的一致性：不会出现订单生效了但库存没扣，或者库存扣了但订单没记录的情况。对于SQLite，由于其锁机制，在高并发下可能成为瓶颈，但在个人或小微场景下完全够用。如果未来扩展到多用户，需要考虑更复杂的并发控制策略。

3.4 报表分析模块：从数据中洞察“美食生意”

数据沉淀下来后，需要变成洞察。我设计了几个核心报表：

1. 销售报表：按日/周/月/菜品/分类统计销售额、销量、平均客单价。
2. 成本与毛利分析：根据菜品配方和原料采购价（取最近采购价或加权平均价），动态计算每个已售出菜品的成本，进而分析毛利。
3. 库存周转与预警：列出库存低于安全阈值的原料，分析哪些原料周转慢（可能不新鲜或不受欢迎）。
4. 菜品受欢迎度分析：结合销售数据和可能的“点赞”或“评价”数据（如果后续添加），找出明星菜品和待改进菜品。

实现关键：使用Pandas进行灵活的数据分析。

后端提供聚合数据的API，或者直接写一个Streamlit页面，用Pandas连接数据库进行分析和可视化。

# 一个简单的Streamlit销售分析页面示例 import streamlit as st import pandas as pd import plotly.express as px from database import get_db_session from models import Order, OrderItem from sqlalchemy import func, Date st.header("📈 销售分析") # 连接数据库 session = get_db_session() # 查询最近30天的订单数据 query = ( session.query( func.date(Order.created_time).label('date'), func.sum(Order.final_total).label('daily_sales'), func.count(Order.id).label('order_count') ) .filter(Order.created_time >= func.date('now', '-30 days')) .group_by(func.date(Order.created_time)) .order_by('date') ) df_daily = pd.read_sql(query.statement, session.bind) if not df_daily.empty: fig = px.line(df_daily, x='date', y='daily_sales', title='近30日销售额趋势', labels={'daily_sales': '销售额 (¥)', 'date': '日期'}) st.plotly_chart(fig, use_container_width=True) # 菜品销量排名 st.subheader("热销菜品TOP 10") query_items = ( session.query( MenuItem.name, func.sum(OrderItem.quantity).label('total_sold') ) .join(OrderItem, OrderItem.menu_item_id == MenuItem.id) .join(Order, Order.id == OrderItem.order_id) .filter(Order.created_time >= func.date('now', '-30 days')) .group_by(MenuItem.id, MenuItem.name) .order_by(func.sum(OrderItem.quantity).desc()) .limit(10) ) df_items = pd.read_sql(query_items.statement, session.bind) st.dataframe(df_items) else: st.info("暂无销售数据。")

这个模块将冰冷的交易数据，转化为了指导“美食生意”决策的热图，比如该多备哪些货、哪些菜品利润高值得推广、哪些菜品点单少可能需要优化或下架。

4. 部署与硬件集成：让“机器人”动起来

软件部分完成后，需要让它在一个“机器人”般的环境中稳定运行。我选择树莓派作为载体。

4.1 树莓派环境配置

1. 系统选择：使用 Raspberry Pi OS Lite (64-bit)，无桌面环境，更节省资源。
2. 依赖安装：

   # 更新系统 sudo apt update && sudo apt upgrade -y # 安装Python3, pip, 虚拟环境工具 sudo apt install python3 python3-pip python3-venv -y # 安装数据库驱动等系统依赖（如果需要） sudo apt install libsqlite3-dev -y

3. 项目部署：

   # 克隆代码到/home/pi目录 cd /home/pi git clone <你的项目仓库地址> cashier-robot cd cashier-robot # 创建虚拟环境并激活 python3 -m venv venv source venv/bin/activate # 安装Python依赖 pip install -r requirements.txt

4. 设置自启动服务：使用 systemd 确保程序在树莓派启动时自动运行。
   • 创建服务文件：sudo nano /etc/systemd/system/cashier-robot.service

   [Unit] Description=Foodie Cashier Robot Service After=network.target [Service] Type=simple User=pi WorkingDirectory=/home/pi/cashier-robot Environment="PATH=/home/pi/cashier-robot/venv/bin" ExecStart=/home/pi/cashier-robot/venv/bin/streamlit run app.py --server.port 8501 --server.headless true --server.enableCORS false --server.enableXsrfProtection false Restart=on-failure RestartSec=5s [Install] WantedBy=multi-user.target

   • 启用并启动服务：

   sudo systemctl daemon-reload sudo systemctl enable cashier-robot.service sudo systemctl start cashier-robot.service sudo systemctl status cashier-robot.service # 检查状态

   现在，只要树莓派开机，收银机器人Web服务就会在后台运行。

4.2 扫码枪集成与优化

普通的USB扫码枪在系统识别为键盘（HID设备）。扫码后，它就像人在键盘上输入一串字符然后按了回车。在Streamlit应用中，需要有一个输入框来接收这个“输入”。

优化技巧：使用全局快捷键监听（需额外库）

默认的Streamlit输入框需要先点击聚焦才能输入。为了达到“随手扫”的体验，我使用了pynput库来监听全局键盘事件，自动将扫码内容填充到指定位置。

# 这是一个简化的独立脚本，运行在后台监听扫码枪输入 from pynput import keyboard import pyperclip import time # 假设扫码枪扫码后会以“ENTER”键结束 scanned_data = [] def on_press(key): try: # 扫码枪输入通常是字符 scanned_data.append(key.char) except AttributeError: # 处理特殊键，如回车 if key == keyboard.Key.enter: barcode = ''.join(scanned_data) print(f"Scanned: {barcode}") # 这里可以将barcode通过进程间通信(如socket、文件、队列)发送给Streamlit主进程 # 或者模拟一次HTTP请求到FastAPI后端，由后端通知前端更新 # 简化处理：复制到剪贴板，Streamlit应用可以轮询剪贴板 pyperclip.copy(barcode) scanned_data.clear() # 清空缓存，准备下一次扫描 elif key == keyboard.Key.esc: # 停止监听 return False # 启动监听 with keyboard.Listener(on_press=on_press) as listener: listener.join()

在Streamlit主应用中，可以添加一个组件定期检查剪贴板（或通过WebSocket接收消息），一旦发现新的扫码内容，就自动触发查询菜品并添加到订单的操作。这样就实现了“即扫即加”的无感体验。

注意事项：硬件选择的坑

1. 扫码枪兼容性：确保扫码枪支持输出“回车键结束”。有些扫码枪需要手动配置。购买前最好咨询卖家或查阅说明书。
2. 树莓派电源：使用官方电源或质量可靠的5V/3A电源。供电不足会导致树莓派运行不稳定，尤其是在接入USB设备时。
3. 散热：如果树莓派持续运行，建议加装散热片或小风扇，避免因过热降频导致应用卡顿。
4. 网络：确保树莓派连接到稳定网络。如果你需要在其他设备（如平板、手机）上访问收银界面，需要知道树莓派的IP地址，并在Streamlit启动命令中设置--server.address 0.0.0.0以允许局域网访问。

5. 避坑指南与进阶思考

在开发和使用这个系统的过程中，我遇到了不少问题，也总结出一些让系统更健壮、更“聪明”的经验。

5.1 数据安全与备份

虽然是个个人项目，但数据无价。尤其是积累了几个月的销售和成本数据后。

• 自动备份：写一个简单的Shell脚本，用cron定时任务每天凌晨备份SQLite数据库文件到另一个硬盘或云存储（如用rclone同步到个人网盘）。

  # 示例备份脚本 /home/pi/backup_db.sh #!/bin/bash BACKUP_DIR="/home/pi/db_backups" DATE=$(date +%Y%m%d_%H%M%S) cp /home/pi/cashier-robot/data/app.db "$BACKUP_DIR/app.db.backup_$DATE" # 可选：删除7天前的备份 find $BACKUP_DIR -name "*.backup_*" -mtime +7 -delete

  然后在crontab中添加：0 2 * * * /bin/bash /home/pi/backup_db.sh

• SQLite的并发写入：SQLite在多个进程同时写入时可能会报database is locked错误。我的系统主要是单用户操作（我自己），Streamlit前端和FastAPI后端通常在同一进程，问题不大。但如果未来考虑多终端同时操作，需要考虑：

  1. 使用更专业的数据库如PostgreSQL。
  2. 在应用层做好请求队列，避免短时间内的密集写操作。
  3. 使用SQLite的WAL（Write-Ahead Logging）模式，可以在一定程度上改善并发读写的性能（在连接数据库时添加参数?mode=rwc&cache=shared并启用WAL）。

5.2 成本计算的准确性

这是“美食家”系统的精髓，也是难点。我的cost_ingredients里记录的用量是固定的，但原料采购价是波动的。

• 成本计算策略：

  1. 最近采购价法：计算成本时，取该原料最近一次的采购单价。简单，但可能不准确（如果最近一次买贵了）。
  2. 加权平均法：成本单价 = (当前库存总价值) / (当前库存总量)。每次采购入库时，重新计算该原料的库存总价值和总量。这种方法更符合会计原则，能平滑价格波动。实现起来稍复杂，需要在采购入库和库存消耗时都更新原料的加权平均单价和库存总价值字段。
  3. 标准成本法：为每个原料设定一个“标准成本价”，定期（如每季度）根据市场情况调整。用于内部核算和定价参考，与实际采购价分离。

  我目前采用的是加权平均法，因为它最能反映真实的物料成本流动。在ingredients表中，我增加了total_cost（库存总成本）和avg_unit_cost（加权平均单价）字段。每次采购入库和订单消耗时，都触发一个函数来重新计算这两个值。

5.3 扩展性思考：这个“机器人”还能做什么？

这个项目的基础框架搭建好后，有很多可以延伸的方向：

• 客户关系管理（迷你CRM）：为常客建立档案，记录其口味偏好（如“不要香菜”、“喜欢偏辣”）、消费历史。在结账时自动弹出备注，提升服务体验。甚至可以集成简单的积分或充值系统。
• 与智能硬件联动：通过树莓派的GPIO接口连接一个小 thermal printer（热敏打印机），自动打印订单小票或厨房出菜单。连接一个称重传感器，用于原料入库时的自动称重记录。
• 食谱与销售联动分析：分析哪些食谱的菜品更受欢迎，哪些原料在多个畅销菜品中出现，从而指导食谱研发和原料采购计划。
• 数据可视化大屏：在厨房或工作室放一个旧平板，实时显示今日销售额、最畅销菜品、库存预警信息，让数据驱动运营。

这个“美食家程序员的收银机器人”项目，始于一个微小的个人需求，最终成长为一个能够切实提升我的美食项目管理和运营效率的工具。它证明了，用程序员的思维去解构生活或工作中的问题，用合适的工具将想法实现，所能带来的满足感和实用价值，远超仅仅使用一个现成的、与自己格格不入的软件。它不完美，但完全贴合我的需求，并且随着我的需求变化，它可以被我随时调整和扩展——这，或许就是“程序员自给自足”的乐趣所在。如果你也有类似的跨界兴趣，不妨从一个小点开始，动手搭建属于你自己的“机器人”。