std::is_constant_evaluated()只能在constexpr或consteval函数体内直接调用，构造函数中需确保被用于常量表达式上下文（如constexpr变量初始化）才返回true；否则返回false，且编译期分支严禁运行时操作。
std::is_constant_evaluated() 在构造函数里根本不能用
它只能在 constexpr 或 consteval 函数内部调用，而普通构造函数（哪怕标记为 constexpr）的初始化列表和函数体中，若未被用于常量表达式上下文，std::is_constant_evaluated() 仍返回 false。
常见错误现象：constexpr MyClass(int x) : val(x) { if (std::is_constant_evaluated()) { ... } }，然后写 MyClass obj(42); —— 这里不是常量表达式初始化，分支进不去编译期逻辑。
- 只有
constexpr MyClass obj(42);或static_assert(MyClass(42).val == 42);这类明确要求常量求值的场景，才可能触发true - 成员初始化列表中无法直接调用
std::is_constant_evaluated()，必须挪到构造函数体或辅助constexpr工厂函数中 - 若类含非字面量成员（如
std::string、动态分配资源），即使加了constexpr，整个构造也无法进入常量求值路径
怎么安全地做“编译期构造 + 运行时构造”双模逻辑
核心是把构造逻辑拆离：用独立的 constexpr 工厂函数负责编译期路径，普通构造函数或重载负责运行时路径，主构造函数只做跳转。
示例（安全支持字面量字符串的字符串视图）：
立即学习“C++免费学习笔记（深入）”；
struct cstr_view {
const char* data_;
size_t size_;
<pre class="brush:php;toolbar:false;">constexpr cstr_view(const char* s) : cstr_view(make_constexpr(s)) {}private:
static constexpr cstr_view make_constexpr(const char s) {
if (std::is_constant_evaluated()) {
// 编译期：手动遍历，仅用字面量兼容操作
const char p = s;
while (*p) ++p;
return {s, static_cast
- 不能在
make_constexpr的true分支里调用std::strlen，否则编译失败 - 传入的
s必须是字符串字面量（如"hello"）或constexpr char[]，否则编译期分支无法通过 - 避免在工厂函数里捕获非常量状态（如全局计数器、
rand()结果），那会让整个路径退化为运行时
为什么在 constinit 变量初始化里它有时返回 false
constinit 只保证变量零初始化后立即赋值，不保证该赋值发生在常量求值阶段。GCC 可能对简单表达式激进优化并返回 true，Clang 则通常按标准保守处理，返回 false。
常见错误现象：constinit auto x = my_constexpr_func("test"); 在 Clang 下 std::is_constant_evaluated() 返回 false，导致编译期分支未执行。
- 验证是否真走编译期：用
static_assert(my_constexpr_func("test").size_ == 4);，通过即说明成功 - 跨平台项目应以 Clang 行为为底线，别依赖
constinit触发常量求值 - 若需强保障，改用
consteval函数，它强制编译期执行，std::is_constant_evaluated()必为true
构造优化中最容易被忽略的合法性检查
不是“能不能写分支”，而是“分支里的每个操作是否满足当前求值环境的约束”。编译期分支一旦出现非法操作，报错位置往往远离 std::is_constant_evaluated() 调用点，排查成本高。
- 编译期分支禁止：
new/delete、std::cout、对非常量全局变量取地址、调用非constexpr成员函数 - 运行时分支禁止：把运行时分配的对象（如
std::string）隐式传给编译期分支使用的参数，会因类型不匹配或隐式转换失败而中断 - C++23 允许编译期
std::vector，但 GCC/Clang/MSVC 支持度差异极大，不要在跨平台构造逻辑中默认启用
