C++拷贝构造函数形参为何必须用引用？值传递引发的无限递归解析

每次面C++岗位，我几乎都会拿这道题当开胃菜：“拷贝构造函数的形参为什么不能用值传递？能不能用指针传递？”能一次说清楚的人，其实不算多。很多人知道答案是“必须用引用”，但真被追问到“用值会发生什么”“用指针又错在哪”时，就支支吾吾了。今天这篇就用实际代码和编译结果，把这块彻底掰开揉碎，讲清楚背后的规则、原理，以及它和值语义、移动语义之间的深层关系。

1. 先把拷贝构造函数的定义和触发场景对齐

1.1 标准对拷贝构造函数的定义：形参类型被写死

C++标准对拷贝构造函数有非常明确的限制：对于类X，一个非模板构造函数，如果它的第一个参数类型是X&、const X&、volatile X&或者const volatile X&，并且没有其他参数，或者其余参数都有默认值，那么这个构造函数才被认定为拷贝构造函数。

注意这里没有任何“指针版本”的选项。也就是说，X(const X&)是拷贝构造函数，X(X&)也是拷贝构造函数，但X(X*)根本不是拷贝构造函数，它只是碰巧接收了一个指向X的指针的普通构造函数。

这个定义不是随便定的。拷贝构造函数在语言里承担的是“值语义复制”的职责，它必须能被编译器在各种隐式拷贝场景中自动调用。如果形参类型不是引用，这个职责就从根本上无法成立。

1.2 哪些场景会真的触发拷贝构造

先列几个最常见触发场景：

• 用一个已有对象初始化另一个对象：X b(a)或X b = a
• 函数按值传参：void f(X v); f(a);
• 函数按值返回：X f() { return a; }
• 标准容器复制元素：std::vector<X> v(10, a)
• 抛出和捕获异常对象时，也涉及对象拷贝

很多人会把拷贝构造和赋值运算符搞混。拷贝构造发生在“新对象诞生”的瞬间，赋值发生在“对象已经存在”之后。判断标准很简单：看等号左边，如果左边是正在定义的新变量，就是初始化，走拷贝构造；如果左边是已经定义好的对象，就是赋值，走operator=。

1.3 为什么形参类型是整个问题的焦点

因为拷贝构造函数经常在“编译器自动插入”的场合被调用，比如按值传参。如果这个构造函数本身的形参设计不合理，那么每一次合法调用，都会额外引发一次新的拷贝动作，这就是后面要讲的核心问题。

2. 值传递为什么会无限递归：一场隐蔽的栈吞噬

2.1 值传递时编译器在背后做了什么

假设我写了一个类：

class Foo { public: Foo(int v) : val(v) {} Foo(Foo other) : val(other.val) {} // 尝试用值传递做拷贝构造 private: int val; };

当代码中出现Foo b(a)时，编译器需要把实参a复制一份给形参other。“复制一份”这个动作用什么来完成？找拷贝构造函数。它找到的是Foo(Foo other)，于是为了让这个函数被调用，又需要先把a复制一份给这个函数的形参。复制又要调用Foo(Foo other)，然后又要再复制……就形成了一个永远走不完的递归链。

用不严谨但很形象的话说：你想复印一页文件，这台复印机恰好需要先复印一次才能启动，而这一次又需要先复印一次才能启动，结果就是原地空转。

2.2 为什么编译器直接判死刑而不是留到运行时爆栈

现代编译器对这种情况的处理非常干脆。GCC和Clang都会给出明确错误：

error: copy constructor must pass its first argument by reference

原因是这个递归不是“运行到某个深度才被发现”的偶然问题，而是结构性的死循环。每次调用Foo(Foo)都必须先有一个Foo实参副本，而这个副本又必须通过Foo(Foo)产生。也就是说，第一个副本永远产生不出来，栈还没机会开始增长，逻辑上就已经自锁了。

这一点恰恰是面试时最该答出来的部分：值传递必然导致无限递归，所以标准直接在语言层面禁止了这种写法。

2.3 模板构造函数为什么可以按值传递

有人可能会问：那我写一个模板构造函数template <typename T> Foo(T other)为什么就能编译？因为模板构造函数不是拷贝构造函数，标准只限定“非模板构造函数”。当用同类型的Foo对象传入时，编译器会优先挑真正的拷贝构造函数；只有拷贝构造函数不可用时才会尝试模板版本。而且这个模板版本即使被实例化，也和标准拷贝构造没有关系，不存在“形参复制自身”的自锁问题。

3. 指针传递为什么也不行：语法合法，语义断裂

3.1 指针版本到底算什么

先说结论：X(X* p)这种构造函数是可以编译的，它合法，但它不是拷贝构造函数。这个区分很多人没意识到，导致在代码里埋了雷。

#include <iostream> class Data { public: Data(int v) : val(v) {} Data(const Data& other) : val(other.val) { std::cout << "copy ctor used" << std::endl; } Data(Data* other) : val(other ? other->val : 0) { std::cout << "pointer ctor used" << std::endl; } private: int val; }; void passByValue(Data d) { } int main() { Data a(10); Data b(&a); // 调用的是 pointer ctor passByValue(a); // 调用的才是 copy ctor return 0; }

这段代码跑出来后，b(&a)那行输出的是“pointer ctor used”，而passByValue(a)那行输出的是“copy ctor used”。这说明什么？说明指针构造函数永远不会被编译器当作拷贝构造函数来用。我见过有人只写了Data(Data*)，然后理直气壮地按值传参，结果编译直接失败，因为他这个类根本没有拷贝构造函数。

3.2 指针版本的四个致命伤

第一个致命伤：不能绑定临时对象。Data c(&Data(5))这样的代码无法编译，因为&Data(5)这个表达式本身就不合法，临时对象不能取地址。而C++代码里临时对象满天飞，比如函数返回的临时对象要传给另一个构造函数，指针版本根本接不住。

第二个致命伤：const对象传不进去。如果参数是Data*，那么const Data ca(1); Data db(&ca);会报错，因为const Data*不能转换成Data*。就算你写成const Data*，也只能让编译通过，并不能表达“从源对象复制数据”这种清晰的语义。

第三个致命伤：空指针问题。调用方随时可能传一个nullptr进来，构造函数内部必须判空，否则直接解引用就崩。试想一个拷贝动作还要担心源对象是否为空，这个设计本身就说明它不该承担复制职责。

第四个致命伤，也是真正要命的：生命周期和所有权完全失控。调用方传一个指针进来，构造函数怎么知道这个指针指向的对象还活着？如果它指向的是栈上对象，函数返回后指针就悬空了；如果它指向堆上对象，由谁来删除？这些问题全都没有答案。

3.3 指针版本可能引起的事故案例

假设类里管理了一块堆内存，我用指针版本做了一个“共享同一块内存”的构造：

class Buffer { public: explicit Buffer(size_t size) : size_(size), data_(new char[size]) {} ~Buffer() { delete[] data_; } Buffer(Buffer* other) : size_(other->size_), data_(other->data_) { // 注意：这里只是把指针赋值过来，两个对象共享 data_ } private: size_t size_; char* data_; };

然后写：

Buffer a(64); Buffer b(&a);

函数结束时会先析构b，释放data_指向的内存，然后析构a，再次释放同一块内存，这就是经典的双重释放。程序可能当时没崩，但堆已经被破坏了，之后任何一次分配都可能莫名其妙崩溃。这个事故的根源不是“忘了深拷贝”，而是指针构造函数在语法上被允许，让人误以为它可以替代拷贝构造函数。

4. 引用传递才是正解：别名天然避开递归

4.1 引用如何同时解决“递归”和“语义”两个问题

引用本质上是给对象起了一个别名，传递引用时不会产生新对象，不需要为“形参”再拷贝一份实体。所以用const X&做形参时，“拷贝构造需要调用自身来拷贝形参”这个死循环在第一步就被掐断了。

语义层面也清晰了：X(const X& other)的意思是，我要基于other指向的那个对象，创建一个新的独立对象。函数体内可以放心读other的成员，并做深拷贝。调用方不需要关心生命周期和空指针，引用天然绑定到一个真实存在的对象上。

4.2 为什么必须是const引用

如果我把拷贝构造写成X(X& other)，它仍然是拷贝构造函数，但用起来会非常憋屈。首先，不能从const对象拷贝：

const X a(1); X b(a); // 编译错误：X(X&) 不能绑定 const X

其次，不能从临时对象拷贝：

X c(X(1)); // 编译错误：非const左值引用不能绑定临时对象

而生产环境里，从const对象复制、从临时对象复制，都是最普通的操作。所以标准库和常规实践几乎统一使用const X&。X&版本只在极少数需要“窃取被拷贝对象内部资源”的特殊场景下才会出现，而这种需求现在已经有更好的移动语义来承接。

4.3 移动语义时代的补充：形参仍是引用而不是值

到了C++11之后，移动构造函数X(X&& other)出现了，它的形参仍然是引用，只不过换成了右值引用。这说明C++的设计逻辑一脉相承：只要是想在对象之间做“转移资源”的操作，就不应该制造多余的副本。移动构造里同样不能写X(X other)，否则会陷入和拷贝构造一模一样的死循环。

移动构造和拷贝构造是搭档而非替代关系。按值传参时，传入左值会尝试拷贝，传入右值会尝试移动。两个函数的形参一个用const X&、一个用X&&，共同维持了“能省则省，不能省才复制”的高效复制策略。

5. 实操验证与排查指南

5.1 用 is_copy_constructible 和日志快速判断

在实际工程里，怎么快速判断一个类是不是真的可拷贝？最直接的方法是看std::is_copy_constructible的结果：

#include <iostream> #include <type_traits> class OnlyPointer { public: explicit OnlyPointer(int v) : val(v) {} OnlyPointer(OnlyPointer* p) : val(p ? p->val : 0) {} private: int val; }; int main() { std::cout << std::boolalpha; std::cout << std::is_copy_constructible<OnlyPointer>::value << std::endl; return 0; }

输出结果是false。这个类看起来“能用一个指针构造出另一个对象”，但它在语言层面完全不具备拷贝构造能力。所有依赖拷贝的标准库算法、容器操作，对它统统不适用。这种类只能被限制在非常窄的场景里使用，一旦想放进std::vector或传给按值形参的函数，立刻编译失败。

更进一步的排查手段是打印日志。在拷贝构造函数里加一行输出，然后再跑按值传参、按值返回、容器初始化这些操作，观察输出次数。这是最直观的验证方式。

5.2 拷贝省略的陷阱：别让“没调用”骗了你

现代C++编译器非常激进，会在很多场景省略拷贝构造调用。比如：

X make() { X local; return local; } X a = make();

在开启优化后，local和a可能直接复用同一块栈内存，全程看不到拷贝构造输出。C++17之后，纯右值初始化同类型对象时的复制消除更是标准强制行为。于是很多人产生误解：“我的类不需要拷贝构造函数，反正也没被调用过。”

这是典型的经验陷阱。拷贝省略是“允许编译器不调用”，而不是“这个类不需要拷贝构造”。编译器的优化前提，是类的拷贝构造函数必须真实存在、可访问、且语义正确。如果你的类把拷贝构造函数声明为= delete，那么即使编译器想省略拷贝，也会因为“拷贝要求不可访问”而直接报错。所以判断一个类是否可拷贝，永远要看类型自身的能力，而不是看某一次编译有没有实际调用。

想观察完整的拷贝调用链，可以用g++ -std=c++17 -fno-elide-constructors关闭复制消除，这时会看到拷贝和移动构造函数被真实调用的完整过程。

5.3 面试追问与生产注意事项速查

下面这张表基本覆盖了围绕这个问题最常见的追问：

生产代码里我给自己定的规矩很简单：凡是自定义拷贝构造的类，一律同时检查析构和拷贝赋值；凡是需要禁止复制的类，明确写= delete而不是留一个不完整的指针构造函数；凡是资源管理类，优先用std::unique_ptr和std::vector这些标准组件，让它们帮我把拷贝语义解决好，而不是自己手写堆内存管理。这样踩坑的概率会小很多。

我在实际项目里处理过最典型的一次事故，就是某个类想“偷懒”用指针构造函数做复制，结果放进容器后，每次拷贝都是浅共享，析构时反复崩。后来代码评审直接规定：自定义类型只允许通过标准的拷贝构造函数和移动构造函数实现复制，任何以指针为参数的构造函数如果想承担复制职责，一律视为违规。现在回头看，这条规矩救了不少后续的维护成本。

最后再分享一个小技巧：如果你拿不准某个自定义类型该怎么处理拷贝语义，就先问自己三个问题——这个对象能不能被独立复制？复制后是否应当完全独立于原对象？是否允许空对象来复制？三个问题都答“是”，老老实实写const X&版本并做好深拷贝；有一个答“否”，就显式= delete，让编译器帮你拒绝一切意外复制。C++的拷贝语义，不是用来炫技的，而是用来表达数据所有权的，表达清楚了，后续所有代码都会顺畅很多。