我记得带过不少刚学编程的新同学，很多人是在“指针”“内存”“类”这三座大山面前开始动摇的。前两讲我们把语法基础过了一遍，第三讲正好站在一个分水岭上：如果只看代码表面，你写的还是C++；但如果理解了函数回调机制、内存模型和对象生命周期，你才算真正开始写C++。
这一讲我打算把三件事串起来讲——函数参数到底是怎么传的、变量到底住在哪里、对象又是怎么生怎么死的。之所以把这三件事放在同一讲，是因为它们根本不是三个独立话题：函数的传参方式决定了内存里数据的流动方式，内存的生命周期决定了对象什么时候析构，而对象封装资源之后又反过来影响你该怎么设计函数。三者是一条完整的逻辑链。适合刚学完循环、数组、简单函数，准备进阶到类和指针阶段的读者，也适合写过一点C++但总觉得哪里没通的半新手。
1. 从函数到对象的跃迁：为什么要先打通这三关
1.1 函数机制的最后一里路：参数传递的底层逻辑
很多教材会把“值传递”“引用传递”“指针传递”当作三种并列的语法来教，这是一个不小的误区。从底层来看，参数传递只有一种原始动作——把实参的值复制给形参。区别只在于：复制的对象是谁。
void swap_bad(int a, int b) { int tmp = a; a = b; b = tmp; } void swap_ok(int& a, int& b) { int tmp = a; a = b; b = tmp; } void swap_ptr(int* a, int* b) { int tmp = *a; *a = *b; *b = tmp; }swap_bad 传入的 a、b 是实参的副本，函数内部改得再欢，外面纹丝不动。swap_ptr 传入的看似是指针，但指针本身依然是“值”——复制了一份地址数值，只不过这份地址指向的内存和外面实参指向的是同一块，所以通过解引用可以改到外部数据。swap_ok 用的是引用，引用在底层实现上通常就是一个指针，但在语义层面它不再产生副本，而是直接给外部变量起了个别名。
我建议初学者理解这三者的关系时，不要背结论，而是画一张内存草图：值传递复制的是格子里的内容，指针传递复制的是“格子所在地址”，引用传递则是让形参直接贴在实参那个格子上。从编译器的角度，引用和指针的机器码往往非常接近，但从语言设计角度，引用是“必不为空的别名”，指针是“可能为空、可以被重新赋值的地址变量”，这就引出了两条不同的使用纪律：函数里不想修改外部数据时用 const 引用；想表达“可选对象”或“需要重新指向”时用指针。
1.2 重载与默认参数：编译器是怎么“选人”的
理解了参数传递，函数重载才能看明白。同一个函数名可以对应多个不同签名的版本，编译器根据调用点的实参类型去挑选最合适的一个。
void print(int v) { std::cout << "int: " << v << "\n"; } void print(double v) { std::cout << "double: " << v << "\n"; } void print(const std::string& s) { std::cout << "string: " << s << "\n"; }print(42) 选第一版，print(3.14) 选第二版，print("hello") 会先通过标准转换把字符串字面量变成 std::string，再选第三版。编译器内部有一套“重载决议”规则，简单说就是：精确匹配优于标准转换，标准转换优于用户定义转换。这套规则平时不用背得很细，但有一个坑必须知道——如果同时提供一个 int 版本和一个 long 版本，调用 print(42) 总是选 int，因为精确匹配优先。当你后面写的函数越来越多，重载决议报出“有多个重载函数与该调用匹配”的歧义错误时，先别慌，排查的优先级永远是：有没有精确匹配的版本、有没有因为隐式转换让两个版本变得一样好。
默认参数和重载经常组合使用，但有个细节特别容易踩：默认参数只能在声明或定义中的一处给出，不能两边都写。
// 头文件里的声明 void init(int size, int flag = 0); // 源文件里的定义 void init(int size, int flag) { // 不要在定义处再次写 = 0 }如果你在声明里写了默认参数，又在定义里再写一次，某主流编译器通常会直接报错。这个明明写对一次就能过、写两次反而过不了的规则，是考试题和面试题都很爱出的点，实际项目中我也真的见过同事因此反复编译失败。
2. 内存模型：理解指针和引用之前的必修课
2.1 栈与堆：你的变量到底住在哪里
程序运行时的数据内存大致分几个区域，初学者最需要先分清的是栈和堆。可以做一个不太严谨但足够直观的类比：栈是办公桌上随手可用的便签纸，用完即弃，放上去的顺序和拿下来的顺序严格相反；堆则是仓库里的货架，你需要登记申请才能占一个格子，用完必须自己还回去。
void stack_example() { int local_value = 0; // 栈上分配 } // 离开作用域，栈帧回收，无需手动处理 void heap_example() { int* p = new int(100); // 堆上分配 delete p; // 必须手动释放 p = nullptr; // 释放之后置空，防止误用 }栈上的局部变量在离开作用域时自动销毁，这是C语言时代就有的机制。堆上的内存则必须配对 new/delete 或 new[]/delete[]，一旦你 new 了却忘了 delete，这块内存直到程序结束都不会被归还，积累多了就是内存泄漏。
我见过很多新手问：“为什么不能全都用堆，省得考虑栈大小？”答案在于生命周期。栈变量的生命周期跟着作用域走，清晰但短暂；堆变量的生命周期可以一直延续到手动释放甚至程序结束。一个函数里创建、需要返回给调用方继续使用的数据，如果数据量不大又不涉及多态场景，返回“值”本身通常更省心，只有数据量大或结构复杂时才值得用指针/引用在外面传递。
另一个新手常混淆的点是 new int(100) 和 new int[100] 的区别。前者申请一个 int 的空间并初始化为 100，后者申请 100 个 int 的连续空间。释放方式也不同，一个是 delete p，一个是 delete[] p。混用 delete 和 delete[] 在部分平台上可能不立刻报错，但属于未定义行为，后续极其难排查。
2.2 指针与引用：看似相似，用途完全不同
指针和引用的底层实现往往大同小异，这是它们让人困惑的根源。但语义上两者完全是两种工具，我建议直接按下面的分工来记忆：
- 引用：必须初始化、不能重新绑定，本质是“另一个变量的别名”。它天然表达“我操作的就是那个东西本身，它一定存在”。
- 指针：可以不初始化、可以重新指向别的地址、可以为空。它天然表达“我可能没有对象，也可能中途换一个对象”。
在接口设计中，这条分工意味着：能传引用优先传引用，尤其是只读访问一律用 const T&；必须表达空值或需要修改指向时，再用 T*。这个原则几乎适用于所有现代C++代码规范。
void read_only(const std::string& s) { // 只读访问，用 const 引用，避免复制 } void maybe_set(int* p) { if (p) { *p = 100; } }悬空问题是本节的重头戏。返回局部变量的引用，或者在对象销毁后继续使用指向它的指针，都是初学者特别容易犯的错：
int& dangling_ref() { int local = 42; return local; // 危险：函数返回后 local 已被销毁 }这段代码编译时往往会得到一条警告，但一些编译器配置下可能只是警告而不是错误。运行时结果可能是42，也可能是随机值，甚至程序直接崩溃。这就是典型的未定义行为。排查这类问题没有捷径，我自己的习惯是在脑子里追踪每一块内存的“所有权”：这块内存归谁所有，谁负责释放，是否有其他指针/引用在对象生命周期结束后仍然握着它。这个问题如果现在不建立意识，后面学智能指针时还会反复吃亏。
3. 新手必经之劫：构造函数、析构函数与RAII
3.1 构造与析构：对象生死的钩子
类的作用不只是把数据和函数打包，更重要的作用是接管资源的生命周期。构造函数在对象创建时执行，析构函数在对象销毁时执行，而对象销毁的时机又分为两种情况：栈上对象在离开作用域时自动析构，堆上对象在你 delete 时析构。
class Resource { public: Resource() { std::cout << "Resource acquired\n"; } ~Resource() { std::cout << "Resource released\n"; } }; void lifecycle() { Resource r; // 构造 } // 离开作用域，析构，自动调用对于栈上的对象，这个机制非常可靠，即使函数中间有 return、有异常导致提前跳出作用域，析构函数也一定会被调用。这一点正是 C++ 资源管理的基石。你只需要把构造和析构成对写好，剩下的交给编译器。
但如果你在堆上创建对象，情况就不一样了：
void lifecycle_bad() { Resource* p = new Resource; // 如果这里抛出了异常，delete 永远不会执行 delete p; }new 出来的对象不会自动析构，必须手动 delete。一旦中途异常，delete 那行就执行不到，资源就泄漏了。这暴露了手动管理堆对象的脆弱性，于是就有了 RAII。
3.2 RAII：让资源管理成为肌肉记忆
RAII（Resource Acquisition Is Initialization）这个名词第一次见会觉得很绕，其实核心思想一句话就能讲清楚：把资源的获取放在构造函数里，把资源的释放放在析构函数里，然后让对象自己在栈上生、在栈上死。
举一个最贴近日常的例子。文件操作如果你用原生接口：
void read_file_bad(const std::string& path) { FILE* f = fopen(path.c_str(), "r"); if (!f) return; // 读文件逻辑... // 万一中间 return 了或者出异常了，fclose 就没执行 fclose(f); }如果换成标准库的 fstream 对象，它是栈上对象，离开作用域会自动关闭底层文件句柄。你不需要担心每个 return 分支有没有写关闭代码，这就是 RAII 的价值。智能指针也是同样的思路：shared_ptr 和 unique_ptr 都是栈上对象，它们在析构时自动 delete 所管理的堆内存。本讲我们还不深入所有权语义，但你现在至少应该形成这个条件反射：看到 new，第一反应不是“我要记得 delete”，而是“我应该用 RAII 把它包起来”。
有了 RAII 的概念，再回头看前面的 IntStack 代码，你就能发现栈类的析构函数就是天然的容器清理器。这也是这一讲要传递的核心思想：类的封装不只是为了好看，是为了让资源生命周期和对象生命周期绑定。
4. 实操演示：手写一个带完整生命周期的栈类
4.1 从零实现：构造函数、析构函数、深拷贝
前面讲的都是概念，现在完整走一遍代码。我们实现一个基于动态数组的整型栈，重点不是栈算法本身，而是让每个成员函数都体现正确的内存管理。
#include <iostream> class IntStack { private: int* data; int size; int capacity; void expand() { int newCapacity = capacity == 0 ? 4 : capacity * 2; int* newData = new int[newCapacity]; for (int i = 0; i < size; ++i) { newData[i] = data[i]; } delete[] data; data = newData; capacity = newCapacity; } public: IntStack() : data(nullptr), size(0), capacity(0) {} explicit IntStack(int initialCapacity) : data(new int[initialCapacity]), size(0), capacity(initialCapacity) {} ~IntStack() { delete[] data; } void push(int value) { if (size >= capacity) { expand(); } data[size++] = value; } void pop() { if (size > 0) { --size; } } int top() const { return data[size - 1]; } int count() const { return size; } bool isEmpty() const { return size == 0; } }; int main() { IntStack s; s.push(10); s.push(20); s.push(30); while (!s.isEmpty()) { std::cout << "top=" << s.top() << ", count=" << s.count() << "\n"; s.pop(); } return 0; }这个类如果到此为止，看起来能跑，但隐藏着一个致命问题：它没有自定义拷贝构造函数和拷贝赋值运算符。当你写出下面这样的代码时，程序大概率会在退出时崩溃：
IntStack a; a.push(1); IntStack b = a; // 默认拷贝构造：逐位复制成员默认拷贝构造会把 b 的 data 指针复制为与 a 的 data 指针相同的地址。结果是 a 和 b 的 data 指向同一块内存，两个对象析构时都执行 delete[] data，同一块内存被释放两次，这是典型的 double free。修复方法就是实现深拷贝：为目标对象单独申请一块内存，把源对象的内容逐个复制过来。
IntStack(const IntStack& other) : data(new int[other.capacity]), size(other.size), capacity(other.capacity) { for (int i = 0; i < size; ++i) { data[i] = other.data[i]; } } IntStack& operator=(const IntStack& other) { if (this != &other) { delete[] data; size = other.size; capacity = other.capacity; data = new int[capacity]; for (int i = 0; i < size; ++i) { data[i] = other.data[i]; } } return *this; }赋值运算符里有几个细节值得展开。第一是自赋值检查，如果写 s = s，没有 this != &other 的判断，先 delete 后复制就会把自己数据清空。第二是复制前先 release 旧资源，否则老内存就会泄漏。第三是 return *this，这样才能支持连续赋值写法。这三条是 C++ 拷贝赋值运算符的黄金规范。
不过更严谨地说，上面的赋值运算符还有异常安全问题：如果 new int[capacity] 抛出异常，对象已经处于 release 但没复制成功的中间状态。更稳的写法是先用临时对象接收拷贝，再交换数据，也就是 copy-and-swap（复制并交换）惯用法。这个技巧初学阶段可以只做了解，但至少要知道“先释放再申请”不是最安全的那一版。真正定义析构函数的类，一定要同时考虑拷贝构造和拷贝赋值，这就是著名的三法则（Rule of Three）：如果一个类需要自定义析构函数，那么它通常也需要自定义拷贝构造函数和拷贝赋值运算符。
4.2 运行验证与内存观察
把完整代码编译运行，输出应该是：
top=30, count=3 top=20, count=2 top=10, count=1这只是逻辑正确。内存是否正确的验证办法，如果是 Linux 环境，可以用 valgrind 工具来跑：
g++ -g -o stack_demo stack_demo.cpp valgrind --leak-check=full ./stack_demovalgrind 会报告有没有内存泄漏、有没有非法读写、有没有重复释放。我强烈建议每个新手都跑一次这个工具，它能把“模糊的内存恐慌”变成“具体的代码位置”。在我的使用经验里，valgrind 给出的报错里最有价值的就是类似 “Invalid read of size 4” 和 “Address ... is 0 bytes after a block of size ... alloc'd” 这类信息，它会直接告诉你哪一行读越界了。
如果你的环境是 Windows 上的 Visual Studio，可以把 _CRTDBG_MAP_ALLOC 定义打开，用 C 运行库的调试堆来检测泄漏。不过最省事的办法还是尽早接触带 AddressSanitizer 的编译选项：
g++ -fsanitize=address -g -o stack_demo stack_demo.cpp用 AddressSanitizer 跑一遍，只要有越界、泄漏或 double free，它会用红色报错信息直接指出问题代码位置。这套工具链是我带新人时最推荐的起步组合：先用 -Wall -Wextra 打开警告，再用 -fsanitize=address 跑运行时检查。
5. 常见问题与排查技巧实录
在学习这一讲内容的过程中，新同学最常撞上几个问题。下表是按我实际带人的经验总结出来的速查表，每一条都对应真实出现过的场景。
| 现象 | 根本原因 | 处理方式 |
|---|---|---|
| 函数里交换了变量，外面没变 | 值传递复制副本，形参是独立格子的拷贝 | 改为引用传递 void f(int&, int&) |
| 编译报错：默认参数重复指定 | 声明和定义里都写了默认值 | 只在声明处写默认参数，定义处不写 |
| 返回局部变量地址，运行结果时好时坏 | 栈内存已回收，悬空指针/引用的未定义行为 | 改为返回值，或用堆对象+智能指针 |
| new 出来的对象 printf 正常，但程序退出时崩溃 | 没有成对 delete，或释放时机不对 | 检查所有 new 路径是否都有对应 delete，优先 RAII |
| 两个对象互相赋值后，运行时报 double free | 浅拷贝导致两个对象共享同一块内存 | 实现深拷贝构造 + 拷贝赋值，或直接禁用拷贝 |
| delete p 后 p 不为空，判断 p 失效 | 释放内存并不会清空指针变量本身 | 释放后立即置空，但更要避免“释放后判空再用”的写法 |
| 使用未初始化的指针，程序随缘崩溃 | 指针未绑定任何合法内存就解引用 | 指针声明时务必初始化，不确定目标时先置 nullptr |
这些错误里最隐蔽的是第一个和第六个的组合：函数参数该用引用没用引用，加上指针未初始化，两错叠加，排查时往往会绕很久。我的建议是写任何一行涉及指针或引用的代码前，先问自己一个问题：“这个变量到底指向谁？它指向的对象生命周期到什么时候为止？”把这个问题养成习惯后，很多崩溃会直接在学习阶段被拦截掉。
再补充两个我在实际开发中积累的小技巧。第一，在调试阶段把析构函数里加一行输出，观察对象的创建和销毁顺序，这对理解栈上对象的生命周期非常有帮助，调试完再删掉。第二，永远不要用 reinterpret_cast 把整数转换成指针来自造地址，除非你在写嵌入式寄存器操作，否则那基本等于告诉编译器“我不在乎安全”。
6. 本讲内容在系列里的位置与衔接建议
这一讲的名字虽然是“基础（3）”，但它实际承担的任务是承上启下。承上：前两讲的变量、函数、流程控制在内存模型里有了根；启下：下一讲开始讲继承、多态时，你会频繁接触虚函数和基类指针，而为了安全销毁派生类对象，基类析构函数必须声明为 virtual。如果这一讲你没有建立起“对象生死时机”的敏感度，到多态那一讲看到“基类析构函数不写 virtual 就泄漏”的警告时，就会觉得那是某种玄学，而不是一个顺理成章的设计问题。
我个人的建议是，在看下一讲之前，先把你学过的所有结构体、类代码都拿来做一次三法则检查：这个类有没有管理资源？有没有自定义析构函数？如果没有自定义析构，那复制行为是否安全？如果有自定义析构，拷贝构造和拷贝赋值是否都实现了？这三步检查练熟之后，再进入多态专题，你的代码会比同龄学习者坚实得多。
最后分享一个小习惯，是我早年踩过多次坑之后固定下来的。写完任何一个类，不管是工程代码还是学习 Demo，我都会先编译运行，然后马上跑一遍 AddressSanitizer，再想一遍“这个类的对象如果被复制会发生什么”。这个过程只需要几分钟，但能拦截掉一大批内存相关的问题。这个习惯建议你现在就养成，它会让你在后面的指针进阶、容器源码阅读、多线程编程里都少熬夜。
