前 15 章我们一件一件打磨工具，这一章把它们全部装回同一张工作台——从编辑到文档，看一条 C++ 工程如何一站一站跑完全程
核心方法论：工欲善其事，必先利其器
「工欲善其事，必先利其器。但利其器的终点不是收藏工具，而是让每一件工具在正确的环节、以正确的方式出场。这一章我们不造新东西，只做一件事：把前 15 章走过的路摊开成一张全景图，让你在需要的时候，能立刻想起该拿起哪一件。」
回到第 1 章 1.3 节，我们画过一张"六环节生命周期表"：编辑 → 编译 → 构建 → 包管理 → 测试 → 调试。当时表格里的每个词都只是名词，代表工具也仅限"听说过名字"。15 章之后，这六个环节每一个都有了具体的章节、具体的命令、具体的坑。而且这张表还应该再长两行——性能分析（第 15 章）和文档生成（第 12 章）：它们是真实工程里"发布之前"和"发布之后"都要做的事，第 1 章时我们还没能力给它们安排位置。
把第 1 章的旧表和今天的全景并排看，差别一目了然——每一行的"现在"列，都是你亲手跑过的命令：
| 环节 | 第 1 章时的印象 | 现在的掌握程度 | 支撑章节 |
|---|---|---|---|
| 编辑 | VS Code、Vim | 编辑器 + CMake 管理的工程结构 | 贯穿全书、第 2 章 |
| 编译 | GCC、Clang、MSVC | g++、-std、多版本 GCC 切换 | 第 3、4 章 |
| 构建 | CMake、Make | cmake -S . -B build 两步走 | 第 2 章 |
| 包管理 | vcpkg、Conan | vcpkg 清单模式、triplet | 第 5 章 |
| 测试 | GoogleTest | gtest 断言 + lcov 覆盖率 | 第 9 章 |
| 调试 | GDB | 断点、watch、core dump 分析 | 第 14 章 |
| 性能 | —— | perf / gprof 热点定位 | 第 15 章 |
| 文档 | —— | Doxygen + Graphviz 调用图 | 第 12 章 |
用一条命令接一条命令的方式，把全链路走一遍。假设 demo_app 工程的 CMake 与 vcpkg 都已配好（怎么配，看第 2、5 章）：
# 一条 C++ 工程的完整生命周期，从左到右一站一站走
vim src/main.cpp # 1. 编辑：写代码（贯穿全书）
cmake -S . -B build # 2. 构建：读 CMakeLists.txt 生成构建文件（第 2 章）
cmake --build build # 3. 编译：调用 g++ 把源码变成可执行文件（第 3、4 章）
./build/demo_app # 4. 运行：先看现象（第 13 章讲了它依赖哪些库）
ctest --test-dir build --output-on-failure # 5. 测试：自动化断言（第 9 章）
gdb ./build/demo_app # 6. 调试：出问题就停住看现场（第 14 章）
perf stat ./build/demo_app # 7. 性能：慢了就量一量热点（第 15 章）
doxygen Doxyfile # 8. 文档：从注释生成 HTML 文档（第 12 章）再看这些工具在一个真实工程目录里的落点——每个文件都有它服务的环节，这正是"工具链"这个名字的含义：
demo_app/
├── CMakeLists.txt # 构建：CMake 的"图纸"（第 2 章）
├── vcpkg.json # 包管理：声明依赖清单（第 5 章清单模式）
├── Doxyfile # 文档：Doxygen 配置（第 12 章）
├── src/
│ ├── main.cpp # 编辑：源码
│ └── config.cpp # 编译、链接的对象（第 3、13 章）
├── include/ # 头文件路径（第 4 章环境变量、第 13 章 -I）
├── tests/
│ └── test_core.cpp # 测试：gtest 用例（第 9 章）
└── build/ # out-of-source 构建目录（第 2 章）这张图就是第 16 章的地基：后面每一节都是在给图上的某一站"贴标签"——16.2 逐站回顾，16.3 把它们串起来，16.4 讲出了问题怎么定位到站，16.6 给一张可以打印的速查表。
从第 2 章到第 15 章，我们一共经过了 14 个站点（算上第 4 章的环境变量）。每一站解决一个具体问题。回顾的最佳方式不是重读代码，而是做到两件事：一句话说清它解决什么问题，一条命令记住它怎么用。
先按"问题 → 工具"的方向把整条线捋一遍——这张表是 16.6 速查表的"人话版"，帮你建立记忆锚点：
| 站点 | 章节 | 一句话：它解决什么问题 |
|---|---|---|
| CMake | 第 2 章 | 用声明式 CMakeLists.txt 调度"编什么、按什么顺序编" |
| GCC / g++ | 第 3 章 | 把 C++ 源码翻译成机器码，并走完预处理、汇编、链接全程 |
| 环境变量 | 第 4 章 | 让编译器在"系统默认之外"找到头文件和库，还能切换 GCC 版本 |
| vcpkg | 第 5 章 | 一条命令下载、编译、安装第三方库，并管好依赖版本 |
| jsoncpp | 第 6 章 | 读写 JSON 数据，把文本变成 C++ 对象树再变回去 |
| spdlog | 第 7 章 | 分级、可落盘、多线程安全的日志，替代 printf 打天下 |
| pistache | 第 8 章 | 用 C++ 直接写 REST 服务，把业务逻辑暴露成 HTTP 接口 |
| gtest | 第 9 章 | 自动化单元测试 + 覆盖率，让"改坏了"在第一时间被抓住 |
| gRPC | 第 10 章 | 跨语言、高性能的远程调用，用 .proto 文件描述接口契约 |
| POCO | 第 11 章 | 一站式通用库：网络、JSON、数据库都给你现成的实现 |
| Doxygen | 第 12 章 | 从注释生成 API 文档和调用图，文档与代码永不失步 |
| 静态/动态库 | 第 13 章 | 把代码打包成可复用的 .a / .so，并理解链接与符号的规则 |
| GDB | 第 14 章 | 让程序在任意一行停住，观察变量、揪出崩溃的凶手 |
| perf / gprof | 第 15 章 | 用数据回答"程序的时间到底花在哪"，而不是靠猜 |
每条命令都是对应章节的真实用法——把它们串起来背，就是一本"工具链口诀"：
# 第 2 章 CMake：configure + build 两步走
cmake -S . -B build
cmake --build build
# 第 3 章 GCC：源码安装一条龙（gcc-5.1.0 时代）
./contrib/download_prerequisites
./configure --prefix=/opt/gcc-5.1.0 --enable-languages=c,c++ --enable-checking=release --disable-multilib
make -j$(nproc) && sudo make install
# 第 4 章 环境变量：多版本 GCC 按需切换（Red Hat 系 SCL）
scl enable devtoolset-7 bash
# 第 5 章 vcpkg：指定 triplet 安装依赖
./vcpkg/vcpkg install jsoncpp:x64-linux# 第 12 章 Doxygen：生成文档两步
doxygen -g # 1. 生成 Doxyfile 配置模板
doxygen Doxyfile # 2. 按配置生成 HTML 文档
# 第 13 章 链接：看清依赖与符号
ldd ./demo_app # 运行时依赖了哪些 .so
nm -C ./libfoo.a # 库里定义了哪些符号（T=有实现，U=缺实现）
# 第 14 章 GDB：事后分析 core dump
gdb ./demo_app core
# 第 15 章 perf：整体概要 + 热点采样
perf stat ./demo_app
perf record -g ./demo_app && perf report注意到没有：第 6、7、8、9、10、11 章的"工具"都是库，它们不产生独立命令，而是通过 target_link_libraries 进入你的工程（jsoncpp_lib、spdlog::spdlog、GTest::gtest_main……）。这就是 C++ 生态和脚本语言生态最大的不同：库要链接，链接就要懂第 13 章的规则。
光回顾不够，我们把工具串起来。场景：一个命令行小工具 demo_app——用 jsoncpp 从 config.json 读配置、用 spdlog 记日志、核心函数用 gtest 测过、注释用 Doxygen 出文档。这就是"最小但五脏俱全"的真实工程形态：它不炫技，但每一个文件都能在本书找到出处。
第一步，工程结构。注意 vcpkg.json 用清单模式把三个依赖都声明清楚——这是第 5 章官方推荐的做法：
demo_app/
├── CMakeLists.txt # 第 2 章：构建图纸
├── vcpkg.json # 第 5 章：依赖清单（清单模式）
├── Doxyfile # 第 12 章：文档配置
├── config.json # 第 6 章：运行时读取的配置
├── src/
│ ├── main.cpp # 入口：读配置 + 记日志 + 调核心函数
│ └── config.cpp # 核心函数 compute 的实现（第 9 章要测它）
└── tests/
└── test_core.cpp # 第 9 章：gtest 用例// vcpkg.json —— 声明依赖，clone 下来 vcpkg install 一跑就绪（第 5 章）
{
"name": "demo-app",
"version": "1.0.0",
"dependencies": [ "jsoncpp", "spdlog", "gtest" ]
}第二步，CMakeLists.txt 核心片段——每一行都能在对应章节找到出处，这就是"全书收尾"的意义：
# CMakeLists.txt（第 2 章语法 + 第 5 章 vcpkg + 第 6/7/9 章库集成）
cmake_minimum_required(VERSION 3.16)
project(demo_app CXX)
set(CMAKE_CXX_STANDARD 17) # 第 1 章：C++17 起步最稳
# 三个库：jsoncpp（第 6 章）、spdlog（第 7 章）、gtest（第 9 章）
find_package(jsoncpp CONFIG REQUIRED)
find_package(spdlog REQUIRED)
find_package(GTest REQUIRED)
add_executable(demo_app src/main.cpp src/config.cpp)
target_link_libraries(demo_app PRIVATE jsoncpp_lib spdlog::spdlog)
# 测试目标（第 9 章：GTest::gtest_main 提供现成 main）
enable_testing()
add_executable(test_core tests/test_core.cpp src/config.cpp)
target_link_libraries(test_core PRIVATE GTest::gtest_main)
include(GoogleTest)
gtest_discover_tests(test_core) # 自动把每个 TEST 注册成 ctest 用例第三步，把四个环节的命令串成一条流水线——配置时带上 vcpkg 工具链文件，之后的每一步都不需要再操心依赖：
# 1. 配置：-DCMAKE_TOOLCHAIN_FILE 指向 vcpkg（第 5 章）
cmake -S . -B build -DCMAKE_TOOLCHAIN_FILE=$HOME/vcpkg/scripts/buildsystems/vcpkg.cmake
# 2. 构建（第 2 章 + 第 3 章编译器）
cmake --build build
# 3. 测试（第 9 章：ctest 跑全部用例）
ctest --test-dir build --output-on-failure
# 4. 文档（第 12 章：生成后用浏览器打开 doc/html/index.html）
doxygen Doxyfile第四步，看一眼 main.cpp 的骨架——jsoncpp 读配置、spdlog 记日志，两行注释就交代了"这个工具在干什么"（完整实现见第 6、7 章，这里只展示组合方式）：
// src/main.cpp：核心流程只有三步
#include <json/json.h> // 第 6 章：JSON 读写
#include <spdlog/spdlog.h> // 第 7 章：日志
#include <fstream>
int main() {
// 1. 读配置：文本 -> 树 -> 取值（第 6 章：parseFromStream）
Json::Value cfg;
std::ifstream fin("config.json");
std::string errs;
if (!Json::parseFromStream(Json::CharReaderBuilder(), fin, &cfg, &errs)) {
spdlog::error("config parse failed: {}", errs);
return 1;
}
int port = cfg["port"].asInt();
// 2. 记日志：分级输出（第 7 章）
spdlog::info("starting on port {}", port);
spdlog::set_level(spdlog::level::debug);
// 3. 调核心函数（第 9 章对它写测试，第 15 章对它做性能分析）
int result = compute(port);
spdlog::debug("result = {}", result);
return 0;
}任何真实工程都是"若干站点的组合"：demo_app 用了 4 个站点；换成网络服务，就把 jsoncpp/spdlog 换成 pistache（第 8 章）+ gRPC（第 10 章）；换成数据处理，就是 POCO（第 11 章）。工具是积木，组合方式由你的业务决定。
工具学了一堆，遇到问题时第一反应不应该是"逐个试工具"，而应该是先看报错长什么样，再决定用哪一章的工具。报错大致分四类，每类都有明确的主刀工具——这套"对号入座"的流程，比任何单一工具都值钱。
| 报错类型 | 典型现象 | 主刀工具 | 对应章节 |
|---|---|---|---|
| 编译错误 | 语法错、找不到头文件、-std 不支持 | g++ 报错信息 + 环境变量 | 第 3、4 章 |
| 链接错误 | undefined reference、cannot find -l | -l / -L、nm、ldd | 第 13 章 |
| 运行错误 | 崩溃、Segmentation fault、结果不对 | gdb、断点、core dump | 第 14 章 |
| 性能问题 | 慢、CPU 占用高、内存拷贝多 | perf、gprof、chrono 计时 | 第 15 章 |
编译错误最好认：报错里带"文件名:行号"，先看行号、再看错误类型。排查顺序也固定——先确认标准参数，再确认头文件路径，最后确认编译器版本：
# 编译错误长这样：main.cpp:8:5: error: 'cout' was not declared ...
g++ -std=c++17 src/main.cpp -o demo_app
# 排查三步：① 标准参数对不对 ② 头文件路径在不在 ③ 编译器版本对不对
g++ --version
echo $CPLUS_INCLUDE_PATH # 第 4 章：自定义头文件搜索路径
scl enable devtoolset-11 bash # 第 4 章：切到新版 GCC 再试链接错误在报错里看到 undefined reference 或 cannot find -l 就锁定第 13 章——它和编译错误本质不同：语法没问题，是"符号对不上号"。用 nm 和 ldd 两个探测器破案：
# 链接错误：/usr/bin/ld: ...: undefined reference to `compute(int)'
nm -C ./libfoo.a # 看库里有哪个符号：T=有实现，U=缺实现
ldd ./demo_app # 看运行时缺哪个 .so（=> not found 就是缺）
g++ main.o -L./lib -lfoo -o demo_app # -L 指路，-l 指名（第 13 章）运行错误是能编译、能链接，一跑就崩或结果不对。这时候上 gdb——编译时加 -g，崩溃后用 core dump 事后分析：
# 运行错误：Segmentation fault (core dumped)
ulimit -c unlimited # 打开 core 生成开关（第 14 章）
./demo_app # 崩溃瞬间留下现场快照 core
gdb ./demo_app core # 带上 core 文件直接定位崩溃现场
(gdb) bt # backtrace：看调用栈，谁调了谁、崩在哪一层最后一类性能问题没有报错，症状是"慢"。第 15 章的心法是：先量再优化——perf stat 看整体概要，perf record -g + perf report 找热点函数，90/10 法则提醒你绝大多数时间花在少数代码上。四类问题全部"对号入座"之后，剩下的就是执行：先分类，再选工具，让工具告诉你答案——这正是第 14 章柯南"真相只有一个"、第 12 章福尔摩斯"排除不可能"的方法论在工具链层面的落地。
16 章走完，你掌握的是一条"够用"的工程链路。但 C++ 的世界远不止这些。继续深入有三个方向：语言本身、生态工具、社区资源。它们不需要按顺序学，挑跟你工作最相关的先走。
方向一：语言本身。第 1 章讲过标准演进：C++11 是现代 C++ 的起点，C++17 是目前工程主流，C++20/23 带来了 concepts、协程、ranges、std::print 等新特性。切标准就是改一个参数的事——但先确认编译器版本，GCC 13 对 C++20/23 的支持才趋成熟：
# 同一份代码，换标准就是换一个 -std 参数（第 1、3 章）
g++ -std=c++17 demo.cpp -o demo # 保守：教程全系列基准
g++ -std=c++20 demo.cpp -o demo # 尝鲜：concepts / 协程 / ranges
g++ -std=c++23 demo.cpp -o demo # 最新：std::print 等实用改进方向二：生态工具。本书没有展开、但真实存在且值得认识的几件：Conan（另一个 C++ 包管理器，第 5 章提过，和 vcpkg 的取舍在它的官方文档里有对比）、Ninja（更快的构建后端，第 1 章提过，CMake 换生成器即可）、Boost（号称"准标准库"，功能最全的 C++ 库集合）、Catch2（另一个测试框架，第 9 章提过）、fmt（spdlog 的格式化底座，独立出来也是个好库）。上手成本都很低，因为套路你已经会了：
# Ninja：把 CMake 的构建后端从 Make 换成 Ninja（第 2 章知识直接复用）
cmake -S . -B build -G Ninja && cmake --build build
# Boost / Catch2：vcpkg 一条命令，第 5 章的流程原样照搬
./vcpkg/vcpkg install boost catch2方向三：社区与资料。几个公认的"权威第一站"：cppreference.com（标准库的权威参考，查 API 用它）、isocpp.org（C++ 标准与高质量文章）、Compiler Explorer（网页上直接编译运行代码，试语法神器）、GitHub 上各库的 issues 区（vcpkg 装不上、库报错时的第一现场）。学一个新库的通用套路，第 8 章学 pistache 时已经练过：官方 README → examples 示例 → issues 区，三步走完基本就能上手。
路线图不是必做清单。挑一个跟你工作最相关的方向，把它变成一个小工程，用 16.3 的流程再走一遍——工具是练出来的，不是看出来的。收藏 100 篇教程，不如亲手跑通一条命令。
最后，把 14 个站点压缩成一张表。打印出来贴在显示器边上：遇到问题先查表，再翻对应章节。这张表是全书唯一允许"不求甚解"的地方——它的价值在查得快，不在记得牢。
| 工具 | 章节 | 一句话用途 | 常用命令 / API |
|---|---|---|---|
| CMake | 第 2 章 | 声明式调度整个构建 | cmake -S . -B build |
| GCC / g++ | 第 3 章 | 编译 C++ 源码成机器码 | g++ -std=c++17 app.cpp -o app |
| 环境变量 | 第 4 章 | 让编译器找到非默认头文件/库 | export CPLUS_INCLUDE_PATH=/opt/include |
| vcpkg | 第 5 章 | 安装与管理第三方库 | ./vcpkg/vcpkg install jsoncpp |
| jsoncpp | 第 6 章 | JSON 解析与序列化 | Json::parseFromStream(...) |
| spdlog | 第 7 章 | 分级日志输出 | spdlog::info("hello {}", 42) |
| pistache | 第 8 章 | 用 C++ 写 REST 服务 | Http::listenAndServe(...) |
| gtest | 第 9 章 | 单元测试 + 覆盖率 | ctest --test-dir build |
| gRPC | 第 10 章 | 高性能远程调用 | protoc --grpc_out=. ... |
| POCO | 第 11 章 | 网络/JSON/数据库通用库 | ./configure --omit=Data/ODBC,MongoDB,PDF |
| Doxygen | 第 12 章 | 注释生成文档与调用图 | doxygen Doxyfile |
| 静态/动态库 | 第 13 章 | 打包与链接 .a / .so | ar rcs libx.a x.o |
| GDB | 第 14 章 | 断点调试与 core 分析 | gdb ./app core |
| perf / gprof | 第 15 章 | 定位性能热点 | perf stat ./app |
环境自检——换新机器时，一站一条命令确认"在位"。全部有输出，说明开发环境就绪，可以开工：
# 一站一条：全部有输出 = 环境就绪
g++ --version # 第 3 章：编译器
cmake --version # 第 2 章：构建系统
./vcpkg/vcpkg version # 第 5 章：包管理器
doxygen --help # 第 12 章：文档工具（--help 是官方确认的用法）
gdb --version # 第 14 章：调试器
perf --version # 第 15 章：性能工具（Linux）收尾动作——新工程从零到"能测、能出文档"的标准流程，全部命令都出自本书：
# 一次性准备：clone vcpkg 并引导（第 5 章）
git clone https://github.com/microsoft/vcpkg
./vcpkg/bootstrap-vcpkg.sh
# 每个新工程：声明依赖 -> 配置 -> 构建 -> 测试 -> 文档
vim vcpkg.json # 第 5 章清单模式
cmake -S . -B build -DCMAKE_TOOLCHAIN_FILE=$HOME/vcpkg/scripts/buildsystems/vcpkg.cmake
cmake --build build
ctest --test-dir build --output-on-failure
doxygen Doxyfile # 第 12 章第 1 章我们问"为什么学 C++"，第 16 章我们回答"用什么把 C++ 工程做出来"。工具链是外功，语言本身是内功——两条腿走路，才算真正入门。这一章是终点，也是起点：把这张全景图记在心里，以后无论遇到什么工程问题，你都知道该拿起哪一件工具。祝你在 C++ 的世界里，走得更远。
把左边的工具与右边"它解决的问题"配对：① gtest；② Doxygen；③ perf；④ vcpkg；⑤ GDB。候选：A. 让程序在任意一行停住观察变量；B. 自动化断言代码行为符合预期；C. 一条命令安装第三方库；D. 从注释生成 API 文档；E. 用数据回答程序时间花在哪。
回到 16.2 的"逐站回顾表"，每个工具都有一句话用途，对号入座即可。
① gtest → B（自动化断言，第 9 章）；② Doxygen → D（注释生成文档，第 12 章）；③ perf → E（性能热点，第 15 章）；④ vcpkg → C（安装库，第 5 章）；⑤ GDB → A（断点调试，第 14 章）。
下面三条报错分别属于哪一类（编译 / 链接 / 运行）？该用哪一章的工具排查？(a) main.cpp:12:5: error: 'cout' was not declared in this scope；(b) /usr/bin/ld: undefined reference to `compute(int)'；(c) Segmentation fault (core dumped)。
看报错关键词：带"文件名:行号"是编译期；带 ld / undefined reference 是链接期；Segmentation fault 是运行期。对应 16.4 的表格。
(a) 编译错误——第 3、4 章（检查 -std、include 路径、编译器版本）；(b) 链接错误——第 13 章（用 nm 查符号、ldd 查依赖、补 -l/-L）；(c) 运行错误——第 14 章（g++ -g 重新编译，gdb ./app core 看 bt）。
16.3 的 CMakeLists.txt 里，测试目标的集成少了四步，导致 ctest 跑不出用例。请补全：enable_testing() 之后还需要哪四步，才能让 gtest 的每个 TEST 自动注册成 ctest 用例？
回顾第 9 章的 CMake 集成：add_executable 测试目标、链接 GTest::gtest_main、include(GoogleTest)、gtest_discover_tests。
四步：add_executable(test_core tests/test_core.cpp src/config.cpp)、target_link_libraries(test_core PRIVATE GTest::gtest_main)、include(GoogleTest)，最后 gtest_discover_tests(test_core) 自动发现用例。之后 ctest --test-dir build --output-on-failure 就能跑全部测试。
动手实操：按 16.3 的 demo_app 结构，自己建一个最小工程并走完全流程。要求：① vcpkg.json 声明 jsoncpp/spdlog/gtest 三个依赖；② CMakeLists.txt 配好主程序与测试目标；③ 核心函数写一个 compute（比如把输入翻倍），并用 gtest 写 2 个用例（含一个故意失败的，观察 ctest 输出）；④ 用 Doxygen 生成文档，打开 doc/html/index.html 确认页面存在。把每条命令和关键输出记录下来。
命令全集在 16.3 和 16.6 的代码块里：cmake 配置（带 -DCMAKE_TOOLCHAIN_FILE）、cmake --build、ctest --test-dir build --output-on-failure、doxygen Doxyfile。gtest 断言宏用 EXPECT_EQ，第 9 章讲过。
关键步骤：① vcpkg.json 写 {"name":"demo-app","version":"1.0.0","dependencies":["jsoncpp","spdlog","gtest"]}；② CMakeLists.txt 照 16.3 片段；③ test_core.cpp 里 TEST(ComputeTest, Doubles) 用 EXPECT_EQ(compute(2), 4)，故意失败用例用 EXPECT_EQ(compute(2), 5)——ctest 会打印 FAILED 并给出期望/实际值，改回 4 后全部 PASS；④ doxygen -g 生成 Doxyfile（把 EXTRACT_ALL 设为 YES）再 doxygen Doxyfile，确认 doc/html/index.html 存在。全流程跑通，你就把 16 章的工具链真正"过"了一遍。