搞定饮料自动售卖机源码,面试必问的3个致命坑

刚学完循环和变量，是不是感觉手握屠龙刀？一上项目就露馅，尤其是做饮料自动售卖机这种经典练手题，逻辑一绕就崩。

这是面试必问的基础题，也是检验你学会语法却不知怎么搭项目能力的试金石。别以为这是玩具题，大厂笔试、中小厂初面，经常用它来考察状态管理和异常处理。

很多学员卡在同一个地方：代码跑通了，但稍微改点需求就炸，或者面试时被问“为什么不用全局变量”就哑火。

今天不灌鸡汤，直接拆解我踩过的三个大坑，附带官方源码仓库级别的严谨写法，帮你把这块短板补死。

坑一：状态机混乱，余额与库存不同步

现象用户投币1元，买可乐（2元），提示余额不足。但此时再投1元，突然提示“购买成功”，扣款却只扣了1元，或者库存没减。更可怕的是，多次操作后，机器显示的剩余库存是负数。

根本原因 大多数新手习惯用多个布尔值（isPaid, hasStock）或分散的变量（coin1, coin5）来记录状态。这种写法看似简单，实则是在维护一个非原子性的状态集合。当多个条件交叉判断时，逻辑漏洞必然出现。

正确写法对比

错误写法（散落的状态）：

# 错误示范：状态分散，极易出错
balance = 0
stock_cola = 10
is_vending = Falsedef insert_coin(amount):global balancebalance += amountdef buy_drink():global balance, stock_cola, is_vendingprice = 2if balance >= price:if stock_cola > 0:# 这里逻辑很危险，如果并发操作，或者中间报错，状态就不一致了balance -= pricestock_cola -= 1is_vending = Trueprint("饮料出来了")else:print("没货了")else:print("钱不够")

正确写法（单一状态源 + 封装）：

# 正确示范：使用类封装状态，确保一致性
class VendingMachine:def __init__(self, stock, price):self.stock = stockself.price = priceself.balance = 0  # 内部状态，外部不可直接修改def insert_coin(self, amount):if amount <= 0:raise ValueError("金额必须大于0")self.balance += amountdef buy(self):# 原子性检查：同时判断余额和库存if self.balance >= self.price and self.stock > 0:self.balance -= self.priceself.stock -= 1return "Success"elif self.stock <= 0:return "Out of Stock"else:return "Insufficient Funds"

复现与修复 在错误写法中，如果你手动修改balance而不经过insert_coin，或者在buy_drink执行到一半时中断，状态就会脏掉。修复方案是：永远不要直接修改内部状态，所有变更必须通过受控的方法进行。

规避建议

拒绝全局变量：将相关状态封装在对象中。
原子操作：判断条件和执行动作要紧密耦合，中间不要插入可能失败的操作。
防御性编程：对输入金额做校验，防止负数或0注入。

坑二：浮点数精度陷阱，钱算不准

现象投币0.1元，投10次，余额显示0.9999999999999999元。买1元饮料时，提示余额不足。或者，退款时算出的零头是0.0999999元，而不是0.1元。

根本原因 计算机二进制无法精确表示某些十进制小数（如0.1, 0.2）。0.1 + 0.2 != 0.3 是IEEE 754双精度浮点数的固有特性。在金融计算中，严禁直接使用float类型处理金额。

正确写法对比

错误写法（使用浮点数）：

# 错误示范：浮点数精度丢失
price = 2.5
inserted = 0.1 * 10  # 实际结果是 0.9999999999999999
if inserted >= price:print("支付成功")
else:print("钱不够") # 会进入这个分支，因为 0.999... < 2.5 是假，但如果是1元饮料呢？# 更典型的坑：
a = 0.1 + 0.2
b = 0.3
print(a == b) # False

正确写法（使用整数分或Decimal）：

# 正确示范1：将所有金额转换为“分”作为整数处理（推荐，性能最好）
price_cents = 250  # 2.50元
inserted_cents = 10 * 10  # 0.1元 * 10次 = 100分if inserted_cents >= price_cents:print("支付成功")
else:print("钱不够")# 正确示范2：使用Decimal库（适合需要高精度小数运算的场景）
from decimal import Decimal, getcontext
getcontext().prec = 50 # 设置精度price_dec = Decimal('2.50')
inserted_dec = Decimal('0.10') * 10if inserted_dec >= price_dec:print("支付成功")

复现与修复 在JavaScript中，0.1 + 0.2 同样等于 0.30000000000000004。如果前端用JS计算价格，后端用Python校验，两边对不上就会出Bug。修复方案是：全链路统一使用“分”作为最小单位进行整数运算，仅在展示层转换为元。

规避建议

金额单位：内部存储和计算一律用“分”（整数）。
展示层转换：(amount / 100).toFixed(2) 格式化输出。
库选择：Python用Decimal，Java用BigDecimal，JS用BigInt或专门的货币库。
测试用例：必须包含边界值测试，如0.1、0.2、0.7等易出精度问题的数字。

坑三：异常处理缺失，机器“卡死”

现象用户投币时，机器断电重启，余额丢失。或者，用户选择“退款”，但退款接口超时，程序抛出未捕获异常，导致整个售卖机进程崩溃，后续用户无法投币。

根本原因 新手代码往往只有“快乐路径”（Happy Path）逻辑，即假设一切正常。没有考虑网络超时、硬件故障、非法输入等异常场景。缺少幂等性设计和事务回滚机制。

正确写法对比

错误写法（无异常处理）：

# 错误示范：裸奔代码
def process_transaction(user_input):if user_input['action'] == 'buy':# 假设这里调用支付网关，可能超时payment_result = call_payment_gateway(user_input['amount'])if payment_result['status'] == 'success':dispense_drink()else:print("支付失败")elif user_input['action'] == 'refund':# 假设这里调用退款接口call_refund_api(user_input['order_id'])

正确写法（异常捕获 + 状态恢复）：

# 正确示范：健壮性处理
class TransactionError(Exception):passdef process_transaction(user_input, db):try:if user_input['action'] == 'buy':# 1. 先锁库存（防止超卖）with db.lock_stock():if db.stock <= 0:raise TransactionError("库存不足")# 2. 调用支付（设置超时时间）try:payment_result = call_payment_gateway(user_input['amount'], timeout=5)except TimeoutError:# 支付超时，不扣库存，提示用户重试raise TransactionError("支付超时，请重试")if payment_result['status'] != 'success':raise TransactionError("支付被拒绝")# 3. 支付成功，扣库存，记录订单db.decrement_stock()db.create_order(user_input)dispense_drink()elif user_input['action'] == 'refund':# 退款也是事务，必须保证要么成功，要么回滚with db.transaction():order = db.get_order(user_input['order_id'])if not order or order.status != 'paid':raise TransactionError("订单状态异常")try:call_refund_api(user_input['order_id'], timeout=5)except Exception as e:# 退款失败，保持订单状态为paid，等待人工介入raise TransactionError(f"退款失败: {str(e)}")db.update_order_status(user_input['order_id'], 'refunded')except TransactionError as e:# 记录日志，返回友好错误信息log.error(f"Transaction failed: {str(e)}")return {"success": False, "message": str(e)}except Exception as e:# 捕获所有未知异常，防止进程崩溃log.critical(f"Unexpected error: {str(e)}")return {"success": False, "message": "系统繁忙，请稍后"}

复现与修复 模拟支付网关超时：在call_payment_gateway中sleep(10)，设置超时为5秒。错误代码会挂起或崩溃，正确代码会捕获TimeoutError，提示用户，且库存不被错误扣除。

规避建议

全量捕获：外层必须有try-except，确保进程不崩溃。
事务一致性：库存扣减、订单创建、支付确认必须在同一事务或补偿机制下。
超时控制：所有外部调用（网络、硬件）必须设置超时。
幂等性：退款、支付接口要支持幂等，防止重复扣款或退款。

进阶：面试加分项与薪资真相

讲完坑，聊点实际的。很多培训机构学员问我：“做这种小项目，能拿多少钱？”

薪资区间与地区差异

一线城市（北上广深）：初级后端/全栈，若能在面试中清晰讲出上述三个坑的解决方案，薪资起步通常在12k-18k。若能结合Redis做分布式锁、结合消息队列做异步处理，薪资可冲击20k+。
二线城市（杭宁汉武）：起步8k-12k。重点考察基础扎实程度，异常处理和精度问题是必查项。
培训机构选择避坑：
- 避坑1：只教语法，不教工程化。如果你的课程里，售卖机项目没有try-catch，没有日志记录，没有单元测试，直接pass。
- 避坑2：项目过于简单。如果项目只是input和print，没有任何架构设计（如分层、接口抽象），说明培训质量低。
- 避坑3：忽视“为什么”。只会背代码，说不出为什么用整数存金额、为什么用状态机，面试必挂。

官方源码仓库参考 建议去GitHub搜索vending-machine标签下Star数较高的项目（如github.com/nickelc/vending-machine或类似开源实现）。观察它们如何处理并发、如何设计API、如何记录日志。不要只盯着main.py，要看test/目录下的测试用例，那才是工程思维的体现。

总-分-总回顾