type_traits 是编译期类型判断与变换工具，只在编译期起作用，必须配合 if constexpr、std::enable_if 或 requires 才能生效，不能用于运行时分支。
直接说结论：type_traits 不是用来“运行时判断”的，它只在编译期起作用；你不能拿它做 if (is_integral_v<t>)</t> 这种运行时分支，必须配合 if constexpr、enable_if 或 requires 才能生效。
什么时候该用 if constexpr 而不是普通 if
普通 if 会要求所有分支代码都能编译通过，而 if constexpr 只编译被选中的分支。这是 type_traits 最自然的搭档。
- 错误写法：
if (std::is_integral_v<t>) { static_assert(false, "won't compile"); }</t>—— 即使 T 是 int，else 分支里非法语句也会触发编译失败 - 正确写法：
if constexpr (std::is_integral_v<t>) { /* only this branch compiles for int */ }</t> - 注意：C++17 起才支持
if constexpr；C++14 及更早只能靠enable_if做函数重载 - 常见组合：
is_floating_point_v、is_class_v、is_enum_v都适合放在这里做类型分发
remove_reference 和 decay 到底该选哪个
两者都处理引用，但语义完全不同，混用会导致完美转发失效或 cv 限定符丢失。
-
std::remove_reference_t<t></t>→T；std::remove_reference_t<const t></const>→const T（只去引用，保留 const） -
std::decay_t<t></t>→T；std::decay_t<const t></const>→T（去引用 + 去 const/volatile + 数组/函数退化） - 写
std::forward或实现转发引用时，必须用remove_reference，否则forward<const t></const>会变成T&&，破坏语义 - 模板参数推导后想“标准化”类型（比如存进容器、做哈希），常用
decay，因为它抹平了引用、cv、数组等干扰
为什么 is_same_v 经常匹配失败
std::is_same_v<t int></t> 看似简单，但实际中极易因类型修饰不一致而返回 false。
-
int&≠int，const int≠int，int[5]≠int—— 它们是完全不同的类型 - 传参时 auto 推导出
int&，但你想匹配int，就得先remove_reference再比 - 想检查“底层是不是整数”，别用
is_same，改用is_integral_v更鲁棒 - 私有继承下
is_base_of_v<base derived>返回 true，但static_cast仍不合法 —— trait 只反映语言规则，不保证可安全转换
哪些 type_traits 容易踩兼容性坑
不是所有 trait 在所有标准版本里都可用，也不是所有 trait 对不完整类型安全。
-
is_trivially_copyable_v在 C++11 中只有类模板形式（is_trivially_copyable<t>::value</t>），C++17 才有变量模板简写 - 所有
is_*trait（如is_constructible）要求类型必须“完整”（不能是前置声明），否则编译失败 —— 这在循环依赖头文件时很隐蔽 -
is_pod已被弃用（C++20），等价逻辑需用is_standard_layout_v<t> && is_trivial_v<t></t></t>组合 - C++20 起推荐用
requires替代复杂enable_if，但底层仍依赖这些 trait 的布尔值，所以理解它们仍是基础
真正难的不是记住名字，而是清楚每个 trait 的定义边界：比如 is_move_constructible_v 允许移动构造函数被删除（只要声明存在），而 is_nothrow_move_constructible_v 还要检查异常规范。这些细节不看标准文档，光靠试错很容易写出在某些编译器下行为不一致的泛型代码。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
