std::is_constant_evaluated()不能直接用于static_assert，因其返回值非字面类型常量表达式；须配合constexpr if，在编译期分支内使用static_assert才能通过检查。
std::is_constant_evaluated 为什么不能直接用在 static_assert 里
因为 static_assert 要求条件是常量表达式，而 std::is_constant_evaluated() 的返回值虽然在编译期能确定，但它本身不是常量表达式——它被设计为“运行时也合法”，所以直接写 static_assert(std::is_constant_evaluated(), "...") 会编译失败，报错类似：error: non-constant condition for static assertion。
本质是语言限制：constexpr 函数调用 ≠ 常量表达式，除非上下文强制要求（如 template 参数、constexpr if 分支）。
正确姿势：用 constexpr if + static_assert 组合校验
真正起作用的是把 std::is_constant_evaluated() 放进 constexpr if 分支中，再在分支内触发 static_assert。这样编译器能静态判定哪条分支会被选中，从而让 assert 的条件成为有效常量表达式。
- 只在校验“必须发生在编译期”的逻辑时才用这个组合，比如检查传入的
constexpr参数是否满足某约束 - 不要试图在校验“运行时不该发生”的场景里硬套——那该用普通
assert或异常 - 注意函数必须声明为
constexpr，否则constexpr if无法在编译期求值分支条件
constexpr int require_positive(int x) {
if constexpr (std::is_constant_evaluated()) {
static_assert(x > 0, "x must be positive at compile time");
} else {
// 运行时可做其他检查，比如抛异常
if (x <= 0) throw std::invalid_argument("x must be positive");
}
return x * 2;
}
常见误用：当成编译期断言开关滥用
有人以为加了 std::is_constant_evaluated() 就能“自动屏蔽”某些代码路径，结果发现 static_assert 在模板实例化时仍被触发，或根本没生效——问题往往出在调用链没完全 constexpr 化。
立即学习“C++免费学习笔记（深入）”；
- 确保所有上游调用者也是
constexpr函数，且参数本身是字面量或constexpr变量 - 若参数来自非 constexpr 上下文（比如函数参数未标记
consteval），std::is_constant_evaluated()会返回false，分支走不到static_assert -
consteval函数里不需要手动判断——它强制编译期求值，直接static_assert即可，加is_constant_evaluated反而多余
替代方案对比：consteval vs is_constant_evaluated + static_assert
如果目标纯粹是“只允许编译期调用”，优先用 consteval；只有当你需要同一函数在编译期和运行时有不同行为（比如编译期严格校验、运行时宽松容错），才值得引入 std::is_constant_evaluated() 配合 constexpr if。
-
consteval更简洁安全，但丧失运行时能力 - 混合模式下，容易漏掉某个分支的错误处理，比如忘记给运行时分支加
if (x - MSVC 19.35+、GCC 13、Clang 16+ 支持良好，但旧版本可能把
std::is_constant_evaluated()当作普通函数，导致分支判断失效
最易被忽略的一点：这个组合不解决“如何让编译器报更清晰的错误位置”——static_assert 的提示信息仍取决于你写的字符串，跟调用栈无关。真要定位到具体模板实参，得靠 requires 约束或自定义类型约束。
