Policy-Based Design是一种编译期静态多态的泛型架构，通过模板参数将正交策略类（如检查、线程模型）组合进主类，实现零开销、类型安全的行为装配，区别于运行时虚函数策略模式。
Policy-Based Design（基于策略的设计）不是一种运行时切换行为的模式，而是一种在编译期就把行为“装配好”的泛型架构方式。它的核心思想是：把一个类中可变、正交的行为（比如检查逻辑、线程模型、序列化方式、日志策略等）抽出来，做成独立的策略类（policy class），再通过模板参数组合进主类——就像搭积木，主类是底座，策略是可换的模块。
策略类怎么写？关键有三点
策略类本身通常是模板类，接受一个或多个类型参数（常为被管理的原始类型 T），只负责提供一组约定好的接口（如 Check()、Lock()、Message()）。它不依赖主类，也不继承任何东西，职责单一、高内聚。
- 必须是类模板，例如
template<class t> Struct StrictChecking { Static void Check(T* p) { /*...*/ } };</class> - 接口名和签名需统一，方便主类直接调用，不依赖虚函数或动态绑定
- 通常定义为
struct或class，成员多为static函数或protected工具方法，便于被主类继承或 using 引入
主类怎么组合策略？模板模板参数是关键
主类用 模板模板参数（template template parameter）接收策略类，而不是具体实例。语法形如：template<class t template> class CheckingPolicy></class>。这样既能约束传入的是“能接受一个类型参数的类模板”，又保留了策略对 T 的定制能力。
- 主类常通过多重继承公开策略（
public CheckingPolicy<t>, public ThreadingModule<t></t></t>），直接获得其接口 - 也可用 CRTP（奇异递归模板模式）让策略访问主类内部（如
ThreadingModule<smartptr></smartptr>），实现更紧密协作 - 所有策略选择都在编译期完成，零运行时开销，类型安全，且支持 SFINAE 和 concept 约束
和传统策略模式有什么区别？
传统策略模式靠运行时多态（基类指针 + 虚函数），适合行为频繁切换的场景；Policy-Based Design 是编译期静态多态，适合性能敏感、配置固定、需要强类型保障的系统级组件。
立即学习“C++免费学习笔记（深入）”；
- 没有虚函数表、没有指针间接跳转、无内存分配开销
- 不同策略组合会生成不同特化类型（
SmartPtr<int strictchecking multithread></int>和SmartPtr<int loosechecking singlethread></int>是两个完全不同的类型） - 错误在编译时报出（比如策略缺少
Check()方法），而非运行时崩溃
std::variant 可以替代 Policy-Based Design 吗？
不能替代，但可互补。用 std::variant<a b c></a> 实现策略，本质是“运行时选一个类型”，仍需 std::visit 分发，有间接成本，且丢失编译期类型信息；而 Policy-Based Design 是“编译期确定唯一类型”，策略组合即类型定义。
-
variant更适合策略种类少、需动态切换、且不苛求极致性能的业务逻辑层 - Policy-Based Design 更适合基础设施层：智能指针、容器适配器、解析器、IO 管理器等
- 两者可以共存——比如主类用 policy 定义行为骨架，内部用 variant 封装几种可插拔的底层引擎