std::is_constant_evaluated() 返回 false 的常见场景是调用点未被语义要求为常量表达式，如普通变量初始化（int x = f();）、const 非 constexpr 变量初始化、或非强制常量上下文中的 constexpr 函数调用；它只反映本次调用是否实际参与常量求值，与函数是否声明为 constexpr 无关。
std::is_constant_evaluated() 返回 false 的常见场景
它不看函数是不是 constexpr，只看「当前这次调用是否真正在做常量求值」。哪怕函数声明为 constexpr，只要调用点没被语义要求必须是常量表达式，就返回 false。
常见错误现象：constexpr int f() { return std::is_constant_evaluated() ? 42 : 0; }，然后在 main() 里写 int x = f(); —— 这里 x 不是 constexpr 变量，编译器按普通函数调用处理，std::is_constant_evaluated() 必然返回 false。
-
const int y = f();也不行：C++ 标准不要求const初始化走常量求值（除非是constexpr或constinit） - 只有明确需要常量表达式的地方才触发：数组大小、
constexpr变量初始化、模板非类型参数、constinit变量初始化（部分编译器）、static_assert表达式 - 在
consteval函数中调用，一定返回true；但它本身不保证调用者进入consteval路径
编译期分支里不能写什么
一旦进了 std::is_constant_evaluated() 的 true 分支，所有代码都得满足常量求值约束——不是“看起来像 constexpr”，而是每个操作都得能静态验证合法。
常见错误现象：分支里调用 new、对未初始化局部变量取地址、调用非 constexpr 成员函数、读非常量全局变量、用 std::printf 打印调试信息，都会导致编译失败。
- 允许的操作：
constexpr函数/变量、字面量、static_assert、if constexpr（但注意它和std::is_constant_evaluated()是正交机制）、简单循环/递归（深度受编译器限制） - 禁止的操作：
throw、dynamic_cast、reinterpret_cast（除少数特例）、std::vector::push_back（C++23 虽支持，但 GCC 14 仍限制 trivial 类型） - 推荐做法：把编译期逻辑抽成独立的
constexpr辅助函数，主函数只做跳转，降低误触风险
为什么 clang 和 gcc 对同一段代码行为不一致
是否进入常量求值路径，取决于编译器对调用点语义的判定强度，而不同编译器、甚至不同版本，对“隐式常量求值”的激进程度差异很大。
常见错误现象：一段代码在 GCC 14 + -std=c++23 下编译通过且 std::is_constant_evaluated() 返回 true，换到 Clang 18 就报错 “call to non-constexpr function”，或始终返回 false。
- GCC 更倾向在
constinit初始化、某些模板推导上下文中尝试常量求值 - Clang 对常量求值路径更保守，尤其涉及 C++23 新特性（如
constexpr std::vector）时，可能直接拒绝 - MSVC 19.39 当前完全不支持
constexpr new/delete，相关分支会直接编译失败 - 解决办法：避免依赖模糊上下文；用
static_assert(std::is_constant_evaluated(), "...")显式断言预期路径；CI 中固定编译器版本并加注释说明
性能优化的真实代价在哪
表面上是“编译期算好、运行期省事”，但 C++23 放开 constexpr 限制后，真实瓶颈转移到了编译器内部：模板实例爆炸、内存占用飙升、构建时间指数增长。
常见错误现象：一个 constexpr 函数内构造含 500 元素的 std::vector 并排序，在 CI 上触发 4GB 内存耗尽或 10 分钟超时被杀。
- 编译期容器操作（如
std::vector::sort）需完整模拟运行时语义，包括内存布局、迭代器有效性、异常路径——这些全在编译器 AST 层展开 - 分支内调用未标记
constexpr的重载函数，可能意外拖入大量非 constexpr 模板特化 - 真正轻量的编译期路径应尽量避开容器和算法，优先用数组、结构体、查表、硬编码逻辑
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
