为何在函数调用中优先使用值传递而非const引用传递？

你提到的内存效率确实是一个考量点，但值传递还有不少容易被忽略的关键优势，这些场景下它比const引用更合适：

• 彻底规避悬垂引用风险
  使用const引用时，如果传入的是临时对象、或者函数执行期间外部对象被销毁（比如局部对象提前出作用域、线程释放资源），函数内的引用就会变成悬垂引用，后续任何操作都会触发未定义行为。而值传递是直接复制一份独立的副本，完全和原对象解绑，不存在这种隐患。比如你要是把函数参数的引用存在全局容器里，后续访问就大概率出问题，但值传递的副本就不会。

• 消除别名带来的意外副作用
  引用本质是原对象的别名，哪怕是const引用，也可能遇到外部修改的干扰：比如其他线程修改了原对象，或者代码里其他地方通过另一个别名修改了对象，都会导致函数内看到的值突然变化，逻辑出现意外。值传递拿到的是独立副本，函数内的操作完全不受外部影响，逻辑更稳定，不用额外考虑并发或其他修改场景。

• 小对象场景下性能更优
  你担心的复制开销只针对大对象。对于int、char这类基础类型，或者大小不超过寄存器/缓存行的小型结构体，值传递的复制成本几乎可以忽略——编译器甚至会直接把值放到寄存器里，不需要访问内存。反而const引用需要额外的指针解引用操作（先读地址再读值），性能反而不如值传递。

• 结合移动语义，复制成本近乎为零
  C++11引入的移动语义，让值传递的成本大幅降低。对于std::string、std::vector这类支持移动的类型，当你传入临时对象或者用std::move()转移原对象资源时，值传递会触发移动构造而非拷贝构造，几乎没有内存开销。而且写法更简洁，不用在函数参数里区分const引用和右值引用，直接用值传递，编译器会自动优化。

• 接口意图更清晰，维护成本更低
  值传递的接口一眼就能看懂：函数拿到的是独立副本，外部和内部的修改完全隔离。而const引用的接口，读者需要额外确认：会不会有人把它转成非const引用修改？有没有悬垂风险？值传递的意图更直接，后续维护时不用额外纠结这些细节。

总结下来，选择值传递还是const引用，需要结合对象大小、生命周期、代码逻辑稳定性等多方面因素。当你需要独立副本、规避悬垂/别名问题，或者处理小对象时，值传递是更稳妥甚至更高效的选择。

内容的提问来源于stack exchange，提问作者E. Tolga