std::make_signed和std::make_unsigned是编译期类型映射工具，仅对整型有效；char的符号性影响其返回类型，bool/enum class等不支持；不处理值转换，需手动确保范围安全。
直接说结论： std::make_signed 和 std::make_unsigned 不是“类型转换函数”，而是编译期类型映射工具，只对整型（signed/unsigned 整数）有效；对 char、bool、浮点、指针或自定义类型用它们会触发 SFINAE 失败或静态断言报错。
为什么 std::make_signed<char></char> 有时返回 signed char，有时又返回 int？
这取决于 char 在当前平台的底层有无符号性（char 是独立类型，既不是 signed char 也不是 unsigned char）。标准规定：std::make_signed<char></char> 必须返回与 char 占用相同字节数、且能表示其全部值的最小有符号整型。在 char 为无符号的平台（如某些 ARM GCC 默认），char 值域是 [0, 255]，signed char 只能表示 [-128, 127] —— 装不下，所以退而求其次选 int（只要 sizeof(int) >= sizeof(char) 且能覆盖 [0, 255]）。
常见表现：
- Clang x86_64（
char默认 signed）：std::make_signed<char>::type</char>→signed char - GCC on ARM（
char默认 unsigned）：std::make_signed<char>::type</char>→int -
std::make_signed<short></short>总是short（因为short本身是有符号的） -
std::make_signed<unsigned short></unsigned>总是short（只要sizeof(short) == sizeof(unsigned short)）
std::make_unsigned 对 bool 或 enum class 会怎样？
直接编译失败。标准明确要求输入类型必须是“可提升的整型”（promotable integral type），bool 虽是整型但被特别排除；枚举类型（包括 enum class）也不在支持范围内 —— 它们没有内置的符号属性可“映射”。
立即学习“C++免费学习笔记（深入）”；
典型错误信息（GCC/Clang）：
error: no type named 'type' in 'struct std::make_unsigned<bool>'
如果你真需要把 enum class E : uint8_t 映射为无符号底层类型，得手动取 std::underlying_type_t<e></e>，再套一层 std::make_unsigned（前提是底层类型本身是支持的整型）：
using U = std::make_unsigned_t<std::underlying_type_t<E>>;
但注意：这不是 std::make_unsigned<e></e> 的合法用法，别偷懒写错。
实际用例中容易忽略的兼容性陷阱
这两个模板常被用于泛型数值处理（比如序列化、位操作包装器），但以下情况极易出问题：
- 传入
std::size_t：在 Windows LLP64 下它是unsigned long，std::make_signed<size_t></size_t>返回long；但在 Linux LP64 下它是unsigned long，但long和long long都可能被选——行为不一致 - 传入扩展整型（如
__int128）：GCC 支持，但 Clang 可能不识别，且标准未规定，属于编译器扩展 - 和
auto+decltype混用时误以为能“运行时转符号”：它们纯属编译期元函数，生成的类型不能在运行时改变 - 假设
std::make_signed<t>::type</t>一定比T更“小”或更“快”：完全没依据；比如std::make_signed<uint8_t></uint8_t>是int8_t，但很多平台没有原生int8_t运算，反而降效
最常被漏掉的一点：它们不处理值转换逻辑。拿到 std::make_signed_t<uint32_t></uint32_t>（即 int32_t）后，你仍需自己判断原值是否在目标有符号类型可表示范围内（比如 uint32_t v = 0x80000000U 转成 int32_t 就是实现定义行为），std::make_signed 不会帮你做饱和、截断或抛异常。
