企业官网建设流程全解析

1. 项目概述：当树莓派遇上区块链，一台自动售货机的技术新生

几年前，我在一个老旧社区里看到一台自动售货机，它只接受硬币，屏幕昏暗，货道还经常卡住。当时我就在想，这玩意儿的技术是不是还停留在上个世纪？如今，物联网和数字支付早已渗透生活，但很多线下实体设备，尤其是像自动售货机这类“重资产、长周期”的设备，其升级换代却异常缓慢。成本、兼容性、维护复杂度，都是横在面前的坎。于是，一个想法冒了出来：能不能用最普及、最灵活的开源硬件树莓派（Raspberry Pi），结合当下热门的区块链支付技术，打造一台成本可控、功能现代且极具探索乐趣的智能售货机？这个项目，就是“Raspberry Pi Smart Vending Machine with Blockchain Payments”的由来。

这不仅仅是一个简单的DIY玩具。它触及了几个非常实在的痛点：传统售货机支付方式单一（尤其对小额加密货币支付不友好）、交易数据不透明且易于篡改、设备状态远程管理困难、以及软硬件耦合度过高导致的升级壁垒。用树莓派作为核心控制器，意味着你可以用Python等高级语言自由编程，连接各种传感器和执行器，轻松实现货道控制、库存管理、甚至人脸识别等AI功能。而引入区块链支付，并非为了噱头，它真正解决了小额、高频、去信任化交易的需求——用户扫码支付，交易通过智能合约自动确认并触发出货，整个过程无需第三方支付机构介入，交易记录在链上永久可查，对运营方和消费者都提供了更高的透明度和信任基础。

无论你是一名嵌入式开发爱好者，想深入学习树莓派GPIO控制、传感器集成和网络通信；还是一名区块链应用开发者，渴望探索智能合约与实体硬件如何交互；亦或是一个创客，想打造一个炫酷又实用的项目，这个项目都能为你提供一个完整的实践闭环。它涵盖了从硬件选型、电路搭建、嵌入式编程，到后端服务开发、区块链智能合约编写、前后端交互的全栈技能点。接下来，我将拆解整个项目的设计思路、核心模块的实现细节，并分享我在搭建过程中踩过的坑和总结的经验，希望能给你带来一个清晰、可复现的构建指南。

2. 整体系统架构与核心设计思路

在动手焊接第一根线之前，我们必须把整个系统的蓝图规划清楚。一台智能售货机，核心无外乎“收钱”和“出货”两件事。但要让它们智能、可靠地协同工作，就需要一个清晰的架构。

2.1 硬件层：树莓派作为“智慧大脑”与“协调中枢”

树莓派在这里扮演绝对的核心角色。它不再是一个简单的微型电脑，而是整台售货机的“智慧大脑”和“协调中枢”。我选择树莓派4B 4GB版本，主要基于以下几点考量：

1. 算力充足：相比旧型号，4B的CPU和内存足以流畅运行一个轻量级的Linux系统（如Raspberry Pi OS Lite）、Python后端服务、以及可能需要的简单图像识别程序（比如用OpenCV做商品识别防偷盗）。
2. 丰富的IO接口：40针的GPIO排针是连接外部世界的桥梁。我们将通过它来控制步进电机（驱动货道螺旋杆）、读取红外光电传感器（检测货物是否掉落）、连接温湿度传感器（监控机内环境）等。
3. 稳定的网络连接：双频Wi-Fi和千兆有线网口保证了设备能够7x24小时稳定在线，这是实现远程监控、接收区块链交易通知的前提。
4. 成本与生态平衡：树莓派的价格和其庞大的社区生态，使得寻找解决方案和排查问题变得非常容易。

硬件清单与选型理由：

• 主控：Raspberry Pi 4B (4GB RAM)。2GB版本也够用，但4GB为未来功能留有余地。
• 电机驱动模块：我选用的是DRV8825步进电机驱动板，搭配42步进电机。为什么是步进电机而不是普通的直流电机？因为售货机的货道（尤其是弹簧螺旋货道）需要精确的角度控制，以推动商品恰好掉落到取货口。DRV8825支持微步进，运行更平稳，噪音更小，且树莓派通过GPIO发送脉冲即可精确控制其转动步数。
• 传感器：
  • 红外对射传感器：安装在每个货道的出货口下方。当货物掉落穿过光束时，会产生一个电平跳变信号，树莓派检测到这个信号即可确认“出货成功”。这是实现交易闭环、防止纠纷的关键反馈。
  • DHT22温湿度传感器：安装在机箱内部。用于监测环境，如果温度过高（可能因压缩机故障或散热不良），可自动向管理后台发送警报。
• 电源管理：这是一个极易被忽视但至关重要的部分。树莓派需要稳定的5V/3A供电，而多个步进电机在启动瞬间电流很大。绝对禁止直接用树莓派的GPIO（5V引脚）给电机供电！我的方案是使用一个独立的12V/5A开关电源。12V直接供给电机驱动板，同时通过一个DC-DC降压模块（如LM2596）将12V转为稳定的5V，单独给树莓派供电。两者共地即可。
• 其他：7英寸触摸屏（用于显示商品信息和生成支付二维码）、继电器模块（如需控制照明灯或压缩机）、机箱、货道等机械结构件。

2.2 软件与网络层：四层分离的松耦合设计

为了让系统易于维护和扩展，我采用了典型的四层分离设计：

1. 设备控制层（运行在树莓派上）：这是最底层的固件。我用Python的RPi.GPIO库编写了核心控制脚本。它负责：
   • 初始化所有GPIO引脚。
   • 提供基础的函数：drive_motor(channel, steps)（驱动指定货道电机转动若干步）、check_sensor(channel)（读取指定传感器的状态）。
   • 监听一个本地Socket服务或HTTP端点，等待来自上层应用的指令。
2. 业务服务层（可运行在树莓派或云端）：这一层用Python（Flask/Django）或Node.js实现，是业务逻辑的核心。它负责：
   • 商品管理（库存、价格）。
   • 接收来自前端的购买请求。
   • 生成支付订单（包括金额、唯一订单号）。
   • 调用区块链交互层的接口创建收款地址或支付二维码。
   • 在确认支付后，向设备控制层发送“出货”指令。
   • 记录交易日志（本地数据库，如SQLite）。
3. 区块链交互层：这是连接现实世界与链上世界的桥梁。我们不直接在树莓派上运行一个全节点（存储压力太大）。而是采用两种更轻量的方式：
   • 方案A：使用第三方节点服务API：例如Infura（对于以太坊）、QuickNode等。业务服务层通过它们的HTTP API来创建钱包地址、查询交易状态、监听交易事件。这是最快上手的方案。
   • 方案B：运行一个轻节点或使用SDK：例如，对于比特币可以使用bitcoinlib，对于以太坊可以使用web3.py连接到一个你信任的远程节点。这种方式自主性更强，但需要对相应区块链的RPC接口有一定了解。
   • 本项目中，我选择方案A，因为它更稳定，无需关心节点同步问题。
4. 智能合约层（部署在区块链上）：这是区块链部分的灵魂。我们编写一个简单的售货机智能合约（以Solidity为例，假设部署在以太坊测试网），其主要功能是：
   • 接收用户的付款。
   • 验证付款金额是否与商品价格匹配。
   • 在付款成功后，触发一个PaymentReceived事件，事件中包含订单号、金额、买家地址等信息。
   • 业务服务层会持续监听这个事件。一旦监听到与本地订单匹配的事件，就判定为支付成功，继而触发出货流程。
5. 用户交互层：
   • 前端界面：一个简单的React或Vue网页，内嵌在树莓派的触摸屏浏览器中全屏显示。展示商品图片、价格、库存，并生成一个包含支付地址和金额信息的二维码（比如一个标准的加密货币支付URI：ethereum:0x...?value=...）。
   • 用户手机钱包：用户使用MetaMask、Trust Wallet等扫码并确认支付。

注意：支付确认的时效性。区块链网络存在确认延迟（从几秒到几分钟不等）。我们的业务逻辑必须处理“支付中”状态，并设置一个合理的等待超时时间（例如2分钟）。超时后，订单自动取消，前端提示用户支付未完成。

2.3 为什么选择区块链支付？与传统方案的对比

你可能会问，微信/支付宝扫码支付不香吗？确实方便，但在这个项目中，区块链支付有其独特的优势和应用场景：

• 降低接入门槛与成本：接入官方微信/支付宝支付需要企业资质、签订合同、缴纳费率，对于个人开发者或小规模实验性项目门槛较高。而区块链支付，你只需要一个钱包地址和对应的智能合约即可开始收款，几乎是零门槛。
• 全球化与隐私性：加密货币支付天生无国界，适合部署在跨国场景（如机场、国际社区）。同时，它保护了消费者的支付隐私（虽然交易记录公开，但地址与真实身份可脱钩）。
• 交易透明与不可篡改：所有交易记录在链上公开可查，运营方无法篡改销售数据，这对于加盟分账或审计场景非常有价值。消费者也可以验证自己的交易。
• 探索与教育价值：这是最重要的。本项目是一个绝佳的“区块链赋能物联网”的案例，能让你亲手实践Web3与物理世界的交互。

当然，它也有明显缺点：支付速度受网络拥堵影响、加密货币价格波动风险、用户需要预先拥有加密货币并熟悉钱包操作。因此，这个项目更适合作为技术验证、特定社区内部使用或对新技术有需求的场景。

3. 核心模块实现与实操要点

理论讲完，我们进入硬核的实操环节。我会分模块讲解关键代码和接线，并附上我踩坑后总结的注意事项。

3.1 树莓派GPIO控制与电机驱动

这是硬件部分最核心的调试环节。目标是实现通过Python程序，精准控制一个货道的电机旋转指定圈数，并等待传感器反馈。

接线示意图（一个货道为例）：

树莓派 GPIO12 (PWM0) -> DRV8825 STEP 树莓派 GPIO16 -> DRV8825 DIR 树莓派 GND -> DRV8825 GND 外部12V电源+ -> DRV8825 VMOT 外部12V电源- -> DRV8825 GND (与树莓派GND共地) DRV8825 A1, A2 -> 步进电机线圈A DRV8825 B1, B2 -> 步进电机线圈B 树莓派 GPIO18 -> 红外传感器OUT 树莓派 3.3V -> 红外传感器VCC 树莓派 GND -> 红外传感器GND

Python控制代码片段：

import RPi.GPIO as GPIO import time class VendingMotor: def __init__(self, step_pin, dir_pin, sensor_pin): self.step_pin = step_pin self.dir_pin = dir_pin self.sensor_pin = sensor_pin GPIO.setmode(GPIO.BOARD) # 使用物理引脚编号 GPIO.setup(self.step_pin, GPIO.OUT) GPIO.setup(self.dir_pin, GPIO.OUT) GPIO.setup(self.sensor_pin, GPIO.IN, pull_up_down=GPIO.PUD_UP) # 启用上拉电阻 # DRV8825 细分数设置（通过硬件跳线），这里假设是1/4步进 self.steps_per_revolution = 200 * 4 # 200是电机固有步数，4是细分数 self.delay = 0.001 # 步进间隔，控制速度 def drive_and_check(self, channel, revolutions): """驱动指定货道电机转动，并等待传感器反馈""" # 设置方向，例如GPIO.HIGH为正转（出货） GPIO.output(self.dir_pin, GPIO.HIGH) steps_needed = int(self.steps_per_revolution * revolutions) print(f"驱动货道{channel}，转动{revolutions}圈，共{steps_needed}步") # 发送脉冲序列 for _ in range(steps_needed): GPIO.output(self.step_pin, GPIO.HIGH) time.sleep(self.delay) GPIO.output(self.step_pin, GPIO.LOW) time.sleep(self.delay) # 等待传感器触发，设置超时（例如5秒） timeout = time.time() + 5 while GPIO.input(self.sensor_pin) == GPIO.HIGH: # 假设传感器触发时为LOW if time.time() > timeout: print(f"警告：货道{channel}出货传感器未在5秒内触发！") return False # 出货失败 time.sleep(0.01) print(f"货道{channel}出货成功确认！") return True # 出货成功 # 使用示例 motor_ch1 = VendingMotor(step_pin=12, dir_pin=16, sensor_pin=18) success = motor_ch1.drive_and_check(channel=1, revolutions=2.5) # 转动2.5圈

实操心得与避坑指南：

1. 电源隔离与共地：重申一遍，电机电源和树莓派电源一定要隔离（分别供电），但两者的“地”（GND）必须连接在一起，否则控制信号无法形成回路。这是导致电机不转或乱转的最常见原因。
2. 电流与细分设置：DRV8825需要通过电位器调节输出电流，匹配你的电机额定电流（通常42电机在1A左右）。电流太小电机无力，太大会发热严重。细分数通过模块上的跳线帽设置，更高的细分（如1/8，1/16）运行更平稳安静，但单位转动的步数也越多，需要调整代码中的steps_per_revolution。
3. 传感器防抖动：红外传感器在触发时可能会产生机械抖动，导致GPIO读到多个跳变。除了硬件上可以加滤波电容，软件上需要做“防抖”处理。一个简单的方法是检测到低电平后，延时10-50毫秒再次检测，如果仍是低电平才认为是有效触发。
4. 异常处理与日志：drive_and_check函数必须包含超时逻辑。如果电机转了但商品卡住没掉下来，传感器永远等不到信号，程序就会死锁。超时后要记录错误，并可能触发一个“重新尝试”或“上报故障”的流程。所有操作都应记录日志，方便后期排查。

3.2 区块链支付集成：智能合约与后端监听

这是项目的另一个核心。我们以以太坊测试网（如Goerli）为例，使用web3.py库与智能合约交互。

第一步：编写并部署智能合约

// SPDX-License-Identifier: MIT pragma solidity ^0.8.0; contract SimpleVending { // 事件：当收到付款时触发 event PaymentReceived( bytes32 indexed orderId, address indexed buyer, uint256 amount, uint256 timestamp ); // 接收ETH的fallback函数 receive() external payable { // 在这个简单版本中，我们假设任何付款都有效。 // 实际应用中，应该验证金额并映射到订单。 emit PaymentReceived(0, msg.sender, msg.value, block.timestamp); } // 一个更安全的函数，允许指定订单ID（前端生成） function payForOrder(bytes32 _orderId) external payable { require(msg.value > 0, "Payment must be greater than 0"); emit PaymentReceived(_orderId, msg.sender, msg.value, block.timestamp); } // 合约拥有者可以提取资金（在实际项目中，可能需要多签或定时提取） function withdraw(address payable _to, uint256 _amount) external { require(msg.sender == owner, "Only owner can withdraw"); _to.transfer(_amount); } }

使用Remix IDE或Hardhat框架将合约部署到Goerli测试网，获取合约地址CONTRACT_ADDRESS和ABI接口定义。

第二步：后端服务监听支付事件

from web3 import Web3 import json import time from threading import Thread # 连接到以太坊测试网节点（使用Infura服务） INFURA_URL = "https://goerli.infura.io/v3/YOUR_INFURA_PROJECT_ID" web3 = Web3(Web3.HTTPProvider(INFURA_URL)) # 加载合约ABI和地址 with open('SimpleVending.json') as f: contract_abi = json.load(f) CONTRACT_ADDRESS = Web3.toChecksumAddress('0xYourDeployedContractAddress') vending_contract = web3.eth.contract(address=CONTRACT_ADDRESS, abi=contract_abi) # 存储待处理的订单。键为订单ID，值为订单信息（商品、金额等） pending_orders = {} def listen_to_payments(): """在一个独立线程中监听PaymentReceived事件""" # 创建事件过滤器 payment_event_filter = vending_contract.events.PaymentReceived.createFilter(fromBlock='latest') print("开始监听区块链支付事件...") while True: try: # 轮询新的事件 for event in payment_event_filter.get_new_entries(): handle_payment_event(event) time.sleep(5) # 每5秒检查一次，避免请求过于频繁 except Exception as e: print(f"监听事件时出错: {e}") time.sleep(10) def handle_payment_event(event): """处理支付成功事件""" order_id = event.args.orderId.hex() # 获取订单ID buyer = event.args.buyer amount_wei = event.args.amount amount_eth = web3.fromWei(amount_wei, 'ether') print(f"收到支付！订单ID: {order_id}, 买家: {buyer}, 金额: {amount_eth} ETH") # 1. 检查订单是否存在且未处理 if order_id in pending_orders and not pending_orders[order_id].get('processed'): order = pending_orders[order_id] # 2. 验证支付金额是否匹配订单金额（允许微小误差） expected_wei = web3.toWei(order['price'], 'ether') if abs(amount_wei - expected_wei) < web3.toWei(0.001, 'ether'): # 允许0.001 ETH的误差 # 3. 标记订单为已支付，并触发出货逻辑 order['processed'] = True print(f"订单 {order_id} 支付验证通过，准备出货...") # 调用本地设备控制接口，触发出货 # 例如：requests.post('http://localhost:5000/dispense', json={'channel': order['channel']}) # 出货成功后，从pending_orders中移除该订单 else: print(f"警告：订单 {order_id} 支付金额不匹配。期望{order['price']} ETH，收到{amount_eth} ETH") else: print(f"忽略事件：未找到订单ID {order_id} 或订单已处理") # 启动监听线程 listener_thread = Thread(target=listen_to_payments, daemon=True) listener_thread.start()

关键点解析与避坑指南：

1. 订单ID的生成与传递：为了将链上支付与线下订单关联，必须有一个唯一的订单ID。我建议在后端业务服务创建订单时，使用UUID生成一个唯一的字符串，然后将其哈希（如Web3.keccak(text=order_id)）作为bytes32类型的参数传递给智能合约的payForOrder函数。同时，这个订单ID和商品信息、价格一起保存在后端的pending_orders字典或数据库中。
2. 事件监听的重连与容错：网络是不稳定的。createFilter创建的过滤器可能会失效。在生产环境中，你需要更健壮的监听逻辑，例如使用get_logs配合最新的区块号进行轮询，并处理网络异常后的重连。
3. 金额验证与安全：智能合约中的receive函数是“来者不拒”的，这很危险。更好的做法是让用户调用payForOrder函数，并传入订单ID。后端在生成支付二维码时，构造一个交易调用该函数。同时，后端监听事件后，必须严格比对支付金额与订单金额，防止用户多付或少付（多付可能导致财务损失，少付则不能出货）。
4. 测试网与测试币：在Goerli等测试网上进行开发测试，你需要获取测试ETH。可以通过官方的Goerli水龙头或一些社区水龙头获取。确保你的测试钱包里有足够的测试币来支付交易Gas费。

3.3 业务服务与前端界面搭建

业务服务层（这里用Python Flask为例）负责串联一切。它提供RESTful API给前端，管理订单状态，并调用设备控制接口。

Flask App核心代码结构：

from flask import Flask, request, jsonify, render_template import uuid import qrcode import io import base64 app = Flask(__name__) # 模拟商品数据库 products = { 1: {'name': '可乐', 'price': 0.005, 'stock': 10, 'channel': 1}, # 价格单位：ETH 2: {'name': '矿泉水', 'price': 0.003, 'stock': 15, 'channel': 2}, } # 订单存储（实际应用应使用数据库） orders = {} pending_orders = {} @app.route('/') def index(): """前端主页面""" return render_template('index.html', products=products) @app.route('/api/create_order', methods=['POST']) def create_order(): """创建订单，生成支付信息""" product_id = int(request.json.get('product_id')) if product_id not in products or products[product_id]['stock'] <= 0: return jsonify({'error': '商品无效或库存不足'}), 400 product = products[product_id] # 生成唯一订单ID order_id = str(uuid.uuid4()) # 计算支付金额（以太坊单位：Wei） amount_wei = web3.toWei(product['price'], 'ether') # 构造支付链接（使用ERC-681 URI格式） # 假设合约地址为CONTRACT_ADDRESS，调用payForOrder函数 # 注意：实际二维码内容需要根据钱包支持的格式调整，可能是简单的“地址:金额”，也可能是调用合约的数据 payment_uri = f"ethereum:{CONTRACT_ADDRESS}@5/payForOrder?bytes32={Web3.keccak(text=order_id).hex()}&value={amount_wei}" # 或者更通用的：向合约地址转账，并在memo里备注订单ID（但需要合约能解析memo，更复杂） # 生成二维码图片 qr = qrcode.make(payment_uri) buffered = io.BytesIO() qr.save(buffered, format="PNG") qr_base64 = base64.b64encode(buffered.getvalue()).decode() # 保存订单 order = { 'id': order_id, 'product_id': product_id, 'amount_wei': amount_wei, 'status': 'pending', # pending, paid, dispensed, failed 'created_at': time.time() } orders[order_id] = order pending_orders[order_id] = order # 放入待支付列表，供区块链监听器查询 # 扣减库存（预扣） products[product_id]['stock'] -= 1 return jsonify({ 'order_id': order_id, 'payment_uri': payment_uri, 'qr_code': f"data:image/png;base64,{qr_base64}", 'amount_eth': product['price'] }) @app.route('/api/check_order/<order_id>') def check_order(order_id): """前端轮询检查订单状态""" order = orders.get(order_id) if not order: return jsonify({'error': '订单不存在'}), 404 return jsonify({'status': order['status']}) @app.route('/api/dispense', methods=['POST']) def dispense(): """（内部接口）区块链监听器调用此接口触发出货""" # 应有一个简单的认证，例如验证请求来自localhost或携带密钥 order_id = request.json.get('order_id') channel = request.json.get('channel') # 调用硬件控制模块 success = hardware_driver.dispense_product(channel) if success: orders[order_id]['status'] = 'dispensed' return jsonify({'success': True}) else: orders[order_id]['status'] = 'failed' # 可以考虑触发退款逻辑（需要智能合约支持） return jsonify({'success': False, 'error': '出货失败'}), 500 # 硬件驱动模块的模拟接口 class HardwareDriver: def dispense_product(self, channel): # 这里应该调用实际的GPIO控制函数 print(f"[硬件操作] 驱动货道 {channel} 出货") # 假设调用成功 return True hardware_driver = HardwareDriver() if __name__ == '__main__': # 注意：在生产环境中，应使用生产级WSGI服务器如Gunicorn app.run(host='0.0.0.0', port=5000, debug=True)

前端界面（index.html简化版）： 一个简单的Vue.js单页应用，展示商品列表。用户点击商品后，调用/api/create_order接口，获取支付二维码并显示。同时，前端通过轮询/api/check_order/<order_id>来更新订单状态（“等待支付” -> “支付确认中” -> “出货成功”）。

部署与整合：

1. 将Flask应用、区块链监听脚本、硬件控制脚本整合到树莓派上。可以使用systemd服务来管理它们的启动和守护。
2. 配置树莓派开机自动启动Chromium浏览器，并以Kiosk模式全屏打开你的前端页面。
3. 确保树莓派连接的网络稳定，并且防火墙开放了必要的端口（如Flask应用的5000端口，仅限内网访问即可）。

4. 常见问题、调试技巧与进阶优化

在实际搭建过程中，你一定会遇到各种各样的问题。下面是我在多次调试中总结的“排错清单”和进阶思路。

4.1 硬件与底层控制问题

4.2 区块链与网络通信问题

4.3 软件与业务逻辑问题

• 并发与订单状态竞争：如果多个用户同时购买，需要处理好订单状态的并发修改。对pending_orders字典的访问可能需要进行线程锁（threading.Lock）保护，或者直接使用数据库（如SQLite）的事务机制。
• 支付成功但出货失败：这是最严重的故障，会导致用户付了钱但拿不到商品。除了硬件上做好传感器反馈，软件上必须有补偿或退款机制。例如，当dispense接口返回失败后，业务服务应记录一条需要人工干预的故障单，并尝试调用智能合约的退款函数（如果合约支持）将资金退回用户地址，或者标记该订单为“待人工处理”。
• 前端页面卡死或白屏：树莓派浏览器性能有限。确保前端页面尽可能轻量，避免复杂的动画和JavaScript框架。可以考虑使用纯HTML/CSS加上少量原生JS，或者使用针对嵌入式设备优化的框架。

4.4 进阶优化与扩展思路

当基础功能跑通后，你可以考虑以下方向来完善你的智能售货机：

1. 多区块链支持：除了以太坊，可以集成更快速、手续费更低的区块链，如Polygon、Binance Smart Chain，甚至比特币闪电网络（更适合小额支付）。后端需要适配不同链的RPC接口和监听方式。
2. 状态监控与远程管理：为Flask应用增加一个管理员后台，可以实时查看每个货道的库存、销售数据、设备温度、网络状态等。当库存低于阈值或设备故障时，自动发送邮件或Telegram通知。
3. 商品识别与防损：在取货口加装一个摄像头，结合OpenCV进行简单的图像识别。当传感器触发后，拍照识别掉落的商品是否与订单一致，防止“一瓶可乐的钱掉出两瓶”或者商品卡住的情况。
4. 引入稳定币支付：加密货币价格波动大，可以集成USDC、DAI等稳定币的支付。这需要在智能合约中支持ERC-20代币的转账和验证，复杂度会提高，但用户体验更接近传统支付。
5. 容器化部署：使用Docker将Flask应用、区块链监听器、硬件控制服务分别容器化，通过Docker Compose管理。这能极大简化环境依赖和部署流程。

搭建这样一台基于树莓派和区块链的智能售货机，就像完成了一次小型的全栈工程实践。从拧螺丝、焊线头，到写合约、调API，每一个环节都充满了挑战和乐趣。它可能不会立刻变成一个赚钱的生意，但它带给你的技术视野和解决问题的能力提升，是无可替代的。最让我有成就感的一刻，不是代码第一次跑通，而是当我用手机扫码、确认支付、听到电机转动、可乐“哐当”一声掉出来的那个瞬间——代码与合约，真正驱动了物理世界的运转。希望这份详细的指南，能帮你顺利抵达那个时刻。如果在搭建过程中遇到任何问题，树莓派和区块链的庞大社区，永远是你最好的后盾。