策略接口应以含虚析构函数的抽象基类定义，方法按需设计参数，避免过度通用；优先用构造函数传参配置，不暴露内部状态，不继承std::function。
策略接口怎么定义才够灵活
策略模式的核心是把算法的定义和使用分开，C++里最直接的方式是用抽象基类作为策略接口。关键不是“要不要虚函数”，而是virtual析构函数必须有——否则通过基类指针删除派生类对象会未定义行为。
常见错误是只声明纯虚函数却忘了virtual ~Strategy() = default;，导致资源泄漏或崩溃。接口方法应按需设计参数，避免过度通用（比如不硬塞std::any或万能模板），多数场景传const std::vector或double*更清晰。
- 接口只暴露必要操作，例如
execute()、validate()，不暴露内部状态访问器 - 若策略需要配置，优先用构造函数传参，而非运行时
set_config()方法（降低耦合） - 不继承
std::function——它不是策略接口，只是可调用对象包装器
具体策略类如何避免内存管理陷阱
策略对象通常由上下文（Context）持有，这时得明确所有权：用std::unique_ptr最安全，既避免裸指针误删，又比std::shared_ptr少开销。别在栈上临时构造后传地址——生命周期一结束就悬空。
示例中有人写Context c{&QuickSortStrategy{}};，这是典型错误：QuickSortStrategy{}是临时对象，构造完立即析构，c持有的是指向已销毁内存的野指针。
- 始终用智能指针托管策略实例：
std::unique_ptrstrategy = std::make_unique (); - 若策略无状态（比如只含
static成员函数），可考虑用函数指针或std::function替代类，但要清楚这已偏离经典策略模式结构 - 策略类内部避免
new裸指针；真需要动态分配，用std::vector或std::unique_ptr封装
Context类怎么设计才不破坏策略的可替换性
Context不该知道具体策略类型，只依赖Strategy接口。常见反模式是Context里写if (dynamic_cast——这等于把策略逻辑又拉回上下文，彻底废掉策略模式的意义。
另一个坑是让Context承担策略选择逻辑（比如根据数据规模自动切算法）。这职责应该外移：由工厂或配置层决定用哪个策略，Context只负责执行。
-
Context构造函数接收std::unique_ptr，不提供默认构造+后续set_strategy()（易留空指针） - 不给
Context添加get_strategy_type()之类的方法——类型信息对使用者无意义，且破坏封装 - 若需策略间共享数据，通过构造时传入的
Config对象传递，而非让Context暴露内部状态
编译期策略（std::variant + visit）适合什么场景
当策略种类固定、数量少（比如3–5种）、且性能敏感（避免虚函数调用开销），可用std::variant替代继承体系。但这不是“更高级的策略模式”，而是不同权衡：牺牲扩展性换确定性内联和零虚表开销。
错误用法是把所有策略塞进一个std::variant，然后每次std::visit都重复写几乎一样的调用逻辑——这反而增加维护成本。
- 仅在策略数稳定、无需运行时增删、且 profiler 确实显示虚调用成瓶颈时才考虑
std::variant - 用
std::visit时统一包装成 lambda，避免重复代码；别在每个分支里写完整业务逻辑 - 不要混合使用：同一模块里既用虚函数策略又用
std::variant策略，会让调用方困惑该用哪种方式切换
真正难的不是写出来，是判断什么时候不该用策略模式——比如只有两种实现且永不增加第三种，直接if-else更直白。接口膨胀、策略类里塞了大量无关成员变量、Context开始查策略类型……这些信号说明模式正在被滥用。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
