接口库与对象库：INTERFACE、OBJECT库类型、纯头文件库管理
说到 CMake 的库类型，很多人第一反应就是 STATIC 和 SHARED。嗯，这没错，但实际项目中还有两种特殊类型——INTERFACE 和 OBJECT，它们解决的是「纯头文件库」和「编译对象复用」这两个痛点。我个人习惯把这两种类型称为「轻量级库」，因为它们不产生真正的 .a 或 .so 文件。
一、INTERFACE 库：纯头文件的最佳归宿
先问一个问题：如果你的项目里有一个只包含头文件的模块（比如一些数学工具函数、模板类），你该怎么用 CMake 管理它？
很多新手会直接写 add_library(my_math STATIC empty.cpp)，然后塞一个空源文件。这太别扭了。INTERFACE 库就是为这种场景设计的。
add_library(my_math INTERFACE)
target_include_directories(my_math INTERFACE ${CMAKE_CURRENT_SOURCE_DIR}/include)
target_compile_features(my_math INTERFACE cxx_std_17)
看到没？INTERFACE 库没有源文件，它只传递「接口要求」。说白了，它就是个标签，告诉链接它的目标：「你需要这些 include 路径、这些编译特性、这些宏定义。」
核心理解： INTERFACE 库不产生任何构建产物。它只负责传播使用要求（Usage Requirements）。
我在项目中遇到过这样一个场景：我们有一个跨平台的日志库，全部是头文件实现。用 INTERFACE 库管理后，其他模块只需要 target_link_libraries(module PRIVATE logger)，就能自动获得所有头文件路径和必要的编译选项。干净利落。
二、OBJECT 库：编译一次，多次链接
OBJECT 库就更有意思了。它编译源文件，但不打包成静态库或动态库，而是生成一堆 .o 文件。这些 .o 文件可以被其他目标直接链接进去。
为什么会需要这个？我举个例子你就明白了。
假设你有一个模块，它既需要被打包进静态库供外部使用，又需要被单元测试链接。如果用 STATIC 库，每次修改都要重新编译整个 .a。用 OBJECT 库，你可以把编译好的 .o 文件同时喂给静态库和测试程序。
add_library(my_core OBJECT
src/core.cpp
src/utils.cpp
src/parser.cpp
)
# 这个 OBJECT 库可以被多个目标复用
add_library(my_static STATIC $<TARGET_OBJECTS:my_core>)
add_executable(my_test $<TARGET_OBJECTS:my_core> test_main.cpp)
注意那个 $<TARGET_OBJECTS:my_core> 语法，这是生成器表达式，专门用来引用 OBJECT 库的编译产物。
小技巧： OBJECT 库的源文件只编译一次。如果你的项目有多个目标依赖同一组源文件，用 OBJECT 库能显著减少编译时间。我曾经在一个 CI 流水线里，用 OBJECT 库把构建时间从 12 分钟降到了 7 分钟。
三、纯头文件库的管理策略
纯头文件库在 C++ 项目中越来越常见，尤其是模板库和轻量级工具库。管理它们有几个要点：
- 使用 INTERFACE 库：这是最标准的方式，CMake 官方也推荐。
- 明确版本号：即使是纯头文件，也要有版本管理。可以在头文件里定义版本宏。
- 处理依赖传递：如果纯头文件库依赖其他库，用
target_link_libraries传递。
# 一个完整的纯头文件库示例
add_library(my_template_lib INTERFACE)
# 设置版本
target_compile_definitions(my_template_lib INTERFACE
MY_TEMPLATE_LIB_VERSION_MAJOR=1
MY_TEMPLATE_LIB_VERSION_MINOR=2
)
# 传递依赖
target_link_libraries(my_template_lib INTERFACE
fmt::fmt
spdlog::spdlog
)
# 安装头文件
install(DIRECTORY include/ DESTINATION include)
install(TARGETS my_template_lib EXPORT MyTemplateLibConfig)
避坑指南： 我曾经犯过一个错误——在 INTERFACE 库上用了 target_sources 添加头文件。这其实没必要，因为 INTERFACE 库不编译源文件。正确的做法是用 target_include_directories 指定头文件路径，让使用者自己去发现头文件。
四、知识体系结构图
下面这张图帮你理清 INTERFACE 库和 OBJECT 库在整个 CMake 构建体系中的位置：
五、实际项目中的选择建议
说了这么多，到底什么时候用哪种？我根据自己的经验给你几个判断标准：
| 场景 | 推荐类型 | 原因 |
|---|---|---|
| 纯头文件模板库 | INTERFACE | 不需要编译，只传递接口 |
| 需要被多个目标链接的源文件 | OBJECT | 避免重复编译，节省时间 |
| 对外发布的 SDK | STATIC 或 SHARED | 需要明确的二进制产物 |
| 单元测试与生产代码共享源文件 | OBJECT | 编译一次，链接两处 |
| 仅传递编译选项和宏定义 | INTERFACE | 轻量级，无副作用 |
个人经验： 我一般这样组织项目——核心算法模块用 OBJECT 库，方便测试和静态库打包；外部接口层用 INTERFACE 库，只暴露头文件和 API；最终交付用 STATIC 或 SHARED 库。这样分层清晰，构建也快。
嗯，关于 INTERFACE 和 OBJECT 库，核心就是这些。你想想看，它们其实解决的是同一个问题——「如何更高效地管理代码和编译产物」。只不过 INTERFACE 偏向接口传递，OBJECT 偏向编译对象复用。理解了这一点，你在实际项目中就能灵活运用了。
公众号:蓝海资料掘金营，微信deep3321