static_assert用于编译期断言，要求条件为常量表达式，失败则中断编译；须置于函数外或C++17起函数内，消息为编译期字符串；模板中常用于类型约束，不参与SFINAE，应与requires或enable_if协同而非替代。
static_assert 的基本用法和触发条件
编译期断言靠 static_assert 实现，它在模板实例化或翻译单元编译阶段检查常量表达式，不满足就直接报错并中断编译。关键点是：表达式必须是 constexpr 上下文可求值的，运行时变量、函数调用（非 constexpr 版）、sizeof 以外的类型操作等都不行。
常见错误现象：error: static assertion failed 或更具体的 static_assert failed due to requirement 'X'，说明断言条件为 false；而如果报 error: non-constant-expression cannot be narrowed 类提示，大概率是用了非常量表达式。
- 必须写在函数体外（命名空间/类作用域），或函数体内（C++17 起允许）
- 第二个参数字符串字面量必须是编译期字符串，不能拼接、不能用宏展开后含非字面量内容
- C++11 要求至少一个参数（带消息），C++17 支持单参数形式：
static_assert(sizeof(int) == 4);
在模板中验证类型约束
这是 static_assert 最典型也最实用的场景——把类型检查从运行时提前到编译期，避免隐式转换或误用。
比如限制模板参数必须是整数类型：
template<typename t>
struct safe_int_wrapper {
static_assert(std::is_integral_v<t>, "T must be an integral type");
T value;
};</t></typename>
注意 std::is_integral_v 是 C++17 引入的变量模板，比 std::is_integral 更简洁；若需兼容 C++11，改用后者。
- 别直接用
sizeof(T) >= 4替代类型检查——它无法阻止float或指针传入 - 组合多个条件用逻辑与
&&，但每个子表达式仍需独立为常量表达式 - 对自定义类型，可用
std::is_trivially_copyable_v等 trait 配合断言，确保序列化安全
和 SFINAE / concepts 协同使用时的边界
static_assert 不参与重载决议，一旦触发就直接编译失败；而 std::enable_if 或 C++20 concepts 是“静默过滤”。两者定位不同，混用容易出问题。
典型陷阱：在 SFINAE 友好的上下文中（如模板声明处）写 static_assert，会导致本该被剔除的候选函数直接报错，破坏接口弹性。
- 正确做法：SFINAE 控制可见性，
static_assert在函数体内做最终兜底校验 - C++20 后优先用
requires子句，它语义清晰且支持诊断信息定制；static_assert适合补充 requires 无法覆盖的复杂逻辑（如编译期计算结果验证） - 不要在别名模板（alias template）定义里放
static_assert——它不延迟到实例化，可能过早触发
跨平台和标准版本兼容性细节
C++11 引入 static_assert，但早期编译器（如 GCC 4.3、MSVC 2010）实现有缺陷：不支持在类模板内部使用，或对字符串字面量长度有限制。现在主流工具链（GCC 5+、Clang 3.5+、MSVC 2015+）已无此问题，但仍需留意。
一个易忽略的坑：某些嵌入式平台或旧交叉编译器仅支持 C++11 的最小集，可能不识别 std::is_same_v 这类简写，需降级为 std::is_same::value 并确保包含对应头文件（如
- 检查编译器支持：用
__cplusplus宏判断，201103L表示 C++11，201703L表示 C++17 - 避免依赖编译器扩展（如 GCC 的
__builtin_constant_p）来构造断言条件，会牺牲可移植性 - 消息字符串中慎用 Unicode 字符或宽字符，部分旧编译器只接受 ASCII 字面量
编译期断言真正难的不是语法，而是把业务约束准确翻译成常量表达式——比如“这个数组长度必须是 2 的幂”，就得写成 (N & (N - 1)) == 0 && N != 0，而不是靠注释或运行时 assert。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
