当分支逻辑依赖模板参数且含非法代码时，应使用 if constexpr；它仅检查选中分支，避免编译错误，而普通 if 会检查所有分支。
什么时候该用 if constexpr 而不是普通 if
当分支逻辑依赖模板参数，且不同分支里有非法代码（比如调用不存在的成员函数、实例化不满足约束的类型）时，if constexpr 才真正不可替代。普通 if 会在所有分支做语法和语义检查，编译直接失败；if constexpr 则只对被选中的分支做完整检查，未选中分支仅做基本解析（跳过类型检查和求值）。
常见错误现象：error: no member named 'size' in 'MyType' 出现在模板函数里，但你明明只在 T 是容器时才想访问 size() —— 这就是典型该用 if constexpr 的信号。
- 使用场景：泛型序列处理（如对
std::vector调用.data()，对std::array直接取地址，对自定义类型走迭代器路径） - 性能影响：编译期剔除未命中分支，生成的汇编里完全看不到冗余逻辑，零运行时开销
- 兼容性注意：C++17 起支持，老项目升级前先确认编译器版本（GCC 7+、Clang 4+、MSVC 2017 15.3+）
if constexpr 的条件必须是常量表达式，但别误以为“能算出来就行”
条件表达式必须在编译期可完全求值，且不能含任何运行时依赖。容易踩的坑是把看似静态的值当成常量表达式——比如传入函数参数、未加 constexpr 修饰的静态成员、或依赖虚函数的结果。
- 正确写法：
if constexpr (std::is_same_v<t int>)</t>、if constexpr (N > 0)（N是非类型模板参数） - 错误写法：
if constexpr (x > 0)（x是函数形参）、if constexpr (obj.value() == 42)（value()不是constexpr函数） - 调试技巧：如果不确定是否为常量表达式，临时改成
static_assert，编译报错位置更明确
分支内定义变量要注意作用域和初始化时机
if constexpr 的每个分支是独立的作用域，但变量声明不会跨分支存在。更关键的是：未被选中的分支里，即使写了 T obj{...}，也不会触发构造函数调用或内存分配 —— 编译器真的会彻底丢弃整段代码。
立即学习“C++免费学习笔记（深入）”；
- 安全示例：
if constexpr (has_reserve_v<t>) { t.reserve(100); }</t>，若T没有reserve，这行根本不会进入语义分析 - 危险操作：在分支里声明并返回局部对象引用（
auto& x = ...; return x;），一旦分支被剔除，函数可能缺少返回语句而编译失败 - 性能提示：构造/析构开销、
new分配、锁获取等，只要在未选中分支里，就 100% 不发生
嵌套 if constexpr 容易写成“编译器迷宫”
三层以上嵌套会让模板实例化错误信息变得极难读，尤其当多个条件交叉依赖类型特征时。与其堆砌 if constexpr，不如提前用 requires 或 std::enable_if_t 做 SFINAE 分离，或者拆成多个重载函数。
- 可读性建议：单个函数里最多两层
if constexpr；超过就提取为命名的 constexpr 函数，比如constexpr bool is_trivially_serializable_v<t></t> - 调试陷阱：GCC 有时把嵌套失败的错误定位到最外层
if constexpr，实际问题在内层某次类型推导失败 - 真实代价：过度嵌套会让编译时间显著上升，特别是配合复杂 trait 检查时，得权衡编译速度和运行效率
最常被忽略的一点：if constexpr 不解决所有泛型分支问题，它只管“编译期可见”的条件。如果你要根据运行时数据（比如用户输入的字符串）选逻辑，还是得靠多态或查表——别硬塞进 if constexpr 里试图“优化”。
