一文搞懂自动贩卖机价格，转行后端别再只会写语法

刚学完 Python 或 Java，是不是觉得代码写得挺溜，一让做项目就抓瞎？ 很多人卡在“知道语法”和“能落地”之间的鸿沟里，连个简单的状态机都设计不好。 今天咱们不聊虚的，直接拿自动贩卖机价格这个经典案例，从零手搓一个后端核心逻辑，让你看懂工程化思维。

项目目标：别只盯着投币，要看状态流转

很多新手一上来就写 if coin > 5 然后 if price > 5，这种代码扩展性极差。 真正的自动贩卖机价格处理，核心不是算钱，而是管理“状态”。 我们要实现的功能很具体：支持多种商品（可乐、薯片、咖啡），不同价格，支持硬币（5分、10分、25分）和纸币（1美元），支持找零，支持退币。

注意，这里的“价格”不是写死的 int，而是一个配置项。 在实际生产中，自动贩卖机价格可能随时调整，甚至根据时间段浮动（比如深夜咖啡涨价）。 所以我们的目标，是构建一个解耦的、可配置的价格处理引擎，而不是硬编码逻辑。

对于转行后端的同学，这个项目能帮你理解：

1. 领域模型：怎么把业务规则抽象成代码对象。
2. 状态机模式：处理复杂业务流程的标准姿势。
3. 测试驱动：怎么保证价格计算不出错，毕竟钱算错了是要赔钱的。

目录结构：工程化思维，拒绝单文件脚本

很多初学者喜欢把所有代码塞在一个 main.py 里，这在面试时是减分项。 我们要用工程化的方式组织代码，模拟真实后端项目的结构。

vending_machine/
├── main.py           # 入口文件，启动逻辑
├── models/
│   ├── __init__.py
│   ├── item.py       # 商品模型，定义名称和价格
│   ├── coin.py       # 货币模型，定义面值
│   └── state.py      # 状态定义
├── core/
│   ├── __init__.py
│   ├── machine.py    # 核心状态机，处理投币、选货、找零
│   └── calculator.py # 价格计算辅助类，处理最小公倍数找零
├── tests/
│   ├── __init__.py
│   └── test_machine.py # 单元测试，覆盖各种价格组合
└── config.json       # 商品配置，实现价格动态加载

这个结构的关键在于分离关注点。 models 层只负责数据结构，core 层负责业务逻辑，config 层负责数据。 当你以后要增加“会员卡折扣”或“促销活动”时，只需要修改 core/calculator.py 和 config.json，完全不用动 machine.py 的主流程。 这种设计思想，才是大厂面试中考察的“可扩展性”。

核心代码实现：逐行拆解价格处理逻辑

1. 定义商品与货币模型

首先，我们定义商品。注意，自动贩卖机价格在模型中应该以“美分”为单位存储，避免浮点数精度问题。这是后端开发的铁律。

# models/item.py
from dataclasses import dataclass@dataclass
class Item:name: strprice_cents: int  # 价格以美分存储，如 2.50 美元存为 250@propertydef price_dollars(self):return self.price_cents / 100

# models/coin.py
from enum import Enumclass CoinType(Enum):PENNY = 1       # 1 centNICKEL = 5      # 5 centsDIME = 10       # 10 centsQUARTER = 25    # 25 centsDOLLAR = 100    # 100 cents

这里为什么用 Enum？ 因为货币类型是固定的、有限的集合。用枚举可以防止用户传入非法的货币类型，比如在编译期或运行时就能拦截错误。 这是 TypeScript 或 Java 开发中常见的最佳实践，Python 中同样适用。

2. 核心状态机：处理价格与余额

这是整个项目的灵魂。我们用一个类来封装所有状态。 重点看 calculate_change 方法，这是处理自动贩卖机价格找零的核心算法。

# core/machine.py
from models.item import Item
from models.coin import CoinType
from typing import Dict, Listclass VendingMachine:def __init__(self, items: List[Item]):self.items = {item.name: item for item in items}self.balance = 0  # 当前用户投入的金额（美分）self.state = "IDLE"  # 初始状态def insert_coin(self, coin_type: CoinType):"""投币，更新余额"""self.balance += coin_type.valueprint(f"投入 {coin_type.name}, 当前余额: ${self.balance/100:.2f}")def select_item(self, item_name: str) -> bool:"""选择商品，校验价格是否足够"""if item_name not in self.items:print("商品不存在")return Falseitem = self.items[item_name]# 核心逻辑：判断余额是否 >= 商品价格if self.balance >= item.price_cents:self._dispense_item(item)self._return_change(item.price_cents)return Trueelse:print(f"余额不足，还差 ${ (item.price_cents - self.balance)/100:.2f }")return Falsedef _dispense_item(self, item: Item):"""出货逻辑，此处简化为打印"""print(f"出货: {item.name}")self.state = "DISPENSED"def _return_change(self, price_cents: int):"""找零逻辑，核心算法"""change = self.balance - price_centsif change > 0:coins = self._calculate_change(coins_cents=change)print(f"找零: {coins}")self.balance = 0self.state = "IDLE"def _calculate_change(self, coins_cents: int) -> Dict[CoinType, int]:"""贪心算法计算最少硬币数注意：这依赖于货币体系的可整除性，如美元体系"""coin_values = [(CoinType.DOLLAR, 100),(CoinType.QUARTER, 25),(CoinType.DIME, 10),(CoinType.NICKEL, 5),(CoinType.PENNY, 1)]result = {}remaining = coins_centsfor coin_type, value in coin_values:count = remaining // valueif count > 0:result[coin_type] = countremaining -= count * valueif remaining == 0:breakreturn result

逐行讲解关键点：

1. self.balance 是核心状态变量。每次投币都累加，每次消费都重置。
2. select_item 中，我们直接用 >= 比较 balance 和 price_cents。这里没有做任何浮点数运算，全是整数比较，速度快且无精度误差。
3. _calculate_change 使用了贪心算法。对于美元、人民币等货币体系，贪心算法总能得到最优解（硬币数量最少）。但如果换成某些特殊货币体系（如某些游戏中的金币），贪心可能失效，需要改用动态规划。
4. 注意 config.json 的存在。我们在 __init__ 中加载商品列表，而不是硬编码。这意味着运营人员可以通过修改 JSON 文件来调整自动贩卖机价格，无需重启服务。

3. 配置驱动：让价格活起来

// config.json
{"items": [{"name": "Cola", "price_cents": 150},{"name": "Chips", "price_cents": 125},{"name": "Coffee", "price_cents": 300}]
}

# main.py
import json
from models.item import Item
from core.machine import VendingMachinedef load_items_from_config(file_path="config.json"):with open(file_path, 'r') as f:data = json.load(f)return [Item(item["name"], item["price_cents"]) for item in data["items"]]def main():items = load_items_from_config()machine = VendingMachine(items)# 模拟用户操作from models.coin import CoinTypemachine.insert_coin(CoinType.QUARTER)  # 25machine.insert_coin(CoinType.QUARTER)  # 25machine.insert_coin(CoinType.DIME)     # 10# 总余额 60 美分machine.select_item("Cola")            # 价格 150 美分，余额不足machine.insert_coin(CoinType.DOLLAR)   # 100 美分# 总余额 160 美分machine.select_item("Cola")            # 价格 150 美分，成功，找零 10

这段代码展示了自动贩卖机价格如何从配置文件流入业务逻辑。 对于转行同学，记住这个模式：数据与逻辑分离。 如果明天可乐涨价到 160 美分，你只需要改 config.json 里的 150 为 160，代码一行不用动。这就是工程化的价值。

运行与测试：用代码证明你的逻辑是对的

很多后端新人不写测试，认为“我运行了一下，没报错就行”。 这是大错特错。价格计算是最容易出错的逻辑，必须用单元测试覆盖边界情况。

# tests/test_machine.py
import unittest
from models.item import Item
from models.coin import CoinType
from core.machine import VendingMachineclass TestVendingMachine(unittest.TestCase):def setUp(self):self.items = [Item("Cola", 150),Item("Chips", 125)]self.machine = VendingMachine(self.items)def test_insufficient_funds(self):"""测试余额不足的情况"""self.machine.insert_coin(CoinType.QUARTER) # 25self.machine.insert_coin(CoinType.QUARTER) # 25self.machine.insert_coin(CoinType.QUARTER) # 25# 总 75 美分，买 150 美分的可乐result = self.machine.select_item("Cola")self.assertFalse(result)self.assertEqual(self.machine.balance, 75) # 余额应保留def test_exact_amount(self):"""测试金额恰好相等的情况"""self.machine.insert_coin(CoinType.QUARTER) # 25self.machine.insert_coin(CoinType.QUARTER) # 25self.machine.insert_coin(CoinType.QUARTER) # 25self.machine.insert_coin(CoinType.QUARTER) # 25self.machine.insert_coin(CoinType.QUARTER) # 25self.machine.insert_coin(CoinType.QUARTER) # 25# 总 150 美分result = self.machine.select_item("Cola")self.assertTrue(result)self.assertEqual(self.machine.balance, 0) # 余额清零# 验证没有找零（此处需 mock 或捕获输出，简化版略）def test_change_calculation(self):"""测试找零逻辑"""# 投入 1 美元 (100)，买 25 美分的薯片self.machine.insert_coin(CoinType.DOLLAR)self.machine.select_item("Chips")# 找零应为 75 美分# 期望: 3 个 QUARTER (25*3=75)# 实际计算结果应在 _calculate_change 中验证# 这里我们假设 _return_change 调用了 _calculate_change# 为了测试，我们可以直接调用 private 方法（不推荐，但在测试中常见）change = self.machine._calculate_change(75)self.assertEqual(change.get(CoinType.QUARTER), 3)self.assertEqual(change.get(CoinType.DIME), 0)

测试要点：

1. 边界值：余额刚好等于价格、余额比价格少 1 分钱。
2. 找零算法：验证不同金额组合下，硬币数量是否正确。
3. 状态重置：交易完成后，balance 是否归零，state 是否回到 IDLE。

在真实项目中，我们会使用 pytest 框架，并添加更多断言。 参考 MDN Web Docs 中关于 JavaScript 数值精度的文章，你会发现浮点数运算在金融场景中是禁忌。我们坚持使用整数（美分）运算，就是为了规避这类风险。这个细节，在面试中提到，会让面试官眼前一亮。

优化扩展：从玩具项目到生产级思考

现在的代码能跑，但离生产环境还差很远。 以下是几个可以优化的方向，也是你在简历中可以写的“亮点”。

1. 并发安全

如果同时有多个用户操作同一台机器（虽然物理上不可能，但逻辑上可能），self.balance 会出现竞态条件。 解决方案：

• 使用 threading.Lock 保护关键区。
• 或者使用数据库事务，将余额存入数据库，每次操作都执行 UPDATE balance = balance + ?，利用数据库的行锁保证原子性。

2. 价格动态调整

目前价格是静态的。如果我们要实现“夜间折扣”，该怎么办？ 解决方案：

• 在 Item 模型中增加 price_rules 字段。
• 在 calculator.py 中实现策略模式，根据当前时间、用户等级等因子计算最终价格。
• 引入“价格版本”概念，每次计算都记录使用的价格版本，便于审计。

3. 异常处理

目前代码假设用户只会投合法硬币。但如果用户投了假币呢？ 解决方案：

• 增加“验币”模块，模拟硬件返回的验证结果。
• 如果验币失败，抛出 InvalidCoinException，并记录日志。
• 所有异常都要被捕获并转化为用户友好的提示，而不是直接崩溃。

4. 日志与监控

• 每次投币、选货、找零都要记录日志，包含时间戳、用户 ID、商品、金额。
• 使用 logging 模块，而不是 print。
• 可以接入 Prometheus 监控，统计“余额不足”的次数，用于优化商品定价。

这些优化点，不需要全部实现，但你需要知道它们。 在面试中，当面试官问“你的项目有什么不足？”时，你能答出“并发安全”、“价格动态调整”、“异常处理”，就证明你具备架构思维，而不仅仅是会写代码。

小结：从语法到工程的跨越

通过这个自动贩卖机价格项目，你应该体会到：

1. 状态管理是后端业务逻辑的核心，状态机模式是解决复杂流程的有力工具。
2. 数据与逻辑分离是工程化的基础，配置驱动让系统更灵活。
3. 整数运算是金融场景的标配，规避浮点数陷阱。
4. 单元测试是代码质量的保障，特别是边界情况。

学会语法只是入场券，能搭出结构清晰、可扩展、可测试的项目，才是你转行后端的真正竞争力。 不要满足于“能跑就行”，要追求“跑得稳、改得动、测得全”。

这个案例虽小，但麻雀虽小五脏俱全。 你可以在此基础上扩展：增加库存管理、增加用户登录、增加支付网关对接。 每一步扩展，都是对你工程化思维的锻炼。

还有什么不懂的？评论区留言挨个回。