4、数据结构设计：配方数据模型设计、使用字典与列表存储配方、配方版本管理

配方数据怎么组织，这事其实挺关键的。我见过不少项目，一开始随便用几个变量存参数，等配方数量一多，代码就乱成一锅粥。说白了，数据结构没设计好，后面改起来比重新写还痛苦。

这一章我们就聊聊配方数据模型。我会把我在产线上摸爬滚打的经验放进来，告诉你什么样的结构最实用。

4.1 配方数据模型：从现实到代码的映射

一个配方，本质上就是一组参数的集合。比如温度、压力、时间、速度这些。但光有参数还不够，你还得知道这个配方是谁写的、什么时候创建的、用在哪个产品上。

我个人习惯把配方数据模型分成三层：

• 元数据层：配方ID、名称、版本号、创建时间、修改时间、创建人
• 参数层：具体的工艺参数，比如加热温度、保温时间、冷却速率
• 状态层：当前是否启用、是否被锁定、最后使用时间

为什么要分三层？我在项目中遇到过一个问题：有个同事把所有东西塞进一个字典，结果想查某个配方什么时候修改的，得遍历整个参数列表。后来我强制要求把元数据单独拎出来，查询效率直接翻倍。

4.2 用字典存储单个配方

Python里字典是最灵活的。一个配方就是一个字典，键是参数名，值是参数值。但要注意，字典的键最好用常量或者枚举，别用字符串硬编码。

# 单个配方的字典结构
recipe = {
    # 元数据
    "recipe_id": "RCP-2024-001",
    "name": "标准退火工艺",
    "version": "1.2.0",
    "created_at": "2024-01-15 09:30:00",
    "modified_at": "2024-03-20 14:15:00",
    "author": "张工",
    "status": "active",

    # 工艺参数
    "parameters": {
        "preheat_temp": 150,        # 预热温度 (°C)
        "soak_temp": 850,           # 保温温度 (°C)
        "soak_time": 120,           # 保温时间 (秒)
        "cool_rate": 5.0,           # 冷却速率 (°C/秒)
        "quench_temp": 60,          # 淬火温度 (°C)
        "conveyor_speed": 2.5       # 传送带速度 (m/min)
    },

    # 状态信息
    "usage_count": 47,
    "last_used": "2024-03-25 08:12:00",
    "locked": False
}

你看，这样结构清晰。想查元数据直接取顶层键，想改参数就操作内层字典。我建议把参数部分单独抽出来，方便后续做参数校验和范围检查。

4.3 用列表管理配方集合

单个配方搞定了，那几十上百个配方怎么管？列表是最直接的选择。每个元素是一个配方字典，整个列表就是配方库。

# 配方库：列表套字典
recipe_library = [
    {
        "recipe_id": "RCP-2024-001",
        "name": "标准退火工艺",
        "version": "1.2.0",
        "parameters": {"preheat_temp": 150, "soak_temp": 850}
    },
    {
        "recipe_id": "RCP-2024-002",
        "name": "快速退火工艺",
        "version": "1.0.0",
        "parameters": {"preheat_temp": 180, "soak_temp": 900}
    },
    {
        "recipe_id": "RCP-2024-003",
        "name": "特殊合金工艺",
        "version": "2.1.0",
        "parameters": {"preheat_temp": 120, "soak_temp": 780}
    }
]

但列表有个问题——查找慢。你要找一个配方，得从头遍历。如果配方数量超过几百个，我建议用字典做索引。

# 用字典做索引，recipe_id 作为键
recipe_index = {r["recipe_id"]: r for r in recipe_library}

# 查找配方 O(1) 复杂度
target = recipe_index.get("RCP-2024-002")
if target:
    print(f"找到配方: {target['name']}")

嗯，这里要注意：索引字典和原始列表要保持同步。你增删配方时，两边都得更新。我习惯写一个管理类，把列表和索引封装在一起，对外只暴露方法，不暴露数据结构。

4.4 配方版本管理：别让旧配方丢了

版本管理这事，我曾经吃过亏。有一次产线突然出现批量不良，查了半天发现是操作员误用了旧版本的配方。从那以后，我强制要求每个配方必须带版本号，并且旧版本不能删除，只能标记为“已归档”。

我的版本管理策略是这样的：

版本号格式	含义	示例
主版本.次版本.修订号	语义化版本	1.2.0
主版本	工艺路线重大变更	1.x.x → 2.x.x
次版本	参数范围调整	1.2.x → 1.3.x
修订号	微小修正或注释更新	1.2.0 → 1.2.1

具体实现上，我让每个配方ID对应一个版本链。链里按时间顺序存放所有历史版本。

# 版本链结构
recipe_versions = {
    "RCP-2024-001": [
        {"version": "1.0.0", "parameters": {...}, "created_at": "2024-01-10"},
        {"version": "1.1.0", "parameters": {...}, "created_at": "2024-02-05"},
        {"version": "1.2.0", "parameters": {...}, "created_at": "2024-03-20"}
    ]
}

# 获取最新版本
latest = recipe_versions["RCP-2024-001"][-1]

# 回滚到指定版本
def rollback(recipe_id, target_version):
    versions = recipe_versions.get(recipe_id, [])
    for v in versions:
        if v["version"] == target_version:
            return v["parameters"]
    return None

4.5 知识结构图：配方数据模型全景

下面这张图把配方数据模型的核心关系画出来了。你看一眼就能明白元数据、参数、版本链是怎么串起来的。

4.6 实战建议：数据模型落地要点

理论说完了，我分享几个实际项目中的落地经验。

1. 参数名统一规范：所有参数名用英文小写+下划线，别混用中文和拼音。我在一个项目里见过 wendu 和 temperature 混着写，后来排查问题差点崩溃。
2. 参数范围校验：每个参数都应该有上下限。我习惯在配方加载时做一次校验，超出范围直接报错，不让设备带病运行。
3. 版本号自动递增：修改配方时，版本号应该自动加1。别让操作员手动填，他们很容易填错。
4. 变更记录：每次版本更新，记录变更原因。哪怕只写一句“调整保温时间”，也比空白强。出了问题能追溯。