内存管理、对象生命周期与资源释放

17.1 本周学习重点

重点一是对象生命周期：构造、拷贝、移动、析构。重点二是资源管理策略：谁申请、谁释放、何时释放。

建议你从“避免裸指针滥用”开始，优先使用 RAII 思路，把资源释放交给对象生命周期管理。

17.2 核心示例

下面示例展示了资源与对象绑定后，退出作用域自动释放资源的思路。你可以把同样模式用到文件句柄、网络连接等资源上。

#include <memory>
#include <vector>
using namespace std;

class Buffer {
public:
    Buffer(size_t n) : data(new int[n]), size(n) {}
    ~Buffer() { delete[] data; }
private:
    int* data;
    size_t size;
};

int main() {
    vector<unique_ptr<Buffer>> blocks;
    blocks.push_back(make_unique<Buffer>(1024));
    blocks.push_back(make_unique<Buffer>(2048));
    return 0;
}

17.3 本周项目任务

为你当前项目中一个“频繁创建/销毁对象”的模块做生命周期审查：标记对象拥有者、资源释放时机和潜在泄漏点。

执行建议

• 先画对象关系图，再改代码。
• 把关键资源包装成类，避免散落的 `new/delete`。
• 每次改动后跑回归，确认行为一致。
• 记录至少 3 个内存风险与修复措施。

17.4 深度讲解：内存管理与对象生命周期

这一周真正拉开差距的，不是你写了多少行代码，而是你能不能把 内存管理与对象生命周期 变成稳定的方法。很多同学在学习新知识点时会出现同一个误区：把注意力全部放在语法表面，忽略了背后的设计决策。结果就是课堂示例能跑，稍微换一个场景就卡住。要解决这个问题，你需要建立“先结构后实现”的习惯。先写出目标、输入、输出、边界，再把规则翻译成代码。这个顺序看起来慢，但它能显著降低返工率，也能让你在后续模块扩展时保持稳定。

以 资源管理模块 为例，你在实现时至少要回答四个问题：第一，核心数据由谁拥有，谁负责更新；第二，异常输入如何处理，失败时如何回退；第三，哪些逻辑是可复用的，应该提取为函数或类；第四，如何证明当前实现是正确的。只要你能把这四个问题讲清楚，代码质量通常不会差。相反，如果这四个问题说不清，代码往往只是“刚好能跑”。第三、四阶段最重要的进阶能力，就是把“刚好能跑”升级成“可维护、可验证、可交付”。

另外，你要开始建立工程尺度的风险意识。任何一个看似小的遗漏，在项目后期都会放大。例如边界值漏测、接口契约不清晰、错误信息不可定位、文档更新滞后，这些问题在单个功能时影响有限，但一旦进入整合和发布阶段，就会显著拖慢节奏。建议你每完成一个功能点都做一次轻量复盘：这个改动影响了哪些模块？是否新增了隐式依赖？是否更新了说明文档和测试用例？把这些动作变成固定流程，你的稳定性会比只追求“写得快”提升更明显。

17.5 实战推进路径：从可运行到可交付

建议你用三步推进法完成本周任务。第一步是最小可运行版本：只保留核心流程，先确保主路径稳定闭环；第二步是稳定性增强：补齐输入校验、异常分支和边界处理；第三步是交付化整理：完善日志、文档、测试记录和版本说明。很多同学会直接跳到第二、三步，结果主流程本身不稳，后续所有优化都建立在不可靠基础上。先把主路径跑顺，是所有进阶工作的起点。

在开发节奏上，建议保持“小步改动、小步验证”。具体做法是每完成一个子目标就运行一次核心测试，并记录结果。如果一次改动跨越太大，问题出现时你很难快速定位。你可以把每次改动都限制在一个主题，例如“只改接口命名”“只改排序逻辑”“只补异常处理”。这种粒度控制会让调试效率提升很多，也更利于课堂展示和团队协作。项目实战中，能持续产出稳定小成果，通常比一次性大改更可靠。

评估本周完成度时，不要只看“功能是否存在”，要看“证据是否完整”。至少准备以下证据：功能演示截图或日志、三类测试（正常/边界/异常）结果、关键设计决策说明、已知问题清单和后续计划。这样你在做阶段复盘时，不会停留在“我感觉差不多”，而是有清晰依据说明“哪里做得好、哪里还要迭代”。第四阶段尤其强调可交付能力，证据链完整是核心标准。

• 最小版本先闭环，避免一开始堆叠过多需求。
• 每个改动点都要对应一条验证记录。
• 遇到复杂问题先拆小，再逐个击破。
• 每周至少沉淀 3 条可复用工程经验。

17.6 课堂问答与复盘模板

问：我总觉得自己写得慢，怎么办？
慢并不一定是坏事，关键看你是不是在做“有效慢”。如果你的慢换来了更低返工率、更少线上问题、更清晰结构，那这就是高质量节奏。真正需要避免的是“快写快坏、反复重写”。建议你记录每次 bug 的根因，如果重复错误明显减少，说明你的节奏是对的。

问：我怎么判断自己真的掌握了本周内容？
一个实用标准是：你能离开模板，向同学解释为什么这样设计，并且对方能复现你的流程。会写代码不等于会交付；能解释设计、验证结果、管理风险，才是更高层级能力。你可以尝试 1 分钟口头讲解：目标是什么、结构是什么、风险在哪里、如何验证通过。讲得清楚，通常就是真的掌握了。

问：如果测试失败，是先改代码还是先改用例？
先确认预期是否正确，再确认用例是否覆盖真实场景，最后才改代码。很多“改了半天还是错”的情况，本质是预期定义就不清晰。先把预期对齐，你的改动才有方向。项目实战中，先定义标准再实现，是避免混乱的关键。

复盘模板建议：第一，写出本周三个高频错误；第二，为每个错误写“触发条件、根因、修复动作、防复发规则”；第三，整理一页“下周启动清单”，包括接口约束、测试优先级、发布风险。坚持这种复盘方式，你会把经验沉淀成方法。方法一旦形成，进步会越来越快，而且更稳定。

17.7 自测清单

• 我能说清每个关键对象的生命周期。
• 我能指出资源泄漏最容易发生的位置。
• 我已替换掉高风险裸指针路径。
• 我准备了异常中断场景的释放验证。

返回 C++ 第四阶段