if constexpr 是C++17引入的编译期分支机制，其本质区别在于：被丢弃分支不参与编译，允许非法语法；而普通if要求所有分支运行时前即语法正确、类型合法。
if constexpr 是什么，和普通 if 有什么本质区别
if constexpr 是 C++17 引入的编译期分支机制，它让编译器在模板实例化时就决定是否包含某段代码，而不是等到运行时。关键在于：被丢弃的分支（即条件为 false 的分支）不会参与编译——这意味着里面可以写非法语法、未定义的类型、不存在的成员函数，只要不被选中，就不会报错。
普通 if 是运行时行为，所有分支都必须语法正确、类型合法，哪怕实际永远走不到那条路。
- 普通
if里调用T::value_type，但T是int？编译失败 -
if constexpr里同样写，只要条件为false且T不是类类型，就完全没问题
这正是它能“简化模板分支”的底层原因：不用再套一层 std::enable_if_t 或特化整个函数。
什么时候必须用 if constexpr 而不是 SFINAE 或特化
当你需要在一个函数模板内部，根据类型特征做细粒度逻辑分流，且各分支涉及不兼容的操作时，if constexpr 是最直接的选择。
立即学习“C++免费学习笔记（深入）”；
常见场景包括：
- 对
std::is_integral_v做整数/浮点/字符串分别处理 - 判断容器是否有
begin()和end()，再决定是否用范围 for - 在序列化函数里，对
std::optional、std::variant、普通类型分别展开
容易踩的坑：
- 把
if constexpr写在非模板函数里 → 编译错误，因为没有编译期常量表达式可依赖 - 条件里用了运行时变量（比如参数值），即使类型是
constexpr，也会导致编译失败 - 忘记
constexpr后面必须跟一个能在编译期求值的布尔表达式，例如std::is_same_v可以，some_runtime_flag不行
典型误用：忘记 else constexpr 导致分支不完整
if constexpr 的 else 分支也得是 constexpr 才能保证编译期裁剪。如果只写 if constexpr (...) { ... }，而没配 else constexpr，那么当条件为 false 时，该分支直接消失，函数可能缺少返回值或逻辑断裂。
比如这个例子会编译失败：
templateauto get_value(T t) { if constexpr (std::is_pointer_v ) { return *t; } // 缺少 else constexpr → 当 T 不是指针时，函数无返回语句 }
正确写法是：
templateauto get_value(T t) { if constexpr (std::is_pointer_v ) { return *t; } else constexpr { return t; } }
注意：C++23 允许省略 else constexpr（自动推导），但主流编译器（GCC 13、Clang 16）默认仍需显式写出，否则报错。
性能和兼容性要注意的点
if constexpr 本身不产生运行时开销，它只是控制代码生成——但它的条件表达式本身有编译期成本。频繁使用嵌套的类型特征（如 std::is_constructible_v）会让编译变慢，尤其在模板深度大时。
兼容性方面：
- GCC ≥ 7.0、Clang ≥ 4.0、MSVC ≥ 19.14（VS 2017 15.7）开始支持
- 如果项目还要支持 C++14，就不能用；别试图用宏模拟，结果只会更难维护
另外，调试时看不到被裁剪掉的分支——GDB 和 IDE 不会显示那些代码，容易让人误以为逻辑“没走”，其实是根本没进 AST。
if constexpr 看似简单，但它依赖整个上下文都是编译期可知的。一旦某个类型 trait 返回值不确定（比如自定义 trait 里混入了非字面量表达式），整个 if constexpr 就退化成普通 if，然后立刻暴露出隐藏的编译错误。
