结论：用虚函数接口+具体策略类+上下文持有智能指针，可将if-else拆为可插拔、可测试、不改主逻辑即可扩展的结构；关键在接口定义要窄而稳定、生命周期由上下文安全托管，新增策略仅需三处修改且不触碰原有代码。
直接上结论：用虚函数接口 + 具体策略类 + 上下文持有指针/引用，就能把一长串 if-else if-else 拆成可插拔、可测试、不改主逻辑就能加新分支的结构。关键不是“怎么写接口”，而是“在哪切”和“谁来管生命周期”。
怎么定义策略接口才不会后期返工
接口要窄、稳定、只暴露真正需要调用的能力。比如导出模块，别定义 exportToFile、exportToOss、compressThenExport 这种带实现细节的方法；只留一个 serialize(const DataSet&) —— 因为所有格式干的唯一共同事，就是把数据变成字符串。
容易踩的坑：
-
serialize()返回值类型选std::string还是std::vector<uint8_t></uint8_t>？如果后续要支持二进制格式（如 Protocol Buffers），后者更通用 - 别在接口里塞
setCompressionLevel(int)这类配置方法——那是具体策略自己的事，接口只管“做什么”，不管“怎么做” - 必须声明虚析构函数：
virtual ~ISerializer() = default;，否则用std::unique_ptr<iserializer></iserializer>时会内存泄漏
上下文类怎么持有策略才安全又灵活
上下文（Context）不是策略的容器，而是策略的使用者。它应该只持有一个策略实例的引用或智能指针，而不是自己 new/delete。
立即学习“C++免费学习笔记（深入）”；
实操建议：
- 优先用
std::unique_ptr<iserializer></iserializer>成员变量，构造时传入，避免裸指针和手动delete - 不要在上下文中做策略选择逻辑（比如根据
format字符串 new 对应类）——那属于工厂职责，混在一起会让上下文变重 - 如果策略需要共享状态（比如共用一个日志器或配置对象），通过构造函数注入，别用全局变量或单例
- 避免把策略当成临时对象传参：不要写
context.process(data, JsonSerializer{})，因为移动语义可能让行为不可控；固定生命周期更可靠
新增一种策略时，哪些地方绝对不能动
理想状态下，加 CSV 支持，只涉及三处修改：
- 新增
CsvSerializer类，继承ISerializer并实现serialize() - 在工厂或注册表里加一行映射：
registry["csv"] = []{ return std::make_unique<csvserializer>(); };</csvserializer> - 测试文件里加一个
TEST(CsvSerializerTest, BasicRoundTrip)
以下地方必须保持原封不动：
- 上下文类的头文件和实现（
Exporter或OrderProcessor） - 业务主流程中调用
serializer->serialize(data)的那行代码 - 所有已有策略类的接口定义（
ISerializer）
一旦发现要改这三处中的任何一处才能加新策略，说明接口设计或职责划分出了问题。
为什么有时候用 std::function 比虚函数更合适
当策略非常轻量、无状态、且只有一两个函数要封装时（比如一个排序比较器、一个简单校验 lambda），用 std::function<bool item></bool> 更直接。它省去了类定义、继承、虚表开销，也避免了头文件膨胀。
但要注意边界：
- 如果策略需要保存字段（比如
CompressGzip要存压缩级别），std::function就得靠捕获，容易引发悬垂引用 - 如果策略要被多次复用、跨线程传递，或者需要运行时动态替换（不只是构造时定死），还是得回归虚函数接口
-
std::function的类型擦除有小幅度性能开销，高频调用路径（如每毫秒调用数百次）需实测
最常被忽略的一点：策略的销毁时机。用裸指针时，谁 delete？用 std::shared_ptr 时，循环引用怎么破？这些不是语法问题，而是架构分层没想清的表现。
