三法则要求手动管理资源时必须手写析构、拷贝构造和拷贝赋值函数，防止浅拷贝导致的双重释放、崩溃等问题；五法则强调添加移动操作后需显式删除不合理的拷贝操作；零法则指出当所有成员均满足raii时可不写任何特殊函数。
三法则：什么时候必须手写析构函数、拷贝构造和拷贝赋值
当你在类里手动管理资源（比如用 new 分配内存、fopen 打开文件、pthread_mutex_init 初始化锁），就大概率要自己写这三个函数。编译器生成的默认版本只会做浅拷贝——两个对象指向同一块内存或同一个文件描述符，后续析构时重复释放，直接崩溃。
常见错误现象：double free or corruption、segmentation fault、文件读写错乱、多线程死锁。
实操建议：
- 只要类里有裸指针成员（如
int* data）、FILE*、void*等非 RAII 资源，先默认要补全三法则 - 拷贝构造和拷贝赋值必须深拷贝资源，且确保异常安全（比如分配失败时不能泄露原资源）
- 析构函数里只负责清理，不抛异常；否则可能打断栈展开
- 如果类不可拷贝，显式删除：
T(const T&) = delete;和T& operator=(const T&) = delete;
五法则：移动语义加入后，为什么拷贝操作没被自动禁用
加了移动构造（T(T&&)）和移动赋值（T& operator=(T&&)）后，编译器不会自动把拷贝操作设为 delete。这意味着你写了移动函数，但用户仍能调用拷贝——而默认生成的拷贝函数大概率出错，因为移动函数往往已把资源“掏空”了。
立即学习“C++免费学习笔记（深入）”；
使用场景：容器类（如 MyVector）、网络连接句柄、大图数据缓存等需要高效转移所有权的地方。
实操建议：
- 一旦提供移动操作，务必同步检查拷贝操作是否还合理；不合理就显式
= delete - 移动函数内部应把源对象置为有效但空的状态（如将
ptr设为nullptr），避免二次析构 - 移动操作通常比拷贝快，但不是零成本——比如
std::string小字符串优化下，移动也可能只是复制 24 字节 - 注意
noexcept：移动函数标noexcept后，std::vector扩容时才敢用移动而非拷贝
零法则：什么情况下可以一个自定义函数都不写
当类的所有成员都自动满足资源安全（即本身遵守三/五法则），你就不需要写任何特殊成员函数。典型例子是只含 std::string、std::vector、std::unique_ptr、std::mutex 的类——它们自己管好了内存、句柄和线程安全。
参数差异：零法则成立的前提是「所有成员类型都是可移动且可拷贝的」，且没有裸资源。哪怕加了一个 int*，就立刻退化为三法则场景。
性能影响：零法则下，编译器生成的函数常是 trivial（平凡的），支持 memcpy 级别拷贝，比手写更快更安全。
实操建议：
- 优先用 RAII 类型替代裸指针/句柄：用
std::unique_ptr代替int*，用std::fstream代替FILE* - 用
static_assert(std::is_trivially_copyable_v<t>)</t>检查是否真符合零法则 - 继承时小心：基类若违反零法则，派生类也自动失效
容易被忽略的细节：= default 不等于没写，也不等于安全
= default 是显式要求编译器生成默认实现，但它只在类满足“平凡性”时才生成真正高效的版本。如果类里有 std::mutex 成员，operator= 即使 = default 也会编译失败——因为 std::mutex 不可拷贝。
另一个坑：在头文件里对模板类写 = default 析构函数，可能引发 ODR 违规；而内联定义（如 ~T() {}）反而更稳妥。
实操建议：
- 不要为了“看起来干净”而随便加
= default；先确认成员是否真的允许默认行为 - 对含有
std::atomic、std::mutex、std::thread的类，拷贝操作基本都要= delete - 用
clang -Wdefaulted-function-deleted或gcc -Weffc++帮忙揪出隐式删除却未声明的问题
资源管理真正的复杂点不在语法，而在所有权边界是否清晰。一个 std::shared_ptr 可能掩盖三个生命周期 bug，而一行 delete ptr; 如果漏掉，程序可能跑一周才崩。
