本文介绍一种简洁、可维护的重构方法：将重复的 if-elif 链替换为「验证函数-搜索值」元组列表的遍历，避免代码冗余，提升可读性与扩展性。
本文介绍一种简洁、可维护的重构方法：将重复的 if-elif 链替换为「验证函数-搜索值」元组列表的遍历，避免代码冗余，提升可读性与扩展性。
在实际开发中，当多个分支逻辑仅在验证函数和待搜索字段上存在差异时，硬编码多个 if/elif 不仅违反 DRY（Don’t Repeat Yourself）原则，还会增加维护成本——例如新增一种搜索类型（如 VLAN 或 Vendor）时，需复制粘贴整段逻辑并修改三处。
更优解是提取共性：所有分支均执行以下操作：
- 调用特定验证函数判断字段是否有效；
- 若通过，则加载配置块（extract_blocks）；
- 在块中筛选包含该字段值的条目；
- 输出结果并终止流程。
据此，可将变化部分抽象为元组序列，并用单层 for 循环驱动：
def search_select(search_option: Searching_section):
# 定义验证函数与对应字段的映射关系（顺序即优先级）
validation_pairs = [
(Hostname_Validation, search_option.Hostname),
(MAC_Validation, search_option.MAC),
(IP_Validation, search_option.IP),
]
for validate_func, search_value in validation_pairs:
if validate_func(search_value):
blocks, _ = extract_blocks(app.conf_file_path)
result = [block for block in blocks if search_value in block]
print(result)
return # 找到首个匹配即退出，符合原逻辑的短路行为
✅ 优势说明：
- 清晰可读：意图明确——按预设优先级依次尝试各字段；
- 易于扩展：新增搜索类型只需在 validation_pairs 中追加一行元组，无需改动主干逻辑；
- 避免重复：extract_blocks 和过滤逻辑只出现一次，降低出错风险；
- 语义正确：return 确保首次命中即终止，与原 if-elif-elif 的执行顺序和短路特性完全一致。
⚠️ 注意事项：
- 验证函数（如 Hostname_Validation）必须能安全处理 None 值（因 Pydantic 字段默认可为空），建议内部做 if value is None: return False 防御；
- 若需支持“多字段同时生效”（而非仅首个有效字段），应移除 return 并累积结果，但此时需重新设计返回结构；
- filter() + list() 可直接替换为列表推导式（如示例所示），更符合 Python 惯用法且性能略优。
通过这种数据驱动的方式，我们把控制流逻辑从代码中“解放”出来，转为可配置、易测试的数据结构——这正是编写健壮、可演进代码的关键一步。
