C++ 学习的难点很少是“语法太多”，更常见的问题是知识被拆散：构建系统、对象模型、并发、调试和性能分析各自成立，却没有被放进同一个工程闭环。本文把这些历史记录整理成一条可重复执行的主线。
本文是站内历史文章的主题化重组稿，不替换任何原始文章。工具名称和命令会随版本变化，实际操作请以项目文档和当前环境为准。
先建立工程闭环
一个可维护的 C++ 项目至少应该形成下面这条闭环：
- 可重复构建：依赖、编译选项、安装规则和测试目标都能被明确描述。
- 可定位故障：崩溃、链接错误、内存问题和并发问题都有最小复现路径。
- 可验证正确性：单元测试、静态检查和运行时检查互相补充，而不是互相替代。
- 可解释性能：先测量，再决定是否优化；优化后用相同基准复测。
如果项目还不能稳定地回答“它在哪里失败、为什么失败、如何证明修好了”，继续添加功能通常只会放大问题。
推荐学习顺序
| 阶段 | 先掌握什么 | 产出的证据 |
|---|---|---|
| 构建 | CMake 目标、头文件、库、编译定义 | 一条从干净目录开始的构建命令 |
| 调试 | GDB、断点、调用栈、core dump | 最小复现和稳定的调试记录 |
| 资源 | RAII、智能指针、异常和对象生命周期 | 没有裸资源泄漏的局部设计 |
| 并发 | 锁、条件变量、线程生命周期 | 可解释的同步策略和压力测试 |
| 质量 | GoogleTest、静态分析、Valgrind | 测试与检查结果 |
| 性能 | perf、VTune、基准设计 |
优化前后可比较的数据 |
1. 构建先于技巧
先读 CMake 和 CMake Tools，重点不是记住所有命令，而是理解 target、依赖传播、生成器和安装边界。一个项目能否被另一个项目正确消费，通常比 IDE 里是否显示补全更重要。
2. 调试先于猜测
遇到崩溃时，先保留最小输入、编译模式、调用栈和版本信息，再使用 GDB 与 core dump 缩小范围。不要把“加一个打印”当成完整的调试方法：打印可能改变时序，也可能看不到已经失效的对象。
3. 生命周期是资源管理的主线
把 shared_ptr 与 lock_guard / unique_lock 放在同一条学习线上，是为了强调两个共同问题：谁拥有资源，谁负责释放；谁获取同步能力，谁负责释放。优先使用作用域表达所有权，避免让生命周期隐含在全局变量和裸指针中。
4. 质量工具形成互补
- GoogleTest：验证输入、输出和边界条件。
- 静态分析：尽早发现可疑 API、资源路径和风格问题。
- Valgrind：检查运行时非法访问、泄漏和未初始化数据。
- VTune：定位 CPU、内存和线程热点。
这些工具的结论必须结合代码语义解释。例如 Valgrind 报告“未初始化”并不自动意味着业务结果错误，但它通常值得追踪；静态分析给出警告也不等于缺陷，要记录误报或修复理由。
性能优化的正确姿势
性能分析指南 和 BehaviorTree.CPP 性能优化 可以合并成一个原则：基准必须代表真实工作负载。先记录输入规模、并发数、编译选项和硬件，再比较 wall time、CPU time、分配次数和缓存行为；只看一个总耗时，无法判断优化是否把瓶颈转移了。
一个可复用的实验记录模板：
场景：
输入规模：
编译器与选项：
运行次数：
中位数 / P95：
优化前：
优化后：
是否改变了功能语义：
每周复查清单
- 新增依赖是否有清晰的版本和用途？
- 是否能用一条命令从干净环境构建？
- 失败路径是否有测试或最小复现？
- 裸指针、锁和线程的释放责任是否明确？
- 性能结论是否有同条件的前后数据？
- 工具报告是否被转化为可执行的修复或已知例外？
按照这条路线学习，原始文章仍然可以作为逐题查阅的参考，而重组后的地图负责告诉你：下一步应该解决哪一类工程问题。