多阶段构建文档需清晰说明各阶段目的、输入输出及关键行为，用实际命令加注释替代理论描述，明确多文件依赖关系，并提供中间产物验证方法。
多阶段构建的文档记录，核心是让他人（或未来的自己）能快速复现、定位问题、理解依赖关系。不堆砌术语，不罗列命令，而是讲清“为什么这么走”和“每一步在干什么”。
明确划分阶段并标注输入输出
每个构建阶段单独成节，用统一格式说明：阶段名称、触发动作、输入文件、输出文件、关键行为。例如：
-
预处理：运行
gcc -E main.c，输入main.c，输出main.i；展开宏、插入头文件内容、处理条件编译指令 -
编译：运行
gcc -S main.i，输入main.i，输出main.s；将C语义翻译为对应平台的汇编指令 -
汇编：运行
gcc -c main.s，输入main.s，输出main.o；生成机器码，但地址未确定、符号未解析 -
链接：运行
gcc main.o utils.o -o app，输入所有.o和库文件，输出可执行文件app；解析函数调用、分配内存地址、合并段表
用实际命令+注释替代纯理论描述
避免只写“链接器负责符号解析”，而要给出带解释的命令示例：
gcc -v main.o utils.o -o myapp —— 加 -v 可看到链接器调用细节，如 collect2 如何查找 printf 在 libc 中的位置；若报错 undefined reference to 'add'，说明 utils.o 没参与链接，或 add 函数未定义（只有声明）。
记录多文件项目的依赖与分工
对含多个 .c 文件的项目，文档中需说明：
- 哪个文件含
main()（入口点） - 哪些
.h文件提供公共接口，是否用了#ifndef XXX_H保护 - 各
.c编译成独立.o的顺序无关，但链接时必须包含所有实现模块 - 如果某函数在
utils.h声明、在utils.c定义，则main.c只需包含头文件，不必知道实现细节
附上可验证的中间产物检查方法
告诉读者如何确认某阶段是否成功完成：
- 看
.i文件是否含展开后的stdio.h内容（搜索typedef或extern） - 用
file main.o确认是 ELF 格式目标文件，不是文本 - 用
nm main.o | grep add查看add符号是否为U（undefined）或T（defined in text section） - 用
ldd ./myapp检查动态链接依赖，确认是否遗漏libm.so等
不复杂但容易忽略
