除了构造新对象之外，构造函数还有副作用。因此，这两个版本的语义可能不同。
即使不是这种情况，编译器也可能无法在编译期间确定。例如，如果foo 类型的复制构造函数没有在同一个翻译单元中定义并且没有使用链接时优化，编译器将无法优化掉复制，因为它可能具有副作用在当前翻译单元的编译时未知。
同样，循环体可能会调用编译器无法证明它们没有修改 foo 的函数，在这种情况下，副本也无法被优化掉。
（顺便说一句，这对于编译器来说比 clang-tidy 给你警告更难证明，因为即使是一个函数，在技术上仍然允许修改它。即使foo 对象本身是const 限定的（例如const auto），函数也可能依赖于foo 对象的地址，而不是容器的foo 对象通过其他程序路径的地址。 )
即使翻译单元中的所有内容都是可见的，并且可观察的行为不依赖于副本，操作也可能过于复杂，编译器无法优化副本。
例子：
auto f(const std::vector<std::string>& x) {
std::size_t n = 0;
for(auto y : x)
n += y.size();
return n;
}
带有-O3 和 libstdc++ 的 GCC 和 Clang 都不会优化副本（请参阅程序集中的 operator new/operator delete/memcpy 调用）：https://godbolt.org/z/d66ac617M
还可以与引用相同的代码进行比较：https://godbolt.org/z/Tdc3GhcEv
但是，在上面的示例中，std::string 的标准库实现可能仍然存在可见性问题。这可能是一个更好的示例，其中所有定义都可能在当前翻译单元中可见：
struct A { int a[64]; };
auto f(const std::vector<std::vector<A>>& x) {
std::size_t n = 0;
for(auto y : x)
n += y.size();
return n;
}
在这种情况下，GCC 仍然不会优化副本，而 Clang 会这样做，尽管由于某种原因它仍然会在那里留下一些分配大小检查：https://godbolt.org/z/8KWPTx4o5
但是如果类型变得更复杂，那么即使所有内容都是可见的，也可能会出现两个编译器都无法优化副本的点。
如果您知道foo 的类型很简单，例如像 std::vector<int> 容器上的标量，那么它在性能方面并不重要，假设可观察的行为是相同的。
您可能仍想使用 const 引用，更具体地说是 const 部分，以保持整个代码的 const 正确性。这有多么必要，但可能会进入基于意见的领域。