编译期类型检查靠模板+static_assert，本质是让编译器在模板实例化时发现类型不匹配；用type traits判断并配合static_assert触发编译失败，而非依赖运行时typeid或enable_if。
编译期类型检查靠什么？不是运行时 typeid，而是模板 + static_assert
编译期类型检查的本质，是让编译器在实例化模板时就发现类型不匹配，而不是等程序跑起来再报错。最直接有效的组合是：用模板参数接收类型，用 std::is_same_v、std::is_integral_v 等类型特征（type traits）做判断，再用 static_assert 触发编译失败。
比如写一个只接受整数类型的加法函数：
template <typename t>
T safe_add(T a, T b) {
static_assert(std::is_integral_v<t>, "T must be an integral type");
return a + b;
}</t></typename>
调用 safe_add(3.14, 2.71) 会直接报错：static assertion failed: T must be an integral type，且不生成任何目标代码。
为什么不用 enable_if？它更适合重载分发，不是“拦错”首选
std::enable_if 的作用是让某个模板特化“消失”，从而参与重载决议——它本身不报错，只是让错误版本不可见。当你的目标是明确拒绝某类类型并给出可读提示时，static_assert 更直接；而 enable_if 更适合实现多个版本的函数，按类型自动选一个。
- 想阻止浮点类型调用？用
static_assert，信息清晰、位置可控 - 想同时提供
vector<int></int>和vector<string></string>两种处理逻辑？用enable_if或 C++20 的requires -
enable_if写在返回类型或模板参数里容易出错，尤其配合默认模板参数时，可能因 SFINAE 失效而静默 fallback 到其他重载
C++20 的 concepts 怎么用？比 static_assert 更结构化，但别滥用约束
Concepts 是对类型要求的显式命名和复用机制，不是语法糖，而是编译期契约。定义一个概念后，可以直接约束模板参数：
template <typename t>
concept Integral = std::is_integral_v<t>;
<p>template <integral t>
T square(T x) { return x * x; }</integral></p></t></typename>
调用 square(3.5) 报错信息会包含 Integral 名称，比裸 static_assert 更易定位问题源头。但要注意：
- 不要为单次使用定义 concept，比如只在一个函数里用一次
Integral，不如直接写static_assert - concept 内部仍依赖 type traits，不能绕过标准库已有设施去“重新发明”类型判断逻辑
- 多个 concept 组合（如
Integral && std::signed_integral<t></t>）可读性下降，此时拆成static_assert分步检查反而更清楚
常见陷阱：模板参数推导失败 ≠ 类型检查失败
很多初学者以为写了 static_assert 就万事大吉，结果发现 foo("hello") 根本没进模板体，因为字符串字面量推导出 const char[6]，而模板形参是 std::string，连实例化都没发生，自然不会触发 static_assert。
这类问题必须从两层看：
- 第一层：模板能否成功推导（SFINAE 前阶段），这取决于实参和形参的匹配关系
- 第二层：模板实例化后，
static_assert或 concept 是否满足 - 若想覆盖更广的输入类型，得配合引用折叠、
std::decay_t或万能引用（T&&）来放宽推导条件
真正难的不是写检查语句，而是想清楚：你到底要约束“传入的原始类型”，还是“退化后的类型”，或是“最终使用的语义类型”。这个边界模糊时，所有检查都可能失效。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
