搞定饮料自动售卖机源码,面试必问的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 Successelif self.stock = 0:return Out of Stockelse: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(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，还是坚持用“分”做整数运算？评论区交流，看看大家的实战经验。
搞定饮料自动售卖机源码,面试必问的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 Successelif self.stock = 0:return Out of Stockelse: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(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，还是坚持用“分”做整数运算？评论区交流，看看大家的实战经验。
