static_assert能在编译期报错，因其基于常量表达式在语义分析阶段强制验证，条件不满足则编译直接失败；它要求条件为常量表达式、错误信息为字符串字面量，适用于模板类型约束、宏校验替代及清晰错误提示等场景。
static_assert 为什么能在编译期报错
它不是运行时检查，而是编译器在解析模板或常量表达式时就强制验证的断言。只要条件不满足，编译直接失败，连目标文件都不会生成——这比 assert 或异常更早掐断错误配置。
常见错误现象：改了某个宏定义（比如 MAX_BUFFER_SIZE），但忘了同步更新依赖它的数组长度，结果越界隐患埋到运行时才暴露。static_assert 能在改完宏、还没跑测试前就亮红灯。
- 必须用常量表达式：不能含变量、函数调用（除非是
constexpr函数）、运行时才能确定的值 - 第二个参数（错误信息）必须是字符串字面量，不能拼接、不能用宏展开后的内容（GCC/Clang 对宏支持有限，容易静默失效）
- C++11 起支持，但 C++17 加了对模板参数的更好推导，C++20 允许用
std::is_same_v这类类型特征直接写条件
怎么给模板加安全护栏
模板最怕传错类型——比如要求整数却传了浮点，或者要求可默认构造却给了不可构造的类。这时候靠文档或注释根本拦不住，static_assert 是唯一靠谱的编译期守门员。
典型使用场景：封装一个只接受无符号整数的容器适配器，或限制某个算法只对 std::random_access_iterator 生效。
立即学习“C++免费学习笔记（深入）”；
- 用
std::is_integral_v<t></t>检查类型分类，别手写std::is_same<t int>::value || std::is_same<t unsigned>::value</t></t>——漏掉long long就白写了 - 用
std::is_default_constructible_v<t></t>替代手动判断是否有默认构造函数，避免被explicit构造函数绕过 - 错误信息里尽量写清“要什么”，而不是“不要什么”：写
"T must be unsigned"比"T cannot be signed"更明确
template <typename T>
struct ring_buffer {
static_assert(std::is_unsigned_v<T>, "T must be unsigned");
T data[1024];
};
和宏定义搭配时最容易踩的坑
很多人想用 static_assert 校验宏，比如确认 LOG_LEVEL 只能是 0–3。但宏在预处理阶段就被替换了，而 static_assert 在语义分析阶段才起作用——表面看能用，实则陷阱密布。
- 如果宏没定义，
static_assert(LOG_LEVEL >= 0, "...")会先报“LOG_LEVEL undeclared”，根本走不到断言逻辑 - 如果宏定义成带空格的表达式（如
#define LOG_LEVEL (1 + 1)），可能因括号缺失导致运算优先级出错，且错误位置指向断言行而非宏定义处 - 更稳的做法：用
constexpr变量替代宏，再对其做static_assert；或者用#ifdef+#error做预处理层校验，和static_assert分工
错误信息太长反而掩盖关键线索
编译器报错时，static_assert 的字符串会原样输出，但终端宽度有限，过长的信息会被截断，真正有用的类型名或数值反而看不见。
- 控制在 80 字以内，优先放约束条件和推荐值，例如：
"N must be power of 2, e.g., 64 or 128" - 避免堆砌技术术语，像
"requires std::is_trivially_copyable_v<t> && std::is_standard_layout_v<t>"</t></t>这种不如拆成两个static_assert，每条只说一个事 - 如果涉及多个并列条件，宁可用多个
static_assert，也别塞进一个里用&&连接——失败时你只能看到第一个不满足的条件
复杂类型约束、跨平台常量兼容性、模板元编程里的递归深度控制……这些地方 static_assert 不是锦上添花，是防止问题滑向集成测试阶段的最后防线。但它的威力完全取决于你写的条件是不是真能覆盖住那个“一不小心就错”的配置点。
