TL; DR：考虑所有事情，在C ++中通过const引用传递仍然是一个好主意。不是过早的优化。
TL; DR2：大多数格言没有意义，直到做到。
目标
这个答案只是试图扩展C ++核心准则（在amon的评论中首先提到）上的链接项。
这个答案并没有试图解决如何正确思考和应用程序员圈子中广泛流传的各种格言的问题，特别是在矛盾的结论或证据之间调和的问题。
适用性
此答案仅适用于函数调用（同一线程上不可拆分的嵌套作用域）。
（旁注。）当可通过的事物可以逃避范围（即，其生存期可能超出外部范围）时，满足应用程序对对象生存期管理的需求就变得尤为重要。通常，这要求使用也可以进行生命周期管理的引用，例如智能指针。另一种选择是使用管理器。注意，lambda是一种可分离范围。lambda捕获的行为就像具有对象范围。因此，请注意lambda捕获。此外，请注意lambda本身的传递方式-通过复制还是通过引用。
何时传递价值
对于标量值（适合于机器寄存器且具有值语义的标准原语）而言，不需要按变异通信（共享引用），则按值传递。
对于被调用方需要克隆对象或集合的情况，请按值传递，其中被调用方的副本可以满足对克隆对象的需求。
何时通过引用等
对于所有其他情况，请传递指针，引用，智能指针，句柄（请参阅：handle-body惯用语）等。每当遵循此建议时，请照常应用const-correctness原理。
出于性能原因，应始终将内存占用量足够大的事物（聚合，对象，数组，数据结构）设计为促进按引用传递。当它是数百个字节或更多时，此建议绝对适用。当该建议为数十个字节时，这是临界点。
不寻常的范例
有一些特殊用途的编程范例，这些范例有意复制。例如，字符串处理，序列化，网络通信，隔离，第三方库的包装，共享内存的进程间通信等。在这些应用程序区域或编程范例中，数据从结构复制到结构，或有时重新打包到结构中字节数组。
在考虑优化之前，语言规范如何影响此答案。
Sub-TL; DR传播参考不应调用任何代码；通过const-reference满足此条件。但是，所有其他语言都可以轻松满足此条件。
（建议新手C ++程序员完全跳过本节。）
（本节的开头部分受到gnasher729的回答的启发。但是，得出了不同的结论。）
C ++允许用户定义的副本构造函数和赋值运算符。
（这是一个大胆的选择，既令人惊讶又令人遗憾。这绝对是与当今语言设计可接受的规范背道而驰。）
即使C ++程序员没有定义一个，C ++编译器也必须根据语言原理生成此类方法，然后确定是否需要执行除之外的其他代码memcpy。例如，包含成员的class/ 必须具有复制构造函数和非平凡的赋值运算符。structstd::vector
在其他语言中，不鼓励复制构造函数和对象克隆（除非绝对必需和/或对应用程序的语义有意义），因为对象通过语言设计具有引用语义。这些语言通常具有基于可达性而不是基于范围的所有权或引用计数的垃圾收集机制。
当在C ++（或C）中传递引用或指针（包括const引用）时，程序员可以确保除了地址值的传播之外，不会执行任何特殊代码（用户定义或编译器生成的函数） （引用或指针）。这是C ++程序员感到满意的行为的清晰说明。
但是，背景是C ++语言不必要地复杂，因此这种行为的清晰性就像核辐射区周围的某个绿洲（可生存的栖息地）。
为了增加祝福（或侮辱），C ++引入了通用引用（r值），以促进具有良好性能的用户定义的移动运算符（move-constructor和move-assignment运算符）。通过减少复制和深度克隆的需求，这可以使高度相关的用例（将对象从一个实例移动（转移）到另一个实例）中受益。但是，在其他语言中，谈论对象的这种移动是不合逻辑的。
（非主题部分）专门讨论文章“想要速度？通过价值传递！”的部分。写于2009年左右。
该文章写于2009年，解释了C ++中r值的设计依据。该文章对我在上一节中的结论提出了有效的反驳。但是，本文的代码示例和性能声明早已遭到反驳。
Sub-TL; DR C ++中r值语义的设计允许在a上惊人地优雅的用户端语义Sort函数。无法用其他语言建模（模仿）这种优雅。
排序功能应用于整个数据结构。如上所述，如果涉及大量复制，将会很慢。作为一种性能优化（实际上是相关的），排序函数被设计为在除C ++之外的许多其他语言中具有破坏性。破坏性意味着修改目标数据结构以实现排序目标。
在C ++中，用户可以选择调用以下两种实现之一：具有更好性能的破坏性实现，或不修改输入的常规实现。（为简洁起见，省略了模板。）
/*caller specifically passes in input argument destructively*/
std::vector<T> my_sort(std::vector<T>&& input)
{
std::vector<T> result(std::move(input)); /* destructive move */
std::sort(result.begin(), result.end()); /* in-place sorting */
return result; /* return-value optimization (RVO) */
}
/*caller specifically passes in read-only argument*/
std::vector<T> my_sort(const std::vector<T>& input)
{
/* reuse destructive implementation by letting it work on a clone. */
/* Several things involved; e.g. expiring temporaries as r-value */
/* return-value optimization, etc. */
return my_sort(std::vector<T>(input));
}
/*caller can select which to call, by selecting r-value*/
std::vector<T> v1 = {...};
std::vector<T> v2 = my_sort(v1); /*non-destructive*/
std::vector<T> v3 = my_sort(std::move(v1)); /*v1 is gutted*/
除了排序之外，这种优雅还可以通过递归分区在数组（最初未排序）的破坏性中值发现算法的实现中使用。
但是，请注意，大多数语言将平衡二进制搜索树方法应用于排序，而不是对数组应用破坏性排序算法。因此，该技术的实际相关性并不像看起来那样高。
编译器优化如何影响此答案
在多个级别的函数调用中应用内联（以及整个程序优化/链接时优化）时，编译器能够（有时是穷举性）看到数据流。发生这种情况时，编译器可以应用许多优化，其中一些可以消除在内存中创建整个对象的过程。通常，在这种情况下，通过值或const引用传递参数都没有关系，因为编译器可以进行详尽的分析。
但是，如果较低级别的函数调用的内容超出了分析范围（例如，编译之外的其他库中的内容，或者调用图太简单了），则编译器必须进行防御性优化。
大于机器寄存器值的对象可以通过显式的内存加载/存储指令或通过调用尊贵的对象来复制 memcpy功能。在某些平台上，编译器生成SIMD指令以便在两个内存位置之间移动，每个指令移动数十个字节（16或32）。
有关冗长或视觉混乱问题的讨论
C ++程序员习惯了这一点，即，只要程序员不讨厌C ++，在源代码中编写或读取const-reference的开销就不会太可怕。
成本效益分析之前可能已经进行了很多次。我不知道是否应该引用任何科学论文。我想大多数分析都是非科学的或不可重复的。
这就是我的想象（没有证据或可靠的参考资料）...
- 是的，它会影响使用这种语言编写的软件的性能。
- 如果编译器可以理解代码的目的，那么它可能足够聪明，可以自动化
- 不幸的是，在支持可变性（而不是功能纯净）的语言中，编译器会将大多数事物归类为变异，因此自动推导constness会将大多数事物视为非const
- 精神开销取决于人。那些认为这是沉重的精神负担的人会拒绝C ++作为可行的编程语言。