std::add_rvalue_reference仅在模板元编程中有用，如实现std::forward；它不是运行时操作，而是编译期类型变换，对void、引用、函数类型等有特殊规则，且不改变cv限定符。
std::add_rvalue_reference 什么情况下才真有用？
它几乎从不直接用在业务代码里——你写 std::add_rvalue_reference_t<int></int> 得到 int&&，但手动写 int&& 更直白；它的真正价值只出现在模板元编程中，尤其是实现 std::forward 这类依赖类型推导的工具时。
常见错误是把它当成“给任意类型加右值引用”的运行时操作：不是。它是编译期类型变换，对 void、引用类型、函数类型等有特殊规则，且不会改变底层 cv 限定符。
-
std::add_rvalue_reference_t<int></int>→int&& -
std::add_rvalue_reference_t<int></int>→（左值引用不能再加右值引用）</li> <li><code>std::add_rvalue_reference_t<void>
→void（void&&非法）
为什么 std::forward 要靠它，而不是直接写 T&&？
因为 T&& 在模板参数推导中是万能引用（universal reference），其实际绑定行为取决于实参：可能是左值，也可能是右值。而 std::forward 必须“还原”原始实参的值类别，这就需要先根据原始类型 T 构造出正确的引用类型——std::add_rvalue_reference_t<t></t> 就是那个构造步骤。
举个简化版 forward 实现：
立即学习“C++免费学习笔记（深入）”；
template<class T>
constexpr T&& my_forward(typename std::remove_reference_t<T>& t) noexcept {
return static_cast<std::add_rvalue_reference_t<T>>(t);
}
注意这里用了 std::remove_reference_t<t>&</t> 接收参数（保证是左值引用），再用 std::add_rvalue_reference_t<t></t> 做转换——如果 T 是 int&，std::add_rvalue_reference_t<t></t> 就是 int&；如果是 int，结果就是 int&&。
容易被忽略的兼容性陷阱
它在 C++11 引入，但早期 GCC 4.7/Clang 3.1 实现有偏差，比如对函数类型处理不一致；C++17 开始明确要求对函数类型返回 T&&（如 void()&&），但部分旧标准库仍返回 void()。
- 不要对
auto推导出的类型直接套用——auto x = 42;推出int，但auto&& y = 42;推出int&&，此时std::add_rvalue_reference_t<decltype></decltype>是int&&，没变 - 和
std::decay_t混用要小心：std::decay_t<int></int>是int，再套add_rvalue_reference又变回int&&，但这已丢失原始值类别信息 - 它不处理数组维度：
std::add_rvalue_reference_t<int></int>是int[3]&&，合法但极少用
替代方案比它更常用
绝大多数时候，你应该用 std::move 或 std::forward，而不是手撕 std::add_rvalue_reference。连 std::forward 内部都封装了它，你再绕一层只会增加理解成本和出错概率。
唯一需要显式调用它的场景，是你在写类似 forward 的泛型转发逻辑，且必须精确控制引用类型生成——比如实现自定义的完美转发 wrapper、或调试类型推导过程。
值类别和引用折叠规则本身已经够绕了，加一层裸的 add_rvalue_reference 容易让类型链变得不可读。真要用，务必配上 static_assert 校验输出类型。
