constexpr函数仅允许在常量上下文中编译期求值，需满足核心常量表达式要求；static变量、异常、asm等会使其失效，C++14放宽限制而C++20加强约束，验证方式为赋值给constexpr变量或用于模板非类型参数。
constexpr 函数必须满足编译期可求值的约束
不是所有带 constexpr 修饰的函数都能在编译期执行——它只是“允许”编译器在常量上下文中调用，但能否真正展开，取决于函数体是否满足「核心常量表达式（core constant expression）」要求。
常见卡点包括：
-
static局部变量、try/catch、asm、goto直接导致函数无法成为 constexpr - 调用非
constexpr函数（哪怕只是std::sqrt或std::string::size()）会中断常量传播 - C++14 起放宽了限制（允许局部变量、循环、条件分支），但 C++20 进一步要求所有操作必须在常量求值环境中合法（例如禁止对未初始化内存读取）
验证方式很简单：把函数结果赋给 constexpr 变量，或用在模板非类型参数位置，编译失败就说明没走通常量路径。
避免隐式运行时回退：用 if constexpr 替代普通 if
普通 if 在 constexpr 函数里仍需两条分支都可编译，哪怕某分支逻辑只在运行时才进入。这容易触发意外的 SFINAE 失败或模板实例化爆炸。
立即学习“C++免费学习笔记（深入）”；
if constexpr（C++17 起）则在编译期裁剪掉不满足条件的分支，彻底消除无效代码参与常量求值。
示例对比：
constexpr int safe_log2(int n) {
if (n <= 0) return -1; // ❌ 编译期 n=0 时，-1 合法；但 n=4 时也得能编译该分支
int r = 0;
while (n > 1) { n >>= 1; ++r; } // ✅ C++14 起允许循环
return r;
}
constexpr int log2_or_fail(int n) {
if constexpr (n <= 0) { // ✅ 分支仅在编译期判断，n>0 时整个 else 分支不参与求值
return -1;
} else {
int r = 0;
for (int t = n; t > 1; t >>= 1) ++r;
return r;
}
}
模板参数推导 + constexpr 函数是编译期计算主力组合
单独写 constexpr 函数往往不够——它需要和模板配合才能释放全部性能潜力。典型模式是把输入“抬升”为非类型模板参数（NTTP），再用 constexpr 函数加工。
例如字符串字面量长度计算：
templateconstexpr size_t str_len(const char (&s)[N]) { return N - 1; // ✅ 编译期确定 } // 使用：str_len<"hello">() → 5，完全无运行时开销
注意点：
- C++20 才支持
std::string_view作为 NTTP，之前只能用字符数组引用或std::array - 函数返回类型必须明确（不能是
auto除非 C++14+ 且所有 return 路径类型一致） - 递归深度受编译器限制（如 GCC 默认 512 层），复杂逻辑建议改用迭代或拆成多个 constexpr 步骤
constexpr 函数的调试与性能陷阱
编译期计算不是银弹：过度使用可能拖慢编译速度，尤其涉及大量模板实例化或复杂 constexpr 算法（如编译期排序、JSON 解析）。
几个现实问题：
- Clang/GCC 对 constexpr 求值深度和时间有硬限制（可通过
-fconstexpr-depth=/-fconstexpr-loop-limit=调整，但治标不治本） - 某些 constexpr 实现会生成大量中间模板特化，链接阶段符号膨胀明显
- 调试困难：GDB/Lldb 不支持单步 constexpr 执行，只能靠编译错误信息或
static_assert插桩
建议策略：优先用 consteval（C++20）明确限定“必须编译期求值”，避免无意中退化到运行时；对非关键路径，宁可用 constinit + 运行时初始化，也不硬塞 constexpr。
