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

一文搞懂自动贩卖机价格，转行后端别再只会写语法 刚学完 Python 或 Java，是不是觉得代码写得挺溜，一让做项目就抓瞎？ 很多人卡在“知道语法”和“能落地”之间的鸿沟里，连个简单的状态机都设计不好。 今天咱们不聊虚的，直接拿自动贩卖机价格这个经典案例，从零手搓一个后端核心逻辑，让你看懂工程化思维。 项目目标：别只盯着投币，要看状态流转 很多新手一上来就写 if coin 5 然后 if price 5，这种代码扩展性极差。 真正的自动贩卖机价格处理，核心不是算钱，而是管理“状态”。 我们要实现的功能很具体：支持多种商品（可乐、薯片、咖啡），不同价格，支持硬币（5分、10分、25分）和纸币（1美元），支持找零，支持退币。 注意，这里的“价格”不是写死的 int，而是一个配置项。 在实际生产中，自动贩卖机价格可能随时调整，甚至根据时间段浮动（比如深夜咖啡涨价）。 所以我们的目标，是构建一个解耦的、可配置的价格处理引擎，而不是硬编码逻辑。 对于转行后端的同学，这个项目能帮你理解：领域模型：怎么把业务规则抽象成代码对象。 状态机模式：处理复杂业务流程的标准姿势。 测试驱动：怎么保证价格计算不出错，毕竟钱算错了是要赔钱的。目录结构：工程化思维，拒绝单文件脚本 很多初学者喜欢把所有代码塞在一个 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 = DISPENSEDdef _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 = IDLEdef _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逐行讲解关键点：self.balance 是核心状态变量。每次投币都累加，每次消费都重置。 select_item 中，我们直接用 = 比较 balance 和 price_cents。这里没有做任何浮点数运算，全是整数比较，速度快且无精度误差。 _calculate_change 使用了贪心算法。对于美元、人民币等货币体系，贪心算法总能得到最优解（硬币数量最少）。但如果换成某些特殊货币体系（如某些游戏中的金币），贪心可能失效，需要改用动态规划。 注意 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 分钱。 找零算法：验证不同金额组合下，硬币数量是否正确。 状态重置：交易完成后，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 监控，统计“余额不足”的次数，用于优化商品定价。这些优化点，不需要全部实现，但你需要知道它们。 在面试中，当面试官问“你的项目有什么不足？”时，你能答出“并发安全”、“价格动态调整”、“异常处理”，就证明你具备架构思维，而不仅仅是会写代码。 小结：从语法到工程的跨越 通过这个自动贩卖机价格项目，你应该体会到：状态管理是后端业务逻辑的核心，状态机模式是解决复杂流程的有力工具。 数据与逻辑分离是工程化的基础，配置驱动让系统更灵活。 整数运算是金融场景的标配，规避浮点数陷阱。 单元测试是代码质量的保障，特别是边界情况。学会语法只是入场券，能搭出结构清晰、可扩展、可测试的项目，才是你转行后端的真正竞争力。 不要满足于“能跑就行”，要追求“跑得稳、改得动、测得全”。 这个案例虽小，但麻雀虽小五脏俱全。 你可以在此基础上扩展：增加库存管理、增加用户登录、增加支付网关对接。 每一步扩展，都是对你工程化思维的锻炼。 还有什么不懂的？评论区留言挨个回。