重复代码在多分支中是维护隐患和性能拖累，应通过函数封装、查表法（std::map/unordered_map）、策略模式或std::variant消除；但需警惕语义不同的“假重复”，避免错误合并。
重复代码在多分支中不是风格问题，是维护隐患和潜在性能拖累。直接提取、封装或替换为查表/策略，比“先写再修”更省力。
用函数封装消除 if-else 里的重复逻辑
当多个分支中出现相同变量初始化、资源申请、日志记录或 cleanup 操作时，硬塞进每个分支会放大修改成本和出错概率。
- 把共用逻辑抽成独立函数，参数只传真正需要的值，避免过度耦合
- 注意生命周期：若函数内 new 了对象，必须明确谁负责 delete；推荐返回
std::unique_ptr或直接使用栈对象 - 别为了封装而封装——如果只有两行且只被一处调用，不值得额外函数层
示例：if (type == "file") { init_io(); open_file(); ... } else if (type == "net") { init_io(); connect_socket(); ... } → 抽出 init_io() 单独调用，而非复制到每个分支里。
用 std::map / std::unordered_map 替代长串 if-else 链
当分支基于字符串、枚举或整型 key 做分发，且分支数 ≥ 5，if-else 不仅难读，编译器也难优化。查表法让逻辑扁平、易扩展、支持运行时增删。
-
std::unordered_map平均 O(1)，适合 key 分布较散；std::map是 O(log n)，但有序，调试时可遍历 - value 类型建议用
std::function<void></void>或函数指针，避免捕获大对象导致隐式拷贝 - 访问前务必检查 key 是否存在（
map.count(key) > 0或map.find(key) != map.end()），否则map[key]会默认构造
示例：if (cmd == "start") handle_start(); else if (cmd == "stop") handle_stop(); ... → 改为 auto it = handler_map.find(cmd); if (it != handler_map.end()) it->second();
用策略模式或 std::variant 处理类型/行为强相关的多分支
当分支差异本质是“不同类型的处理策略”，比如解析 JSON / XML / YAML，或对 int/double/std::string 做统一格式化，硬写 if-else 会随类型增加迅速失控。
- 策略模式适合运行时动态切换，接口稳定、新增策略无需改主逻辑；但有虚函数调用开销，嵌入式慎用
-
std::variant+std::visit更轻量，编译期确定类型集合，无虚表、无堆分配，C++17 起可用 - 避免滥用模板推导：若每个分支只做简单转换，
std::visit配合 lambda 就够用；不要为每种类型都写一个模板特化
示例：处理 std::variant<int double std::string></int> 时，用 std::visit([](const auto& v) { /* 通用逻辑 */ }, var) 统一入口，比三个 std::get + 异常捕获更安全。
警惕“看似重复”实则语义不同的代码
最危险的不是没抽离，而是抽错了——把表面相似但上下文依赖不同的逻辑强行合并，后续改一处崩三处。
- 检查变量作用域：同一行赋值，在分支 A 中是初始化，在分支 B 中可能是覆盖，不能共用
- 检查错误处理路径：一个分支里
fclose(fp)后 return，另一个里要fclose(fp)后继续执行，就不能简单提成公共 cleanup 函数 - 检查 const 正确性：若某分支修改了对象状态，另一分支只读，合并后可能破坏 const 接口契约
这类情况宁可保留少量重复，也要保证语义清晰。自动化工具（如 clang-tidy 的 readability-simplify-boolean-expr）能帮识别真重复，但无法判断语义一致性。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
