std::type_identity是C++20引入的别名模板，用于阻止模板参数自动推导以保持类型原样；它通过将T包装为std::type_identity_t<T>创建非推导上下文，防止引用、const/volatile等修饰符在推导中丢失，避免重载错误、SFINAE失效及约束绕过。
std::type_identity 是什么，为什么需要它
C++ 模板参数推导有时会“过度聪明”，把本该保持原样的类型悄悄转换掉。比如 std::vector<int>&</int> 被推成 std::vector<int></int>（丢掉引用），或者 const T& 推导时把 const 吃掉。这种隐式降级在函数模板中尤其危险。std::type_identity 就是标准库给的“类型防火墙”：它不改变类型，但让编译器在推导时跳过它——相当于告诉编译器：“别碰这个，就用我传进去的原始类型”。
它本质就是一个恒等模板别名：
template<class T> struct type_identity { using type = T; };<br>template<class T> using type_identity_t = typename type_identity<T>::type;注意：C++20 引入，需开启 -std=c++20 或更高标准。
什么时候必须用 std::type_identity 阻止推导
常见于以下三类场景：
- 函数模板参数需保留顶层 const/volatile 或引用性，例如想强制接受
const std::string& 而非推成 std::string
- 转发函数（如包装
std::make_shared）中，避免完美转发前的类型被提前推导变形
- 配合
auto 参数（C++20）或概念约束时，防止约束失效——比如你写 requires std::same_as<T, int>，但 T 被推成了 int&，约束就崩了
std::type_identity 的典型用法和易错点
核心用法就是把“不想被推导”的参数包一层：std::type_identity_t<T>。
const std::string& 而非推成 std::string
std::make_shared）中，避免完美转发前的类型被提前推导变形auto 参数（C++20）或概念约束时，防止约束失效——比如你写 requires std::same_as<T, int>，但 T 被推成了 int&，约束就崩了std::type_identity_t<T>。
错误写法（没用）：
template<typename T><br>void foo(T x); // T 仍会被推导，x 是值拷贝正确写法：
template<typename T><br>void foo(std::type_identity_t<T> x); // T 不参与推导，x 类型完全由调用者显式决定
常见坑：
-
std::type_identity_t<T>只影响该参数的推导，不影响其他参数——别指望它“全局锁住”整个模板 - 不能用于非类型模板参数（NTTP），只对类型参数有效
- 若你写了
foo(const std::string&)，调用foo(s)（s 是std::string）仍会失败：因为std::type_identity_t<T>要求调用时显式指定T，否则无法推导；所以实际常配合默认模板参数或重载使用 - 和
std::decay_t完全相反：后者主动抹除引用/const，前者死守原始类型
一个真实调试案例：为什么 make_shared 包装器崩了
假设你写了个日志版 make_shared：
template<typename T, typename... Args><br>auto logged_make_shared(Args&&... args) {<br> log("making shared");<br> return std::make_shared<T>(std::forward<Args>(args)...);<br>}
问题来了：如果用户传 logged_make_shared<std::string>("hello")，Args... 会被推成 const char([6])，而非 const char*——导致 std::string 构造失败。
加一层 std::type_identity_t 即可修复：
template<typename T, typename... Args><br>auto logged_make_shared(std::type_identity_t<Args>&&... args) {<br> log("making shared");<br> return std::make_shared<T>(std::forward<Args>(args)...);<br>}
这样 Args 不再从实参推导，而是由调用者显式提供（或靠上下文默认），构造逻辑回归可控。
最常被忽略的是：它不解决“怎么让用户方便调用”，而只是“让类型不被污染”。真要好用，往往得搭配显式模板实参、重载，或结合 std::declval 做 SFINAE 保护——否则容易从“推导错误”变成“根本没法推导”。
