std::common_type按三元运算符语义推导类型，即decltype(std::declval() ? std::declval() : std::declval())，依赖通常算术转换规则，不考虑数值范围或溢出风险。
std::common_type 的类型推导规则是什么
std::common_type 不是“找一个能容纳所有类型的最小类型”，而是严格按 std::declval + decltype(t1 ? t2 : t3) 的三元运算符语义推导：它尝试构造一个合法的条件表达式，再取其结果类型。这意味着它依赖于内置三元运算符的转换规则，而非数值范围或隐式转换链。
例如：std::common_type_t<int unsigned int></int> 在大多数平台是 unsigned int（因为 int 可隐式转为 unsigned int，但反之不成立），而 std::common_type_t<short char></short> 是 int（整型提升规则生效）。
常见误区是认为它会“向上取公共基类”或“选最大宽度类型”——它不会。它只模拟 ? : 行为，且仅对可比较/可条件选择的类型组合有效。
为什么 std::common_type 推导出 double 而不是 long double
因为标准规定：当操作数为算术类型时，三元运算符先执行通常算术转换（usual arithmetic conversions），而 int 和 double 的转换结果是 double（int 升级为 double，不进一步升到 long double）。std::common_type 完全复用这套规则。
立即学习“C++免费学习笔记（深入）”；
验证方式：
static_assert(std::is_same_v<std::common_type_t<int, double>, double>); // 通过
注意以下几点：
-
std::common_type对非算术类型（如自定义类）要求必须支持?:重载，否则编译失败 - 若传入三个及以上类型，它递归两两推导：
common_type<a></a>等价于common_type<common_type_t>, C></common_type_t> - 空参数包（
std::common_type）推导为void
std::common_type 在模板中失效的典型场景
最常踩的坑是混用有符号与无符号小整型，或忽略用户自定义转换操作符的影响。例如：
struct S { operator int() const; operator long() const; };
此时 std::common_type_t<s int></s> 可能因重载解析歧义而编译失败（多个可行转换路径），而非自动选 int。
其他易错点包括：
- 传入引用类型：
std::common_type_t<int const int></int>是const int&，不是int；引用折叠和 cv 限定符会被保留 - 传入数组或函数类型：不支持，直接 SFINAE 失败（无对应
?:形式） - 使用
auto推导临时对象时误以为common_type会“优化”类型——它只是静态推导，不参与运行时值分析
替代方案：什么时候不该用 std::common_type
当目标是“安全提升”或“避免截断”，比如做数值计算中间类型，std::common_type 往往不够用。它不考虑溢出风险，也不感知用户语义意图。
更可控的做法是显式选择：
- 用
std::common_type_t<:decay_t>...></:decay_t>先去除引用/const，再推导（避免意外绑定） - 对算术运算，优先用
std::result_of_t<decltype></decltype>模拟一元加号提升（更接近整型提升语义） - 需要跨平台确定宽度时，改用
std::intmax_t或std::common_type_t<decltype decltype></decltype>强制触发提升
真正复杂的数值泛型逻辑，往往要结合 std::numeric_limits 和 if constexpr 手动分支，而不是依赖 common_type 的“自动”。它的设计初衷是配合 std::variant、std::tuple 等容器做类型擦除兼容性判断，不是通用数值升级工具。
