默认拷贝构造函数执行浅拷贝，若类含裸指针或手动内存管理，会导致double free、崩溃等问题；需根据资源管理方式决定是否实现深拷贝或使用移动/共享语义。
拷贝构造函数不写就出问题？默认行为是浅拷贝
只要类里有指针成员、动态分配的内存，或者用了 std::unique_ptr 之外的手动资源管理，编译器自动生成的拷贝构造函数大概率会出错——它只复制指针值，不复制指针指向的内容。这叫浅拷贝，多个对象共享同一块堆内存，析构时重复 delete 就崩。
常见错误现象：double free or corruption、segmentation fault、程序随机崩溃，尤其在函数返回局部对象或容器 push_back 时触发。
- 判断要不要重写：看类里有没有裸指针（
int*）、char*、FILE*，或自己new/malloc过的资源 - 如果只用
std::vector、std::string、std::shared_ptr，通常不用写——它们内部已实现深拷贝语义 - 写了拷贝构造函数，记得也写拷贝赋值运算符（
operator=）和析构函数，否则违反“三法则”（C++11 后建议用“五法则”，加上移动构造和移动赋值）
怎么写一个安全的深拷贝构造函数
核心就一条：对每个动态资源，用 new（或等价方式）重新分配内存，并把原对象的数据逐字节/逐元素复制过去。
示例（简化版）：
立即学习“C++免费学习笔记（深入）”；
class Buffer {
char* data_;
size_t size_;
public:
Buffer(const char* src, size_t n) : size_(n) {
data_ = new char[n];
std::memcpy(data_, src, n);
}
<pre class="brush:php;toolbar:false;">// 深拷贝构造函数
Buffer(const Buffer& other) : size_(other.size_) {
data_ = new char[other.size_]; // 新分配
std::memcpy(data_, other.data_, size_); // 真复制内容
}
~Buffer() { delete[] data_; }};
- 别漏掉初始化列表里的
size_，否则data_分配大小可能未定义 - 用
std::memcpy或循环复制，别直接写data_ = other.data_（那是浅拷贝） - 如果类里有多个指针成员，每个都得单独分配 + 复制，顺序无关，但必须全覆盖
为什么有时候深拷贝反而不该做？
不是所有场景都需要深拷贝。比如包装一个大文件句柄、GPU 显存地址、网络 socket，复制底层资源开销极大甚至不可行——这时该用移动语义或共享语义，而不是硬写深拷贝。
- 如果资源不可复制（如
std::thread、std::mutex），拷贝构造函数应声明为= delete - 想共享资源？改用
std::shared_ptr，它的拷贝就是“浅指针 + 深引用计数”，安全且高效 - 临时转移所有权？优先实现移动构造函数（
Buffer(Buffer&&)），用std::move避免无谓复制
容易被忽略的坑：异常安全与 self-assignment
深拷贝代码写得不严谨，会在异常或自赋值时翻车。比如先 delete 再 new，中间抛异常就内存泄漏；或者 a = a 导致 delete 自己再访问野指针。
- 推荐“复制-交换”惯用法（copy-and-swap）：用参数构造临时对象，再
swap成员，天然处理自赋值且异常安全 - 手动写时，务必在
delete前保存旧指针，在new成功后再delete旧资源（即“先分配后释放”） - 不要在拷贝构造函数里检查
this == &other——构造函数不会被用于自赋值，那是operator=的事
深拷贝的本质不是“多写几行 new”，而是明确谁拥有哪块内存、生命周期如何对齐。很多 bug 其实源于没想清楚资源归属，而不是语法写错了。
