std::is_constant_evaluated() 在普通调用中总返回 false，因为它检测的是“本次调用是否被编译器强制走编译期求值路径”，而非参数是否为字面量；仅当用于 static_assert、数组大小等明确需要常量表达式的上下文时才返回 true。
它不能让代码“自动变快”，但能让你在同一个 constexpr 函数里，安全地为编译期和运行时各写一套逻辑——前提是调用点真被编译器当作常量表达式求值；否则，std::is_constant_evaluated() 永远返回 false，且编译器不会帮你“降级”或“兜底”。
为什么 std::is_constant_evaluated() 在普通调用里总是 false
它不是检测“参数是不是字面量”，而是检测“这次调用是否正被编译器强制走常量求值路径”。哪怕函数声明为 constexpr，只要调用点没被明确要求常量结果，就进不了编译期分支。
-
static_assert(my_func(42) == 100)→ 进入常量求值，std::is_constant_evaluated()返回true -
int x = my_func(42)→ 普通运行时调用，返回false，哪怕 42 是字面量 -
my_func(argv[1])→ 参数含运行时值，整个调用退化为运行时，分支不可达 - C++17 或更早标准下直接编译失败：该函数根本不存在
if constexpr 和 if (std::is_constant_evaluated()) 的关键区别
这是最容易混淆、也最致命的误用点。二者语义完全不同，不能互换。
-
if constexpr基于编译期已知的常量表达式做模板级剪枝：不满足条件的分支**完全不参与语法检查**，可放心写std::vector、std::cout -
if (std::is_constant_evaluated())是运行时可变的bool，两个分支**都必须通过 constexpr 语义检查**；一旦编译期分支里出现std::sqrt或new，整个函数就无法用于static_assert或数组长度 - 正确写法只能是
if constexpr (std::is_constant_evaluated())？错——std::is_constant_evaluated()返回值不是编译期常量，不能放进if constexpr，会编译报错
编译期分支里能写什么、不能写什么
编译期分支（if (std::is_constant_evaluated()) { ... }）不是“稍微限制一点”，而是“100% 严格遵守常量求值规则”。越界操作不会警告，而是硬编译失败，错误往往指向分支内第一行非法语句。
- ✅ 允许：
constexpr函数调用、字面量运算、static_assert、指针算术（如p - s）、std::array初始化、C++23constexpr std::sqrt - ❌ 禁止：
std::strlen（C++20 前非constexpr）、std::printf、new、std::vector::push_back()、对非常量static变量取地址 - ⚠️ 高危陷阱：传入
const char*时，若指针本身不是字面量或constexpr std::array首地址，解引用会触发未定义行为，导致编译失败 - 安全替代：用纯指针遍历代替
std::strlen，用手工牛顿迭代近似代替std::sqrt（C++20 前）
GCC 和 Clang 行为不一致时怎么验证
不同编译器对“哪些调用点算常量求值”的判定尺度不同，尤其在 constinit 初始化、模板推导等边界场景。别猜，用唯一可靠方式验证：
- 写
static_assert(my_func(42) == expected);—— 通过即说明该次调用确实在编译期完成 - Clang 更保守，通常只在
static_assert、数组大小、consteval调用中返回true；GCC 12+ 可能在constinit中激进尝试 - 跨平台项目应以 Clang 行为为底线，不依赖未明确强制常量表达式的上下文（比如普通
const变量初始化） - 若函数在 GCC 上能过、Clang 上失败，大概率是编译期分支里混入了 Clang 认为非法的操作（如某标准库实现中
std::array::data()非constexpr）
真正难的不是写对分支，而是确保编译期路径里每一行代码都经得起所有主流编译器的常量求值审查——哪怕你只打算在运行时用它，只要它存在于 constexpr 函数中，就逃不开这条铁律。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
