C++模板的核心是编译期按需生成类型专属代码，用于解决“逻辑相同、类型不同”问题；滥用会导致可读性差、编译慢、二进制膨胀。
直接说结论：C++模板不是“怎么用”的问题，而是“在哪用、为什么非得用”的问题。它本质是编译器帮你按需生成类型专属代码的机制，不是运行时多态，也不靠宏替换——用错地方反而让代码更难读、编译更慢、二进制更大。
函数模板：替代一堆重载函数的最简路径
当你发现写了 max_int、max_double、max_string 这类名字雷同、逻辑一致的函数时，就是函数模板该上场的时候了。
- 写法很简单：
template<typename t> T max(T a, T b) { return a > b ? a : b; }</typename> - 调用时编译器自动推导类型：
max(3, 5)→max<int></int>，max(1.2f, 3.4f)→max<float></float> - 注意陷阱：如果传入
max(3, 4.5)，两个参数类型不一致，T无法统一推导，会编译失败；必须显式写成max<double>(3, 4.5)</double>或先转型 - 不要为了“看起来泛型”而模板化所有函数——比如只处理
int的配置解析函数，硬套template<typename t></typename>反而增加理解成本
类模板：把容器、工具类从具体类型中解耦出来
类模板的核心价值在于一次定义、多处实例化，且每个实例都是独立类型（vector<int></int> 和 vector<string></string> 完全无关）。
- 基础写法：
template<typename t> class Stack { std::vector<t> data; public: void push(const T& x) { data.push_back(x); } };</t></typename> - 使用：
Stack<int> s1;</int>、Stack<:string> s2;</:string>，两者互不兼容，不能混用 - 关键细节：类模板的定义和实现通常都得放在头文件里（除非用
extern template显式实例化），否则链接时报undefined reference - 别忽略默认模板参数：
template<typename t typename alloc="std::allocator<T">> class Vector</typename>能让Vector<int></int>直接可用，又保留定制分配器的能力
模板特化：当通用逻辑对某类型不适用时的兜底方案
特化不是炫技，是解决真实边界问题的手段——比如 std::vector<bool></bool> 是位压缩特化，std::hash 对自定义类型必须显式特化才能用于 unordered_map。
立即学习“C++免费学习笔记（深入）”；
- 全特化写法：
template struct std::hash<mytype> { size_t operator()(const MyType& t) const { return t.id; } };</mytype> - 偏特化只支持类模板，不支持函数模板（函数只能重载或 SFINAE）：
template<typename t> class Ptr<t> { /* 数组版指针 */ };</t></typename> - 特化必须在主模板定义之后声明，且不能只在 .cpp 里实现——否则其他 TU（translation unit）看不到，导致 ODR 违规
- 警惕过度特化：为每种
enum class都写一个to_string全特化，不如用if constexpr+constexpr switch统一处理
现代写法：用 if constexpr 和 Concepts 替代复杂特化
C++17 的 if constexpr 和 C++20 的 Concepts 让条件逻辑更清晰，避免陷入“特化嵌套特化”的泥潭。
-
if constexpr在编译期裁剪分支：if constexpr (std::is_same_v<t std::string>) { /* string 专用逻辑 */ } else { /* 通用逻辑 */ }</t> -
Concepts把约束前移：template<sortable t> void sort(T& container)</sortable>，比一堆enable_if更易读、报错更准 - 但注意：
if constexpr内部代码仍需语法正确（即使不执行），比如t.size()在T没有size()成员时仍会报错，得配合requires或decltype检查 - 别一上来就堆 Concepts——先保证模板能跑通，再逐步加约束；否则错误信息会从“类型不匹配”变成“concept not satisfied”，反而更难定位
真正容易被忽略的点是：模板不是万能胶。它解决的是「逻辑相同、类型不同」的问题，而不是「逻辑不同、强行统一」。写模板时多问一句：这个函数/类，未来是否真的需要支持多种类型？如果答案是否定的，那就别模板化——干净的 int 函数比带一堆 typename T 却只用过一次的模板更可靠。
