constexpr函数需纯编译期可求值，违反则编译报错；consteval更严格，仅允许字面量参数；模板与constexpr协同需避免NTTP限制、捕获非常量及递归过深；零成本失效表现为运行时分支、未展开循环或冗余构造。
constexpr 函数必须满足“纯编译期可求值”条件
不是加了 constexpr 就能进编译期——它本质是编译器对函数行为的契约：所有分支、调用、对象构造都必须能在常量表达式上下文中完成。一旦出现运行时依赖（比如读全局变量、调用非 constexpr 函数、new 表达式），编译直接报错，错误信息通常含 call to non-constexpr function 或 subexpression not valid in a constant expression。
实操建议：
- 用
static_assert主动验证：在函数末尾加static_assert(false, "not constexpr")，再用constexpr auto x = your_func();触发检查 - 避免隐式转换：
std::string_view构造允许字面量，但std::string不行；同理，std::array可，std::vector不可 - C++20 起支持
constexprnew/delete，但仅限于 trivial 类型且内存不逃逸作用域
consteval 强制纯编译期求值，但调用点必须是常量表达式
consteval 是比 constexpr 更严格的约束：它禁止任何运行时调用可能。哪怕参数是变量（哪怕该变量本身是 constexpr），只要不是字面量或编译期已知常量，就报错 call to consteval function is not a constant expression。
典型误用场景：
立即学习“C++免费学习笔记（深入）”；
- 把
consteval函数传给模板非类型参数（NTTP）：NTTP 要求完全常量，没问题；但若传给普通函数形参，就会失败 - 试图在
if constexpr外调用：consteval函数不能出现在运行时分支中，哪怕分支被丢弃 - 返回类型含非字面量（non-literal）成员：例如返回
std::unique_ptr或含虚函数的类，即使内容为空也不行
consteval int square(int x) { return x * x; }
constexpr int a = 5;
// ✅ OK：a 是编译期常量
constexpr int b = square(a);
// ❌ 编译失败：x 是变量，哪怕它是 constexpr
int runtime_val = 10;
// int c = square(runtime_val); // error: call to consteval function...模板元编程 + constexpr 的协同边界在哪
模板实例化发生在编译期，但模板本身不执行计算；constexpr 提供可执行的编译期逻辑。二者结合的关键是：用模板推导类型/值，用 constexpr 做判断和计算，最终靠 if constexpr 分支裁剪。
常见踩坑点：
- 不要在模板参数中硬塞复杂
constexpr计算结果：NTTP 仅支持整型、枚举、指针、引用等有限类型，std::array可作 NTTP（C++20），但std::string不行 -
constexprlambda 在模板中需显式捕获空：C++20 允许[=]() constexpr { ... }，但捕获非常量变量会破坏常量性 - 递归模板 +
constexpr函数易触发编译器深度限制：GCC 默认 900 层，Clang 约 256，可用-ftemplate-depth=调整，但更推荐改用if constexpr+ 折叠表达式替代深度递归
零成本抽象失效的三个隐蔽信号
所谓“零成本”，前提是编译器能完全消除抽象开销。一旦以下情况出现，生成代码可能含运行时分支、冗余变量甚至函数调用：
- 模板特化未覆盖全部输入范围，导致 fallback 分支无法被
if constexpr剪掉 -
constexpr函数内含未被优化的循环（如手动展开不足的for），编译器可能保留为运行时循环而非展开 - 使用
std::integral_constant等类型擦除工具时，若未配合constexpr静态成员访问，会引入不必要的对象构造
验证方法：用 clang++ -S -O2 或 g++ -S -O2 生成汇编，搜索目标函数名，确认是否只剩常量指令（如 mov eax, 42）而无 call 或循环标签。
