静态库生成关键在于符号可见性、ABI兼容与链接顺序对齐，而非仅产出.lib/.a文件；需确保头文件声明与实现匹配、模板显式实例化、运行时及标准库版本统一。
静态库不是“生成一个 .lib 文件”就完事的，而是要确保头文件、符号可见性、ABI 兼容性和链接顺序全部对齐——否则哪怕 lib 文件成功产出，链接时照样报 LNK2019 或运行时崩溃。
怎么用 MSVC 生成 .lib 文件（Windows + Visual Studio）
关键不是“怎么编译”，而是“怎么让编译器导出你想要的符号”。C++ 静态库默认不导出符号（和动态库不同），所以不用 __declspec(dllexport)，但必须保证函数/类定义可被外部看到。
- 项目类型选
Static Library (.lib)，不是Dynamic Library (.dll) - 源文件（
.cpp）里写实现，头文件（.h）里写声明——静态库不打包头文件，调用方必须自己#include - 不要在静态库工程里启用
/GL（全程序优化），它会禁用增量链接且与某些链接选项冲突；如需 LTO，用/LTCG配合最终可执行文件开启 - 输出路径默认是
$(IntDir)$(TargetName)$(TargetExt)，即Debug\mylib.lib这类，记得把该路径加进主工程的Additional Library Directories
Linux 下用 g++ 生成 .a 文件（等价于 Windows .lib）
.a 是 Unix-like 系统的静态库格式，本质是多个 .o 打包的归档，没有 Windows 那套“导出表”概念，但更依赖符号命名和链接顺序。
- 先编译为位置无关目标文件（尤其涉及模板或内联时）：
g++ -c -fPIC -std=c++17 util.cpp -o util.o - 再打包：
ar rcs libutil.a util.o helper.o——rcs表示创建、替换、索引，缺一不可 - 检查内容：
ar -t libutil.a看对象列表，nm -C libutil.a | grep MyFunc确认符号存在且未被优化掉 - 注意：如果静态库依赖 STL，调用方必须用相同标准库版本（
libstdc++vslibc++）和相同 C++ 标准（-std=c++17），否则链接时报undefined reference to `std::...
链接静态库时最常见的三个失败原因
90% 的“明明有 .lib/.a 却链接失败”问题，都卡在这三处，而不是路径或名字拼错。
立即学习“C++免费学习笔记（深入）”；
-
LNK2001 / undefined reference：函数在头文件中声明了，但对应.cpp没加入静态库工程，或该.cpp被误设为“不参与生成”（VS 中右键文件 → Properties → Exclude From Build = Yes） - 模板函数没实例化：静态库中只放了
template<typename t> void foo(T);</typename>声明，没在.cpp里写template void foo<int>(int);</int>，导致链接时找不到具体符号 - C++ 名字修饰不一致：调用方用了
/MD（动态链接 CRT），静态库用了/MT（静态链接 CRT），会导致std::string等类型布局不兼容，看似链接成功，运行时访问非法内存
跨平台静态库工程怎么组织才不至于后期崩溃
别幻想“一套代码到处编译成 .lib/.a 就能直接用”。ABI、异常模型、RTTI 开关、甚至 size_t 宽度都可能不同。
- 强制统一运行时：CMake 中设
set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded$:Debug>")，避免混用/MT和/MD - 禁用异常传播跨库边界：静态库内部用
try/catch吞掉异常，对外接口一律用错误码返回；否则throw从 .lib 抛出，在主程序 catch 时可能因栈展开信息缺失而 abort - 头文件里避免依赖编译器扩展：比如别用
__declspec(align(...))，改用alignas；别用__attribute__((packed))，改用#pragma pack+ 显式恢复
最麻烦的从来不是“怎么生成”，而是“怎么让别人能稳定链接并安全调用”——头文件要不要带实现、模板要不要显式实例化、是否暴露 STL 类型、运行时怎么对齐，这些决策一旦定下，改起来比重写模块还痛。
