条件必须是常量表达式，否则退化为普通 if

使用 if constexpr 时，条件必须能通过 constexpr 求值。常见判断包括：类型 traits（如 is_pointer_v、is_same_v）、sizeof 比较、模板参数包的长度（sizeof...(Ts)）、编译期常量（如 constexpr 变量）。若条件非常量表达式，编译器会报错，例如尝试使用运行时变量作为条件。注意：即使条件明显为 true 或 false，也必须保证它是常量表达式，否则退化为普通 if。

这个限制意味着你在编写模板函数时，不能把运行时传入的变量直接放进 if constexpr 的条件中。比如你的函数有一个 int n 参数，想根据 n > 0 做分支，那只能用普通 if。如果硬写成 if constexpr (n > 0)，编译器会报错：condition is not a constant expression。遇到这种错误，先检查条件是否全部由编译期可求值的表达式组成，比如模板参数、constexpr 变量、类型 traits 的结果。

被丢弃的分支仍会被语法解析，不能用来隐藏语法错误

if constexpr 不会消除所有分支的语法检查？实际上，被丢弃的分支不会被实例化，但它们的语法仍然会被解析。这意味着分支中的代码必须符合 C++ 语法，否则即使条件为 false 也会编译错误。例如，在丢弃的分支中写一个不存在的成员函数调用会导致解析错误，因为解析发生在实例化之前。因此，不能依赖 if constexpr 来隐藏语法错误。如果需要条件编译，应使用预处理宏。

这个坑很多人第一次遇到时都会困惑。我见过有人试图在丢弃分支里调用只有特定类型才有的方法，以为 false 分支不会被编译就能避开语法检查。结果编译器在解析阶段就报错了，因为那个成员名称根本不存在。验证方式很简单：写一个小测试，条件为 false 的分支中故意写一个语法错误（比如少个分号），你会发现编译器仍然报错。所以，如果确实需要完全隐藏一段代码，还是用 #if 0 ... #endif 或 #ifdef 预处理指令。

常见踩坑：类型覆盖不完整和模板上下文遗忘

一个常见错误是在 if constexpr 的 then 分支中使用了仅适用于特定类型的代码，而 else 分支中未处理其他类型，导致特化遗漏。例如，对整数类型调用 .size() 会编译错误，但 if constexpr 确保该分支仅当 T 是容器时才会实例化。然而，若条件覆盖不完整，比如遗漏了引用类型或 cv 限定，可能触发意外实例化。另一个坑是忘记在模板上下文中使用 if constexpr，导致非模板函数中编译失败。

针对第一个问题，写分支时要尽量全面覆盖可能出现的类型变体。比如判断是否为容器，除了检查是否有 begin() 和 end()，最好也考虑引用类型 T& 和 const 版本。可以在条件中使用 std::remove_cvref_t 先剥离修饰符。第二个问题，if constexpr 只在模板函数或模板类中生效，如果把它用在普通函数里，编译器会直接报错（因为普通函数没有实例化过程）。如果你在非模板函数里需要分支，还是用普通 if 或重载。

模板函数中优先使用 if constexpr 替代 SFINAE

在模板函数里，if constexpr 比传统的 SFINAE 或标签派发更清晰。例如，处理序列化时，对算术类型直接写入值，对容器类型遍历元素，对自定义类型调用序列化方法。将类型检查和分支逻辑放在模板函数内部，避免编写多个重载函数。注意：if constexpr 的分支返回类型必须一致，否则编译器可能报错，或者需要配合 auto 返回类型推导。

实际操作中，把 if constexpr 放在函数体最前面，按优先级检查类型特性。比如先检查基础类型，再检查容器特性，最后 fallback 到自定义序列化接口。如果分支返回类型不同，用 auto 让编译器推导，或者用 std::common_type_t 统一。验证时看编译后的二进制大小，不同分支的代码是否被正确剔除——可以用 objdump 或查看模板实例化的日志（编译器加 -ftemplate-backtrace-limit=0 之类的选项）。

验证与回滚边界：编译错误和模板实例化观察

引入 if constexpr 后，如果条件写错或覆盖不全，通常会在模板实例化时出现编译错误，比如 no matching function for call to 'xxx'。这时先检查条件是否真的为常量表达式，再检查所有分支是否覆盖了目标类型。回滚时只要把 if constexpr 改回普通 if 或改回原来的 SFINAE 代码即可，没有副作用。建议先在单元测试中覆盖典型类型（int、string、vector、自定义类等），确认各分支都能正确实例化且不报错。

边界情况：当条件使用 sizeof...(Args) > 0 时，注意包扩展可能引发歧义；用 requires 子句配合 if constexpr 时要确认编译器支持 C++20 的 requires 表达式，否则可能退化。保守做法是先用类型 traits 写出清晰的布尔条件，不要嵌套太深，避免可读性下降。