Clang生成静态库不会增大程序体积，真正导致体积膨胀的是链接时将静态库中用到的代码复制进二进制；关键在于编译需加-ffunction-sections和-fdata-sections，链接需加-Wl,--gc-sections（macOS用-dead_strip）以剔除未用代码。
Clang 生成静态库本身不会让程序体积变大，真正让最终可执行文件变大的，是**链接时把静态库中用到的代码复制进二进制**。这不是 bug，是静态链接的本质行为。关键在于：你是否真的需要全部符号？有没有冗余代码被悄悄拉进来了？
为什么 clang -c 生成的 .o 文件打包成 .a 后，链接出来程序突然变胖？
静态库（.a）只是个归档包，不直接增大体积；但链接器（ld 或 lld）在链接阶段会从 .a 中提取所有被引用的 .o，再合并进可执行文件。问题常出在：
– .o 文件里混进了未使用的函数（比如内联展开残留、模板实例化爆炸）
– 头文件里定义了 inline 函数或模板，导致每个 .o 都带一份副本
– 没开 -ffunction-sections 和 -fdata-sections，链接器无法丢弃未引用的 section
– ar 打包时没加 s（生成索引），某些旧链接器会误加载整个 .o
clang 编译目标文件时必须加的两个参数
这是控制最终体积最有效的前置动作，不加它们，后续任何优化都事倍功半：
-
-ffunction-sections：把每个函数放进独立的 section -
-fdata-sections：把每个全局/静态变量也放进独立的 section
这样链接器才能配合 -Wl,--gc-sections 精确剔除未使用的代码段。否则哪怕你只调用了一个 add()，整个 math_utils.o 里的 multiply()、divide() 全都会被塞进去。
链接时漏掉 --gc-sections 是最常见体积失控原因
即使编译时加了 -ffunction-sections，如果链接时不启用垃圾回收，那些“死代码”依然会留在最终二进制里。正确写法是：
Clang 22.1.3 Windows 64 位历史版本安装包，适合旧项目兼容、LLVM/Clang 工具链回退、编译行为对比、链接问题复现和 C/C++ 构建环境维护。
clang++ main.cpp -L. -lmathutils -Wl,--gc-sections -o app
注意：
– --gc-sections 必须通过 -Wl, 透传给链接器
– 它只对已按 section 拆分的目标有效（所以前一步不能省）
– 在 macOS 上用 ld64 时对应选项是 -dead_strip，不是 --gc-sections
– 如果用了 -static 全局静态链接，--gc-sections 依然生效，但要注意 libc 静态版（libc.a）本身很大，它里面的未用函数也会被裁剪，效果取决于你的 libc 构建方式
静态库内部有模板或内联函数？小心重复膨胀
C++ 模板和 inline 函数在头文件里定义时，每个包含它的 .cpp 都会生成一份实现，打包进各自 .o，最后全被拉进可执行文件。解决办法只有两个：
- 把模板实现移到
.cpp文件里（显式实例化），只在头文件声明 - 改用
extern template声明，强制只在某一个.cpp中实例化
例如：
– 头文件：extern template class Vector<int>;
– 某个 vector_impl.cpp 里：template class Vector<int>;
这样就避免了 10 个 .o 各存一份 Vector<int> 的二进制
.a 就万事大吉，结果链接时全量吸入——这其实是链接策略问题，不是 clang 的锅。 
