is_constant_evaluated() 不能用于模板特化或SFINAE，仅能在constexpr函数体内按调用上下文返回真假；正确做法是将其封装在constexpr函数中，再作为NTTP传入模板。
模板特化里直接调用 is_constant_evaluated() 是无效的
它不是编译期宏开关，不能在模板参数推导或 SFINAE 中触发分支选择。比如写 template 会编译失败——is_constant_evaluated() 不是常量表达式上下文中的合法模板默认参数，它只能在函数体内求值。
常见错误现象：std::enable_if_t 试图用于重载或特化，结果报错 “call to non-constexpr function in constant expression” 或 “non-type template argument is not a constant expression”。
- 模板实例化发生在编译器解析阶段，早于任何函数调用点的常量求值判定
-
is_constant_evaluated()的返回值取决于**调用它的函数是否处于 manifestly constant-evaluated context**，而非模板是否被实例化 - 想靠它控制特化路径？必须把判断逻辑下沉到 constexpr 函数内部，再由该函数的调用方式间接影响模板行为
用 is_constant_evaluated() 驱动 constexpr 函数分支，再喂给模板参数
这是唯一可靠模式：让 constexpr 函数根据运行时/编译期上下文返回不同值，再把这个值作为非类型模板参数传入。编译器会在需要常量表达式的场景（如数组大小、NTTP）中强制走编译期分支，从而“拐弯”实现特化效果。
示例：
constexpr int choose_size() {
if (std::is_constant_evaluated()) {
return 1024; // 编译期：固定大缓冲
} else {
return 64; // 运行期：小栈缓冲，避免爆栈
}
}
<p>template<int n>
struct Buffer {
char data[N];
};</int></p><p>// ✅ 正确：模板参数来自 constexpr 函数，且调用点要求常量表达式
constexpr auto fast_buf = Buffer<choose_size>{};
// ❌ 错误：普通变量初始化不触发常量求值，choose_size() 返回 64，但无法用于 NTTP
int runtime_n = choose_size(); // 此时 is_constant_evaluated() 返回 false
// Buffer<runtime_n>{}; // 编译错误：runtime_n 非字面量
</runtime_n></choose_size></p>
- 关键前提是：调用
choose_size()的地方必须是明确要求常量表达式的上下文（constexpr变量、数组维度、NTTP 实参等） - 不要在模板声明处硬塞
is_constant_evaluated()，而要把它藏在 constexpr 函数体里，靠调用点语义“激活” - 如果函数返回类型是
auto，确保两个分支都返回相同类型，否则模板推导会失败
和 consteval 函数配合时，is_constant_evaluated() 总是 true
在 consteval 函数中调用 is_constant_evaluated() 永远返回 true，这看似没用，但它能帮你统一接口——把原本需要两套重载的逻辑，收束到一个 consteval 函数里，再靠它驱动模板行为。
示例（避免重复定义）：
consteval auto make_lookup_table() {
constexpr std::array<int> base = []{
std::array<int> a{};
for (int i = 0; i // 模板实参直接取自 consteval 函数结果
template<typename t auto table="make_lookup_table()">
struct Processor {
static constexpr auto table = Table;
};
</typename></int></int>
-
consteval函数无法被运行时调用，所以不存在“false 分支”，但保留is_constant_evaluated()判断可让代码在迁移到普通constexpr时少改逻辑 - 注意：MSVC 19.39 对
consteval函数返回std::array的支持仍弱于 Clang/GCC，若需跨平台，优先用constexpr+ 显式分支 - 这种写法会让模板实例化深度直接受限于
make_lookup_table()的编译期计算复杂度——16 元素安全，1000 元素可能触发 GCC 的 512 层递归限制
别踩这些坑：模板 + is_constant_evaluated() 的隐性陷阱
最危险的不是语法错误，而是行为漂移：同一份代码在不同编译器、不同优化等级、甚至不同变量声明方式下，is_constant_evaluated() 返回值突变，导致模板实例化出完全不同的类型或值。
-
const int x = f();—— GCC 可能尝试常量求值并返回true，Clang 默认返回false；换成constexpr int x = f();才真正稳定 - 在类内
static constexpr成员初始化中调用，某些 Clang 版本会因 “implicit constant evaluation” 触发分支，GCC 可能不触发 - 使用
constinit初始化变量时，is_constant_evaluated()行为未标准化，Clang 18 支持，GCC 14 尚未完全实现 - 若 constexpr 函数内部分支调用了 C++23 新增的
constexpr std::vector::push_back，MSVC 直接拒编，但 GCC/Clang 通过——此时模板实例化会因编译器差异彻底分裂
真正难缠的从来不是怎么写对，而是怎么让所有编译器在所有上下文中，对“是否算常量求值”达成一致。最稳妥的做法，永远是显式写出 constexpr 变量声明或数组维度这类无歧义的强制常量上下文。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
