std::is_constant_evaluated() 仅在当前求值属于常量求值过程（如 constexpr 变量初始化、static_assert 表达式、模板非类型参数）时返回 true，否则为 false；它不依赖函数是否为 constexpr，而取决于调用点上下文是否被强制要求编译期求值。
std::is_constant_evaluated() 返回 true 的确切条件是什么？
它只在常量求值上下文中返回 true，不是“编译期执行”就自动为真——比如普通 constexpr 函数被运行时调用时，即使函数体能常量求值，std::is_constant_evaluated() 也返回 false。
关键判断依据是：当前求值是否属于「常量求值（constant evaluation）」过程，即是否被强制要求产生编译期常量（如模板非类型参数、static_assert 表达式、constexpr 变量初始化等）。
- ✅ 返回
true：在constexpr变量初始化中直接调用，或作为static_assert的条件表达式子表达式 - ❌ 返回
false：同一函数被普通函数调用，哪怕该函数本身是constexpr；或在consteval函数里调用（consteval强制常量求值，但std::is_constant_evaluated()在其中恒为true，不过这不是它的设计目标场景） - ⚠️ 容易误判：以为只要进了
constexpr函数就一定在编译期跑——其实它可能被当作普通函数调用，此时仍是运行时执行，std::is_constant_evaluated()就是false
为什么不能用 if (std::is_constant_evaluated()) { ... } 直接替换分支逻辑？
因为编译器仍需验证两个分支的合法性：即使 if 条件在编译期已知为 true 或 false，另一分支代码仍必须语法正确、且所有子表达式在对应上下文中可求值（例如运行时分支里写了 std::sqrt(2) 没问题，但若写 std::sqrt(-1) 在常量求值分支里就会编译失败）。
- 编译器不会“剪枝”掉不可达分支的语义检查——这是 C++20 的明确要求
- 常见错误：在
false分支里调用非constexpr函数（比如std::printf），结果整个constexpr函数无法用于常量求值上下文 - 安全做法：把运行时专用逻辑封装进独立函数，并确保该函数不被常量求值路径触及（例如用
!std::is_constant_evaluated()做守卫，再配合[[likely]]提示优化，但函数本身不能含非法 constexpr 表达式）
和 consteval 函数比，std::is_constant_evaluated() 解决什么独特问题？
consteval 是“必须编译期执行”，而 std::is_constant_evaluated() 是“允许双模式运行”，它让一个函数既能参与常量求值（比如生成数组大小），又能当普通函数用（比如调试时传参打印）。
立即学习“C++免费学习笔记（深入）”；
- 典型场景：实现一个带 fallback 的
constexpr字符串哈希函数——编译期走查表或递归展开，运行时改用std::hash - 性能影响：无额外开销——结果在编译期确定，生成的汇编里就是硬编码的
true或false - 兼容性注意：C++20 起支持；MSVC 19.28+、GCC 10+、Clang 11+；老编译器会报错或静默忽略（不推荐 fallback 到宏模拟）
容易踩的坑：在模板推导或 SFINAE 中误用
它不能用于模板参数推导或 requires 表达式中作为常量表达式约束，因为此时求值时机未定，编译器不允许依赖运行时不可知的上下文。
- 错误示例：
template—— 编译失败，requires std::is_constant_evaluated()> void f(); std::is_constant_evaluated()不是 ICE（integer constant expression） - 正确替代：用
constexpr变量 +if consteval（C++23）或分拆成两个重载函数（一个consteval，一个普通constexpr） - 更隐蔽的问题：在 lambda 内部调用它，而 lambda 自身未被标记为
constexpr，会导致该 lambda 无法用于常量求值上下文，即使你没打算那么用
真正起作用的永远是「调用点的上下文」，而不是函数定义位置或内部逻辑有多“像编译期代码”。写的时候得盯着调用处想：这里是不是被某个 constexpr 变量拖着一起常量求值？
