std::common_type用于泛型函数中确定多个类型能隐式转换到的最窄公共类型，严格遵循标准算术转换规则及用户特化，不处理引用或cv限定符，仅适用于可相互转换的类型组合。
std::common_type 在什么场景下才真正有用
它不是用来“猜类型”的玩具工具，而是为泛型函数写安全的中间计算类型服务的。比如你写一个接受 T 和 U 的加法函数，想让返回值是两者能自然转换到的最窄公共类型（不是盲目取 auto 或硬写 double），这时候才轮到 std::common_type 出场。
常见错误是把它当 std::decay 或 std::remove_reference 用——它不处理引用、const、cv 限定符，只看内置类型提升和用户定义的 common_type 特化。
- 只对可隐式转换成同一类型的类型组合有效；
std::common_type<int double>::type</int>是double，但std::common_type<:string int>::type</:string>是未定义的（SFINAE 失败） - 若传入左值引用（如
int&），结果仍是int，不会保留引用性 —— 它推导的是“值语义下的公共类型” - C++14 起支持变参：
std::common_type<t u v>::type</t>等价于嵌套调用，但必须两两之间都有公共类型
std::common_type::type 的实际推导规则
它的行为严格对应 C++ 标准中的“通用算术转换”（ISO/IEC 14882:2020 §7.6.6）+ 用户特化。不是靠启发式，而是编译器查表级匹配。
例如：std::common_type<unsigned long int>::type</unsigned> 在 LP64 系统上是 unsigned long（因为 int 可无损转为 unsigned long，反之不行），但在 ILP32 上可能不同——这说明它依赖平台 ABI，不能假设跨平台一致。
立即学习“C++免费学习笔记（深入）”；
- 两个整型：按整型提升规则（promotion）和转换等级（conversion rank）决定，不是简单取更宽类型
- 浮点型优先级高于整型：
std::common_type<float int>::type</float>是float - 自定义类型需显式特化
std::common_type模板，否则默认行为是空基类（即无定义），触发编译错误 - 注意
std::common_type<const t u>::type</const>和std::common_type<t u>::type</t>结果相同 —— cv 和引用修饰符在推导前就被剥离了
为什么 std::common_type 编译失败
因为 void 不参与任何隐式转换，也不满足“存在某类型 X，使得 T→X 和 U→X 都合法”这一基本前提。这不是 bug，是标准强制要求的 SFINAE 失败点。
容易踩的坑是把模板参数直接丢进 std::common_type 而不做约束，结果在某些实例化路径上报错晦涩（比如错误信息里出现 no type named 'type' in std::common_type<...></...>）。这时候该用 std::is_same_v 或 std::is_arithmetic_v 提前静态断言，而不是指望 common_type 自己兜底。
- 所有参数类型都必须是可比性类型（comparable in conversion sense），
void、函数类型、抽象类类型均非法 - 即使
T和U都是类类型，也必须至少有一个提供到同一类型的转换构造函数或转换运算符，否则推导失败 - 不要在 SFINAE 上依赖
std::common_type的失败来分支逻辑——用std::is_convertible更直接可靠
std::common_type 与 auto、decltype 的关键区别
auto 是占位符，靠初始化表达式推导具体类型；decltype 是语法驱动，连引用、const 都照单全收；而 std::common_type 是语义驱动，只关心“值被使用时该是什么类型”。三者目标完全不同。
比如 auto x = a + b; 推出的是表达式 a + b 的确切类型（可能是 int 或 long long，取决于 operator+ 返回值）；但 std::common_type<decltype decltype>::type</decltype> 推出的是数学意义上“能容纳 a 和 b 的最小兼容类型”，不依赖运算符重载定义。
- 对内置类型，
std::common_type的结果通常和decltype(+a + +b)一致（一元+触发提升），但对自定义类型，二者毫无关系 - 性能上无差异——全是编译期计算，生成代码完全一样；但误用会导致模板实例化爆炸或不可读的错误信息
- 现代代码中，多数场景该用
auto，仅当需要“脱离表达式、纯靠类型本身定义公共接口”时才用std::common_type
最常被忽略的一点：它不解决类型擦除或运行时多态问题，也不是替代 std::variant 的方案。它的作用域非常窄——就守在“两个（或多个）类型该统一成什么才能安全参与同一运算”这个边界上。越界使用，只会让编译器报错越来越难懂。
