一文搞懂自动贩卖机价格，转行后端别再只会写语法
刚学完 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: str
price_cents: int # 价格以美分存储，如 2.50 美元存为 250
@property
def price_dollars(self):
return self.price_cents / 100
# models/coin.py
from enum import Enum
class CoinType(Enum):
PENNY = 1 # 1 cent
NICKEL = 5 # 5 cents
DIME = 10 # 10 cents
QUARTER = 25 # 25 cents
DOLLAR = 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, List
class 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.value
print(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 False
item = self.items[item_name]
# 核心逻辑：判断余额是否 = 商品价格
if self.balance = item.price_cents:
self._dispense_item(item)
self._return_change(item.price_cents)
return True
else:
print(f余额不足，还差 ${ (item.price_cents - self.balance)/100:.2f })
return False
def _dispense_item(self, item: Item):
出货逻辑，此处简化为打印
print(f出货: {item.name})
self.state = DISPENSED
def _return_change(self, price_cents: int):
找零逻辑，核心算法
change = self.balance - price_cents
if change 0:
coins = self._calculate_change(coins_cents=change)
print(f找零: {coins})
self.balance = 0
self.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_cents
for coin_type, value in coin_values:
count = remaining // value
if count 0:
result[coin_type] = count
remaining -= count * value
if remaining == 0:
break
return 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 VendingMachine
def 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 CoinType
machine.insert_coin(CoinType.QUARTER) # 25
machine.insert_coin(CoinType.QUARTER) # 25
machine.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 VendingMachine
class 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) # 25
self.machine.insert_coin(CoinType.QUARTER) # 25
self.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) # 25
self.machine.insert_coin(CoinType.QUARTER) # 25
self.machine.insert_coin(CoinType.QUARTER) # 25
self.machine.insert_coin(CoinType.QUARTER) # 25
self.machine.insert_coin(CoinType.QUARTER) # 25
self.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 监控，统计“余额不足”的次数，用于优化商品定价。
这些优化点，不需要全部实现，但你需要知道它们。
在面试中，当面试官问“你的项目有什么不足？”时，你能答出“并发安全”、“价格动态调整”、“异常处理”，就证明你具备架构思维，而不仅仅是会写代码。
小结：从语法到工程的跨越
通过这个自动贩卖机价格项目，你应该体会到：
状态管理是后端业务逻辑的核心，状态机模式是解决复杂流程的有力工具。
数据与逻辑分离是工程化的基础，配置驱动让系统更灵活。
整数运算是金融场景的标配，规避浮点数陷阱。
单元测试是代码质量的保障，特别是边界情况。
学会语法只是入场券，能搭出结构清晰、可扩展、可测试的项目，才是你转行后端的真正竞争力。
不要满足于“能跑就行”，要追求“跑得稳、改得动、测得全”。
这个案例虽小，但麻雀虽小五脏俱全。
你可以在此基础上扩展：增加库存管理、增加用户登录、增加支付网关对接。
每一步扩展，都是对你工程化思维的锻炼。
还有什么不懂的？评论区留言挨个回。 
长河君 · 2026/9/22 8:40:10 · 阅读 1.2k 一文搞懂自动贩卖机价格，转行后端别再只会写语法
一文搞懂自动贩卖机价格，转行后端别再只会写语法
刚学完 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: str
price_cents: int # 价格以美分存储，如 2.50 美元存为 250
@property
def price_dollars(self):
return self.price_cents / 100
# models/coin.py
from enum import Enum
class CoinType(Enum):
PENNY = 1 # 1 cent
NICKEL = 5 # 5 cents
DIME = 10 # 10 cents
QUARTER = 25 # 25 cents
DOLLAR = 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, List
class 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.value
print(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 False
item = self.items[item_name]
# 核心逻辑：判断余额是否 = 商品价格
if self.balance = item.price_cents:
self._dispense_item(item)
self._return_change(item.price_cents)
return True
else:
print(f余额不足，还差 ${ (item.price_cents - self.balance)/100:.2f })
return False
def _dispense_item(self, item: Item):
出货逻辑，此处简化为打印
print(f出货: {item.name})
self.state = DISPENSED
def _return_change(self, price_cents: int):
找零逻辑，核心算法
change = self.balance - price_cents
if change 0:
coins = self._calculate_change(coins_cents=change)
print(f找零: {coins})
self.balance = 0
self.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_cents
for coin_type, value in coin_values:
count = remaining // value
if count 0:
result[coin_type] = count
remaining -= count * value
if remaining == 0:
break
return 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 VendingMachine
def 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 CoinType
machine.insert_coin(CoinType.QUARTER) # 25
machine.insert_coin(CoinType.QUARTER) # 25
machine.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 VendingMachine
class 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) # 25
self.machine.insert_coin(CoinType.QUARTER) # 25
self.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) # 25
self.machine.insert_coin(CoinType.QUARTER) # 25
self.machine.insert_coin(CoinType.QUARTER) # 25
self.machine.insert_coin(CoinType.QUARTER) # 25
self.machine.insert_coin(CoinType.QUARTER) # 25
self.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 监控，统计“余额不足”的次数，用于优化商品定价。
这些优化点，不需要全部实现，但你需要知道它们。
在面试中，当面试官问“你的项目有什么不足？”时，你能答出“并发安全”、“价格动态调整”、“异常处理”，就证明你具备架构思维，而不仅仅是会写代码。
小结：从语法到工程的跨越
通过这个自动贩卖机价格项目，你应该体会到：
状态管理是后端业务逻辑的核心，状态机模式是解决复杂流程的有力工具。
数据与逻辑分离是工程化的基础，配置驱动让系统更灵活。
整数运算是金融场景的标配，规避浮点数陷阱。
单元测试是代码质量的保障，特别是边界情况。
学会语法只是入场券，能搭出结构清晰、可扩展、可测试的项目，才是你转行后端的真正竞争力。
不要满足于“能跑就行”，要追求“跑得稳、改得动、测得全”。
这个案例虽小，但麻雀虽小五脏俱全。
你可以在此基础上扩展：增加库存管理、增加用户登录、增加支付网关对接。
每一步扩展，都是对你工程化思维的锻炼。
还有什么不懂的？评论区留言挨个回。