静态多态本质是模板实例化，编译期根据类型生成独立函数版本，不依赖虚函数、无运行时开销；典型实现为函数模板、类模板与CRTP；需警惕隐式实例化失败、SFINAE误用及代码膨胀。
静态多态的本质是模板实例化，不是虚函数那套
静态多态和运行时多态（即带 virtual 的继承体系）完全无关。它不依赖对象的动态类型，也不产生虚表或运行时查找开销。它的“多态性”体现在：同一个模板定义（比如 template<typename t> void process(T x)</typename>），在编译期根据传入的不同类型（int、std::string、自定义类等）生成多个独立函数版本。这些版本彼此隔离，互不干扰。
关键判断：如果你没写 template，也没用 auto 推导模板参数，那基本就不是静态多态。
最常用实现方式：函数模板 + 类模板 + CRTP
函数模板是最直观的入口。但真正体现“多态行为差异”的地方，往往需要结合类模板或 CRTP（Curiously Recurring Template Pattern）来避免虚函数开销，同时保持接口统一。
-
std::sort是典型例子：对int数组和std::string向量调用同一个sort函数名，背后是两个完全不同的实例化体，比较逻辑由operator 或自定义 <code>Compare决定 - CRTP 常用于“静态接口”场景：基类模板接收派生类作为模板参数，从而在基类中直接调用派生类的静态成员函数，无需虚函数——比如
template<typename derived> struct ShapeBase { double area() const { return static_cast<const derived>(this)->do_area(); } };</const></typename> - 类模板本身不是多态机制，但它是承载静态多态行为的容器：比如
std::vector<t></t>对T=int和T=MyType生成两套内存布局与操作逻辑
容易踩的坑：隐式实例化失败、SFINAE 误用、代码膨胀
模板不是万能胶，编译器不会为你“尽力而为”，而是严格按类型契约检查。
立即学习“C++免费学习笔记（深入）”；
- 传入不支持
operator+的类型到依赖加法的模板函数中，报错是no match for 'operator+'，而不是“找不到合适重载”这种运行时提示 - 用
std::enable_if做约束时，错误地写成typename = std::enable_if_t<...></...>（默认模板参数）而非typename = std::enable_if_t<... void></...>，会导致 SFINAE 失效，变成硬错误 - 过度泛化模板（比如所有算法都写成
template<typename t></typename>）可能引发大量重复实例化，最终二进制体积明显增大，尤其在嵌入式或强体积约束场景下要警惕
和 auto、概念（C++20 Concepts）的关系
auto 是类型推导语法糖，它本身不构成多态；但它常配合模板使用，比如 auto f = [](auto x) { return x + 1; }; 实际定义了一个闭包模板，每次调用都触发新实例化。
C++20 的 concept 是对模板参数的约束升级，它让错误信息更友好，但底层仍是静态多态机制：
template<std::integral T>
T add(T a, T b) { return a + b; }
上面这段代码如果传入 std::string，报错会明确指出 “T does not satisfy std::integral”，而不是一长串模板展开失败日志。但注意：concept 不改变实例化时机或行为，它只是编译期断言的语法糖。
真正复杂的地方在于：你得清楚哪些行为必须在编译期确定（比如内存布局、函数地址），哪些可以延迟（比如策略对象的运行时选择）。混淆这两者，就会在“想省虚调用”和“需要灵活替换实现”之间反复撕扯。
