policy类必须定义编译期可检查的稳定公有接口，推荐用c++20 concept约束；应避免运行时切换、状态混用、隐式耦合与头文件依赖，优先按无状态/有状态选择继承或组合，并控制模板实例化膨胀。
Policy类必须定义清晰的接口契约
Policy类不是随便写个函数就能当策略用的。它必须提供一组编译期可检查的、稳定的公有成员函数，比如 discont、format 或 create——这些名字本身不重要，但调用点（host class）必须能无歧义地访问它们。
常见错误是：Policy里写了 apply()，但 host class 却硬编码调用 run()；或者返回类型不一致（比如一个返回 int，另一个返回 std::optional<int></int>），导致模板实例化失败，报错类似：no matching function for call to 'Policy::discont(float)'。
- 推荐用 C++20
concept约束 Policy 接口，例如template<typename p> concept DiscountPolicy = requires(P p, float f) { p.discont(f); };</typename> - 避免在 Policy 中暴露非 public 成员或依赖外部状态（如全局变量），否则组合多个 Policy 时行为不可预测
- 如果 Policy 需要构造参数（如阈值、格式字符串），应通过其构造函数传入，而非靠 host class “塞”数据过去
Host class 用继承还是组合？看是否需要共享状态
继承方式（CRTP 风格）最常见：template<typename policy> class MemberCart : public Policy</typename>。好处是零成本调用、可直接复用 Policy 的所有公有接口，且编译器能内联 Policy::discont。
但一旦 Policy 需要保存状态（比如计数器、缓存 map），继承就容易出问题：多个 Policy 实例混在一起，状态被意外覆盖。这时该改用组合：template<typename policy> class MemberCart { Policy policy_; }</typename>，并显式转发调用。
- 继承适合无状态、纯函数式策略（如
GoldenMemberCart） - 组合适合带状态或需控制生命周期的策略（如带 LRU 缓存的序列化策略）
- 别混用：既继承又持有同类型 Policy 对象，会引发二义性或重复析构
多个 Policy 组合时，注意模板参数顺序和依赖关系
像 template<typename creationpolicy typename validationpolicy loggingpolicy></typename> 这种多 Policy 设计很常见，但顺序不是随意排的。如果 LoggingPolicy 的 log() 方法要用到 CreationPolicy 创建的对象，那它就必须在后者之后声明，否则模板推导会失败。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
更隐蔽的问题是 Policy 间的隐式耦合：比如 ValidationPolicy 返回 std::expected，但 CreationPolicy 只接受 bool。这类不匹配不会在定义时暴露，而是在 host class 某处调用链上才爆红。
- 用
static_assert在 host class 构造函数里检查关键契约，例如：static_assert(std::is_same_v<decltype>().validate(0)), bool>);</decltype> - 避免让一个 Policy 直接 #include 另一个 Policy 的头文件——这会破坏正交性，改一个就得重编所有组合
- 考虑用 alias template 封装常用组合，例如：
using PremiumCart = MemberCart<goldenmembercart strictvalidationpolicy asynclogpolicy>;</goldenmembercart>
别把 Policy 当运行时配置开关来用
Policy-based Design 是编译期绑定，不是运行时策略切换。你不能写 if (user_tier == "gold") { use_policy<goldenmembercart>(); }</goldenmembercart> ——这行不通。所有 Policy 类型必须在编译时确定。
真有运行时选择需求（比如插件系统、用户可配规则引擎），Policy 就不是正确工具；该用虚函数+工厂，或 std::variant + 访问者。强行用模板硬套，只会导致大量重复实例化、二进制膨胀，还掩盖了设计意图。
最容易被忽略的一点：Policy 的每个特化都会生成一份独立代码。10 个会员策略 × 5 种验证策略 × 3 种日志策略 = 150 份 MemberCart 实例。若其中多数只用一次，链接器未必能全删掉——得靠 [[gnu::visibility("hidden")]] 或 LTO 控制符号可见性。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
