搞定饮料自动售卖机源码,面试必问的3个致命坑
刚学完循环和变量，是不是感觉手握屠龙刀？一上项目就露馅，尤其是做饮料自动售卖机这种经典练手题，逻辑一绕就崩。
这是面试必问的基础题，也是检验你学会语法却不知怎么搭项目能力的试金石。别以为这是玩具题，大厂笔试、中小厂初面，经常用它来考察状态管理和异常处理。
很多学员卡在同一个地方：代码跑通了，但稍微改点需求就炸，或者面试时被问“为什么不用全局变量”就哑火。
今天不灌鸡汤，直接拆解我踩过的三个大坑，附带官方源码仓库级别的严谨写法，帮你把这块短板补死。
坑一：状态机混乱，余额与库存不同步
现象
用户投币1元，买可乐（2元），提示余额不足。但此时再投1元，突然提示“购买成功”，扣款却只扣了1元，或者库存没减。更可怕的是，多次操作后，机器显示的剩余库存是负数。
根本原因
大多数新手习惯用多个布尔值（isPaid, hasStock）或分散的变量（coin1, coin5）来记录状态。这种写法看似简单，实则是在维护一个非原子性的状态集合。当多个条件交叉判断时，逻辑漏洞必然出现。
正确写法对比
错误写法（散落的状态）：
# 错误示范：状态分散，极易出错
balance = 0
stock_cola = 10
is_vending = False
def insert_coin(amount):
global balance
balance += amount
def buy_drink():
global balance, stock_cola, is_vending
price = 2
if balance = price:
if stock_cola 0:
# 这里逻辑很危险，如果并发操作，或者中间报错，状态就不一致了
balance -= price
stock_cola -= 1
is_vending = True
print(饮料出来了)
else:
print(没货了)
else:
print(钱不够)
正确写法（单一状态源 + 封装）：
# 正确示范：使用类封装状态，确保一致性
class VendingMachine:
def __init__(self, stock, price):
self.stock = stock
self.price = price
self.balance = 0 # 内部状态，外部不可直接修改
def insert_coin(self, amount):
if amount = 0:
raise ValueError(金额必须大于0)
self.balance += amount
def buy(self):
# 原子性检查：同时判断余额和库存
if self.balance = self.price and self.stock 0:
self.balance -= self.price
self.stock -= 1
return 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') * 10
if 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):
pass
def 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(fTransaction failed: {str(e)})
return {success: False, message: str(e)}
except Exception as e:
# 捕获所有未知异常，防止进程崩溃
log.critical(fUnexpected 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/目录下的测试用例，那才是工程思维的体现。
总-分-总回顾
状态管理：用类封装，拒绝全局变量，保证原子性。
金额计算：用整数（分）或Decimal，拒绝float。
异常处理：全量捕获，事务一致性，超时控制。
这三个点，是面试必问的底层逻辑。学会语法只是入场券，懂得如何构建健壮、可维护的系统，才是你从“码农”进阶为“工程师”的分水岭。
你更常用哪种写法处理金额？是习惯用BigDecimal/Decimal，还是坚持用“分”做整数运算？评论区交流，看看大家的实战经验。 
长河君 · 2026/9/22 11:56:00 · 阅读 1.2k 搞定饮料自动售卖机源码,面试必问的3个致命坑
搞定饮料自动售卖机源码,面试必问的3个致命坑
刚学完循环和变量，是不是感觉手握屠龙刀？一上项目就露馅，尤其是做饮料自动售卖机这种经典练手题，逻辑一绕就崩。
这是面试必问的基础题，也是检验你学会语法却不知怎么搭项目能力的试金石。别以为这是玩具题，大厂笔试、中小厂初面，经常用它来考察状态管理和异常处理。
很多学员卡在同一个地方：代码跑通了，但稍微改点需求就炸，或者面试时被问“为什么不用全局变量”就哑火。
今天不灌鸡汤，直接拆解我踩过的三个大坑，附带官方源码仓库级别的严谨写法，帮你把这块短板补死。
坑一：状态机混乱，余额与库存不同步
现象
用户投币1元，买可乐（2元），提示余额不足。但此时再投1元，突然提示“购买成功”，扣款却只扣了1元，或者库存没减。更可怕的是，多次操作后，机器显示的剩余库存是负数。
根本原因
大多数新手习惯用多个布尔值（isPaid, hasStock）或分散的变量（coin1, coin5）来记录状态。这种写法看似简单，实则是在维护一个非原子性的状态集合。当多个条件交叉判断时，逻辑漏洞必然出现。
正确写法对比
错误写法（散落的状态）：
# 错误示范：状态分散，极易出错
balance = 0
stock_cola = 10
is_vending = False
def insert_coin(amount):
global balance
balance += amount
def buy_drink():
global balance, stock_cola, is_vending
price = 2
if balance = price:
if stock_cola 0:
# 这里逻辑很危险，如果并发操作，或者中间报错，状态就不一致了
balance -= price
stock_cola -= 1
is_vending = True
print(饮料出来了)
else:
print(没货了)
else:
print(钱不够)
正确写法（单一状态源 + 封装）：
# 正确示范：使用类封装状态，确保一致性
class VendingMachine:
def __init__(self, stock, price):
self.stock = stock
self.price = price
self.balance = 0 # 内部状态，外部不可直接修改
def insert_coin(self, amount):
if amount = 0:
raise ValueError(金额必须大于0)
self.balance += amount
def buy(self):
# 原子性检查：同时判断余额和库存
if self.balance = self.price and self.stock 0:
self.balance -= self.price
self.stock -= 1
return 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') * 10
if 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):
pass
def 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(fTransaction failed: {str(e)})
return {success: False, message: str(e)}
except Exception as e:
# 捕获所有未知异常，防止进程崩溃
log.critical(fUnexpected 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/目录下的测试用例，那才是工程思维的体现。
总-分-总回顾
状态管理：用类封装，拒绝全局变量，保证原子性。
金额计算：用整数（分）或Decimal，拒绝float。
异常处理：全量捕获，事务一致性，超时控制。
这三个点，是面试必问的底层逻辑。学会语法只是入场券，懂得如何构建健壮、可维护的系统，才是你从“码农”进阶为“工程师”的分水岭。
你更常用哪种写法处理金额？是习惯用BigDecimal/Decimal，还是坚持用“分”做整数运算？评论区交流，看看大家的实战经验。