转发引用的合理性：传值后移动方案无法实现的功能有哪些？

架构老林

2026-6-14

转发引用 vs 传值后移动：不可替代的场景

传值后移动的写法确实在很多简单赋值场景下能达到和转发引用近似的效果，但转发引用有几个关键场景是传值移动方案完全无法实现的：

处理不可拷贝/不可移动的类型：如果你的Data是不可拷贝也不可移动的类型（比如std::mutex、std::atomic这类），传值写法直接编译失败——因为函数参数必须完成拷贝或移动构造。但转发引用可以直接传递原对象的左值引用，完全不需要构造新对象。
避免对象切片（多态场景）：如果Data是基类，传入派生类对象时，传值写法会触发对象切片：只会构造一个基类Data对象，派生类特有的成员和多态信息全部丢失。而转发引用可以传递派生类的左值/右值引用，要是m_data是基类引用，就能保留多态性；要是m_data是派生类类型，也能直接完成赋值（前提是类型兼容）。
完美转发到后续重载函数：如果put函数内部不是直接赋值给m_data，而是要把参数转发给另一个有重载的函数（比如内部调用process(data)，而process分别有左值和右值版本），转发引用能精准保留原参数的左值/右值属性，让process匹配到正确的重载。但传值写法里的data是函数内部的右值（因为要执行std::move），只能调用process的右值版本，完全丢失了原参数的属性。
避免额外的构造/移动开销（隐式转换场景）：假设存在一个可以隐式转换为Data的类型DataView，传值写法会先把DataView拷贝构造为一个Data对象，再移动给m_data——多了一次构造+移动的开销。但转发引用可以直接把DataView对象转发给m_data的赋值运算符（如果Data支持接受DataView的赋值重载），完全跳过中间的Data对象构造。
支持可变参数与原地构造（emplace场景）：如果你的需求是把参数转发到容器的emplace系列函数（比如m_container.emplace_back(...)），转发引用的模板版本可以扩展为可变参数模板：
```
template <typename... Args>
void put(Args&&... args) {
    m_container.emplace_back(std::forward<Args>(args)...);
}
```
这种写法能直接把参数原地构造为容器元素，完全避免拷贝/移动操作。而传值写法根本无法处理可变参数的情况，只能固定参数类型。
保留参数的const属性：如果传入的是const Data&，转发引用会推导T为const Data&，std::forward会保持其const属性，调用m_data的const版本赋值运算符（如果有针对性优化的话）。但传值写法会拷贝出一个非const的Data对象，再移动赋值，无法利用const版本的优化逻辑。

内容的提问来源于stack exchange，提问作者SillyGoose35