constexpr函数需满足：函数体符合C++标准常量表达式规则，且所有实参为常量表达式；否则仅运行时调用。consteval则强制编译期求值，否则编译失败。
constexpr 函数必须满足哪些条件才能真正编译期求值
不是标了 constexpr 就一定在编译期算——它只是“允许”编译器在常量上下文中求值。真正在编译期运行，得同时满足：函数体是单条 return 表达式（C++11），或满足更宽松的“核心常量表达式”规则（C++14+），且所有实参本身是常量表达式。
- 常见错误现象：
constexpr int f(int x) { return x * 2; }写对了语法，但f(5)能编译期算，f(i)（i是普通变量）就只能运行时调用，不报错但失去优化意义 - 使用场景：数组长度、模板非类型参数、
static_assert断言条件——这些地方强制要求常量表达式，编译器会拒绝非常量结果 - C++14 起允许循环和局部变量，但别写带
new、dynamic_cast、IO 或虚函数调用的逻辑，它们直接让函数退出 constexpr 资格
constexpr 变量为什么有时还是运行时初始化
constexpr 变量声明本身不保证初始化发生在编译期，关键看初始化表达式是否为常量表达式。哪怕用了 constexpr 函数，只要输入来源不可控，整个链就掉出编译期。
- 常见错误现象：
constexpr int x = std::get(std::make_tuple(42));在 C++17 前会失败，因为std::get不是 constexpr；C++17 后才可，但前提是元组构造本身也 constexpr（std::make_tuple(42)满足） - 参数差异：
constexpr int a = 5;立刻编译期确定；constexpr int b = some_func(some_runtime_var);直接编译失败——编译器连尝试都不做 - 性能影响：如果误以为某
constexpr变量必在编译期算，却实际被降级为静态初始化（如全局作用域中依赖其他未定义符号），可能引入启动时开销
constexpr 和 consteval 的关键区别在哪
consteval（C++20）是硬性要求——函数每次调用都必须在编译期完成，否则直接编译错误；而 constexpr 是“尽力而为”，运行时调用也合法。
- 使用场景：想彻底禁止运行时路径，比如密码哈希预计算、硬件寄存器地址校验，就该用
consteval；若要兼顾调试时传变量观察行为，保留constexpr - 常见错误现象：
consteval int square(int x) { return x * x; }，然后写int y = 3; auto z = square(y);—— 编译器立刻报错：call to consteval function 'square' is not a constant expression - 兼容性注意：C++20 才支持
consteval，老项目升级前得确认工具链（GCC 10+/Clang 11+/MSVC 19.28+）
模板 + constexpr 组合时最容易漏掉的约束
模板参数推导和 constexpr 并不自动协同。即使函数是 constexpr，模板实参仍需满足类型约束，且实例化后的具体函数仍得过常量表达式检查。
立即学习“C++免费学习笔记（深入）”；
- 常见错误现象：
template<typename t> constexpr T identity(T x) { return x; }</typename>，然后constexpr auto v = identity(42.0f);没问题，但constexpr auto w = identity(std::string{"hi"});编译失败——std::string构造不是常量表达式，模板实例化直接卡死 - 性能影响：过度泛化模板 + constexpr 可能导致隐式实例化爆炸，尤其配合 SFINAE 或 concepts 时，编译时间明显上升
- 建议做法：对关键路径，显式限定模板参数为字面类型（
std::is_literal_type_v<t></t>已弃用，改用std::is_trivially_copyable_v<t> && std::is_default_constructible_v<t></t></t>等组合判断），并在文档里写清约束
编译期计算的边界很脆——一个非 constexpr 成员函数、一次动态内存访问、甚至一个没加 constexpr 的构造函数，都可能让整条链路无声退化到运行时。别只看声明，得逐层验证每个调用点的实际上下文。
