C++ 项目构建与工程化面试题 —— 从 CMake 到包管理的实战问答

覆盖CMake核心概念(target/library/install)、第三方依赖管理(vcpkg/conan/FetchContent)、编译加速(ccache/unity build/分布式编译)、静态分析(clang-tidy/cppcheck)、CI/CD集成、交叉编译，20 道高频题附工程模板

发表于 2026/02/27

作者 xirain

27 分钟阅读

C++ 工程化能力是从”写代码”到”做项目”的分水岭——面试官问”你们项目怎么构建？”“编译要多久怎么优化？”“第三方库怎么管理？”时，答不上来就暴露了缺乏大型项目经验。

这篇文章覆盖 C++ 工程化的核心知识：构建系统 → 包管理 → 编译优化 → 代码质量 → CI/CD，每道题都带可直接使用的配置模板。

📌 关联阅读：C++ 对象模型面试题 · 现代 C++ 面试题

第一部分：CMake 核心概念

Q1：CMake 的 target（目标）是什么？为什么说”Modern CMake 以 target 为中心”？

记忆点：target = 编译产物 + 其所有属性的封装（类似面向对象的”类”）

  
# 旧式 CMake（目录级，不推荐）
include_directories(/path/to/include)     # 全局污染
link_directories(/path/to/lib)            # 全局污染
add_definitions(-DFOO)                    # 全局污染

# Modern CMake（target级，推荐）
add_library(mylib src1.cpp src2.cpp)
target_include_directories(mylib PUBLIC include/)      # 只影响 mylib
target_compile_definitions(mylib PRIVATE FOO=1)        # 只影响 mylib
target_link_libraries(mylib PUBLIC Threads::Threads)   # 只影响 mylib

三个可见性关键字：

关键字	含义	类比
`PRIVATE`	只对当前 target 生效	私有实现细节
`PUBLIC`	对当前 target 和依赖它的 target 都生效	公开接口
`INTERFACE`	只对依赖它的 target 生效，自己不用	头文件 only 库

  
# 示例：mylib 的 include/ 对外公开，src/internal/ 只自己用
target_include_directories(mylib
    PUBLIC  ${CMAKE_CURRENT_SOURCE_DIR}/include   # 用户也需要
    PRIVATE ${CMAKE_CURRENT_SOURCE_DIR}/src        # 内部实现
)

面试加分：Modern CMake 的核心思想是依赖传播——target_link_libraries(app PRIVATE mylib) 时，mylib 的 PUBLIC 属性（头文件路径、编译选项等）会自动传递给 app。

Q2：CMake 中 add_library 的 STATIC/SHARED/INTERFACE 有什么区别？

记忆点：STATIC = .a 归档，SHARED = .so 动态库，INTERFACE = 纯头文件

  
# 静态库（编译时链接，打入可执行文件）
add_library(mylib STATIC src.cpp)
# → libmylib.a

# 动态库（运行时加载）
add_library(mylib SHARED src.cpp)
# → libmylib.so

# 接口库（不编译，只传递属性——header-only 库）
add_library(mylib INTERFACE)
target_include_directories(mylib INTERFACE include/)
# → 没有 .a/.so，只传递头文件路径

# 让用户选择（推荐）
option(BUILD_SHARED_LIBS "Build shared libraries" OFF)
add_library(mylib src.cpp)  # 不指定类型，由 BUILD_SHARED_LIBS 决定

类型	产物	链接方式	典型场景
STATIC	.a/.lib	编译时打包	默认方式，部署简单
SHARED	.so/.dll	运行时加载	多程序共享、插件系统
INTERFACE	无	只传属性	header-only 库（如 Eigen）
OBJECT	.o 集合	编译时合并	内部模块组织

Q3：一个标准的 CMake 项目结构应该怎么组织？

记忆点：顶层 CMake + src/ + include/ + tests/ + cmake/

myproject/
├── CMakeLists.txt              # 顶层 CMake
├── cmake/                      # CMake 模块和配置
│   └── myprojectConfig.cmake.in
├── include/                    # 公共头文件
│   └── myproject/
│       ├── core.h
│       └── utils.h
├── src/                        # 源代码
│   ├── CMakeLists.txt
│   ├── core.cpp
│   └── utils.cpp
├── tests/                      # 测试
│   ├── CMakeLists.txt
│   └── test_core.cpp
├── examples/                   # 示例
│   └── CMakeLists.txt
├── third_party/                # 第三方依赖
├── .clang-format               # 代码格式化配置
├── .clang-tidy                 # 静态分析配置
└── README.md

顶层 CMakeLists.txt 模板：

  
cmake_minimum_required(VERSION 3.16)
project(myproject VERSION 1.0.0 LANGUAGES CXX)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
set(CMAKE_CXX_EXTENSIONS OFF)

# 选项
option(MYPROJECT_BUILD_TESTS "Build tests" ON)
option(MYPROJECT_BUILD_EXAMPLES "Build examples" OFF)

# 主库
add_subdirectory(src)

# 测试
if(MYPROJECT_BUILD_TESTS)
    enable_testing()
    add_subdirectory(tests)
endif()

Q4：cmake 的 find_package 是怎么找到库的？MODULE 模式和 CONFIG 模式有什么区别？

记忆点：MODULE = CMake 自带的 FindXxx.cmake，CONFIG = 库自己提供的 XxxConfig.cmake

find_package(Foo) 搜索顺序：

1. MODULE 模式（优先）：
   搜索 FindFoo.cmake 文件
   位置：CMAKE_MODULE_PATH → CMake 安装目录/Modules/
   例：FindOpenSSL.cmake, FindThreads.cmake

2. CONFIG 模式：
   搜索 FooConfig.cmake 或 foo-config.cmake
   位置：CMAKE_PREFIX_PATH → 系统路径 → 注册表
   例：protobuf 安装后提供 protobufConfig.cmake

find_package(Foo REQUIRED)        # 找不到就报错
find_package(Foo 2.0 EXACT)       # 精确版本
find_package(Foo CONFIG)          # 强制 CONFIG 模式
find_package(Foo MODULE)          # 强制 MODULE 模式

面试加分：vcpkg/conan 安装的库通常提供 CONFIG 模式文件。自己写 FindXxx.cmake 时，需要设置 Xxx_FOUND、Xxx_INCLUDE_DIRS、Xxx_LIBRARIES 等变量。

第二部分：第三方依赖管理

Q5：vcpkg、conan、FetchContent 各自的定位和优缺点？

记忆点：vcpkg = 系统级包管理，conan = 项目级包管理，FetchContent = 源码集成

维度	vcpkg	conan	FetchContent
管理粒度	系统/用户级	项目级	项目级
预编译二进制	✅	✅	❌（每次编译）
版本管理	manifest (vcpkg.json)	conanfile.txt/py	CMakeLists.txt
生态	微软维护，~2000+ 库	社区活跃，~1500+	任何 Git 仓库
与 CMake 集成	原生 toolchain file	generator	原生
离线使用	需下载	支持缓存	需下载
学习曲线	低	中	低

vcpkg 用法：

  
# 安装
vcpkg install fmt spdlog grpc

# 在 CMake 中使用
cmake -B build -DCMAKE_TOOLCHAIN_FILE=/path/to/vcpkg/scripts/buildsystems/vcpkg.cmake

  
// vcpkg.json（manifest 模式，推荐）
{
    "dependencies": [
        "fmt",
        "spdlog",
        { "name": "grpc", "version>=": "1.50.0" }
    ]
}

FetchContent 用法：

  
include(FetchContent)

FetchContent_Declare(
    googletest
    GIT_REPOSITORY https://github.com/google/googletest.git
    GIT_TAG        v1.14.0
)
FetchContent_MakeAvailable(googletest)

# 直接用
target_link_libraries(my_test GTest::gtest_main)

选择建议：

小项目/个人项目 → FetchContent（最简单）
团队项目 → vcpkg manifest 或 conan
公司内部 → conan（更灵活的版本管理和私有仓库）

Q6：CMake 的 Presets 是什么？怎么统一团队的构建配置？

记忆点：CMakePresets.json = 统一构建配置，一行命令构建

  
// CMakePresets.json
{
    "version": 6,
    "configurePresets": [
        {
            "name": "dev",
            "displayName": "Development",
            "binaryDir": "${sourceDir}/build/dev",
            "cacheVariables": {
                "CMAKE_BUILD_TYPE": "Debug",
                "CMAKE_CXX_COMPILER": "g++",
                "MYPROJECT_BUILD_TESTS": "ON"
            }
        },
        {
            "name": "release",
            "displayName": "Release",
            "binaryDir": "${sourceDir}/build/release",
            "cacheVariables": {
                "CMAKE_BUILD_TYPE": "Release",
                "CMAKE_CXX_COMPILER": "g++",
                "MYPROJECT_BUILD_TESTS": "OFF"
            }
        }
    ],
    "buildPresets": [
        { "name": "dev", "configurePreset": "dev" },
        { "name": "release", "configurePreset": "release" }
    ]
}

  
# 团队统一构建命令
cmake --preset dev          # 配置
cmake --build --preset dev  # 构建
ctest --preset dev          # 测试

第三部分：编译加速

Q7：大型 C++ 项目编译慢，有哪些加速方法？

记忆点：并行 + 缓存 + 预编译头 + 减少依赖

编译加速方法（从简单到复杂）：

1. 并行编译
   make -j$(nproc)              # 充分利用多核
   cmake --build build -j 16    # CMake 方式

2. ccache（编译缓存）
   相同源码+选项 → 直接返回缓存结果
   首次：无效果
   二次+：极快（秒级）

3. 预编译头（PCH）
   频繁包含的头文件预编译为二进制
   每个 .cpp 不再重复解析这些头

4. Unity Build（合并编译）
   多个 .cpp 合并为一个大文件编译
   减少头文件重复解析和链接开销

5. 前向声明
   头文件中 class Foo; 代替 #include "foo.h"
   减少头文件依赖链

6. 分布式编译
   distcc / icecream：分发到多台机器编译

ccache 配置：

  
# 安装
apt install ccache  # 或 brew install ccache

# CMake 中启用
cmake -B build -DCMAKE_CXX_COMPILER_LAUNCHER=ccache

# 查看命中率
ccache -s

预编译头（CMake 3.16+）：

  
target_precompile_headers(mylib PRIVATE
    <vector>
    <string>
    <unordered_map>
    <memory>
    "common/logging.h"
)

Unity Build（CMake 3.16+）：

  
set(CMAKE_UNITY_BUILD ON)
set(CMAKE_UNITY_BUILD_BATCH_SIZE 16)  # 每 16 个文件合并

各方法加速效果（经验值）：

方法	加速比	侵入性	适用场景
并行 -j	2-8x	无	所有项目
ccache	2-10x（增量）	无	频繁重编译
PCH	1.5-3x	低	大量公共头文件
Unity Build	2-4x	中	源文件多的项目
前向声明	1.2-2x	中	头文件依赖重
分布式编译	3-10x	高	超大型项目

Q8：#include 的依赖管理有什么讲究？PIMPL 模式怎么减少编译依赖？

记忆点：减少头文件 #include = 减少编译耦合 = 加速增量编译

问题：修改 base.h → 所有包含 base.h 的文件都要重编译

before（依赖重）：
// widget.h
#include "database.h"     // 只用了 Database* 指针
#include "network.h"      // 只用了 Connection* 指针
#include "renderer.h"     // 只用了 Texture 类型

after（前向声明）：
// widget.h
class Database;           // 前向声明够了
class Connection;
class Texture;
// 只在 widget.cpp 中 #include 完整头文件

PIMPL（Pointer to Implementation）：

  
// widget.h（公开头文件）——编译依赖最小化
class Widget {
public:
    Widget();
    ~Widget();
    void doSomething();
private:
    struct Impl;          // 前向声明
    std::unique_ptr<Impl> pImpl;  // 指针指向实现
};

// widget.cpp（实现文件）——所有依赖都在这里
#include "widget.h"
#include "database.h"     // 只在 .cpp 中包含
#include "network.h"

struct Widget::Impl {
    Database db;
    Connection conn;
    // 所有私有成员都在这里
};

Widget::Widget() : pImpl(std::make_unique<Impl>()) {}
Widget::~Widget() = default;  // 必须在 .cpp 中定义
void Widget::doSomething() { pImpl->db.query(); }

PIMPL 优缺点：

优点	缺点
修改实现不触发使用者重编译	多一次间接寻址（性能微损）
隐藏实现细节（ABI 稳定）	代码量增加
减少头文件依赖	堆分配开销

第四部分：代码质量工具

Q9：clang-tidy 能做什么？怎么配置？

记忆点：clang-tidy = C++ 的 lint 工具，能自动修复部分问题

  
# .clang-tidy 配置文件
Checks: >
  -*,
  bugprone-*,
  clang-analyzer-*,
  cppcoreguidelines-*,
  modernize-*,
  performance-*,
  readability-*,
  -modernize-use-trailing-return-type,
  -readability-magic-numbers

WarningsAsErrors: 'bugprone-*,clang-analyzer-*'

CheckOptions:
  - key: readability-identifier-naming.ClassCase
    value: CamelCase
  - key: readability-identifier-naming.FunctionCase
    value: camelBack

  
# 运行
clang-tidy src/*.cpp -- -std=c++17 -I include/

# 自动修复
clang-tidy -fix src/*.cpp -- -std=c++17

# CMake 集成（每次编译自动检查）
set(CMAKE_CXX_CLANG_TIDY "clang-tidy;-checks=bugprone-*,performance-*")

常用检查分类：

前缀	检查内容	示例
`bugprone-`	容易出 bug 的模式	整数溢出、悬空引用
`modernize-`	旧写法改现代写法	NULL→nullptr、auto
`performance-`	性能问题	不必要的拷贝、move
`readability-`	可读性	命名规范、magic number
`cppcoreguidelines-`	C++ Core Guidelines	裸指针、gsl 规范
`clang-analyzer-`	静态分析（深度）	空指针解引用、内存泄漏

Q10：Sanitizer 和 clang-tidy 怎么集成到 CI 中？

记忆点：CI = 格式检查 + 静态分析 + 构建 + 测试 + Sanitizer

  
# GitHub Actions 示例
name: CI
on: [push, pull_request]

jobs:
  build-and-test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        build_type: [Debug, Release]
    steps:
      - uses: actions/checkout@v4

      - name: Configure
        run: cmake -B build -DCMAKE_BUILD_TYPE=$\{\{ matrix.build_type \}\}

      - name: Build
        run: cmake --build build -j $(nproc)

      - name: Test
        run: cd build && ctest --output-on-failure

  sanitizers:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        sanitizer: [address, thread, undefined]
    steps:
      - uses: actions/checkout@v4

      - name: Build with Sanitizer
        run: |
          cmake -B build \
            -DCMAKE_CXX_FLAGS="-fsanitize=$\{\{ matrix.sanitizer \}\} -g" \
            -DCMAKE_BUILD_TYPE=Debug
          cmake --build build -j $(nproc)

      - name: Test
        run: cd build && ctest --output-on-failure

  clang-tidy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run clang-tidy
        run: |
          cmake -B build -DCMAKE_EXPORT_COMPILE_COMMANDS=ON
          run-clang-tidy -p build src/

  format-check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Check formatting
        run: |
          find src include -name "*.cpp" -o -name "*.h" | \
            xargs clang-format --dry-run --Werror

第五部分：构建系统进阶

Q11：CMake 的 Generator Expression 是什么？什么时候用？

记忆点：$<...> = 在生成时（而非配置时）求值的表达式

  
# 根据构建类型选择不同选项
target_compile_definitions(mylib PRIVATE
    $<$<CONFIG:Debug>:DEBUG_MODE>          # Debug 时定义 DEBUG_MODE
    $<$<CONFIG:Release>:NDEBUG>            # Release 时定义 NDEBUG
)

# 根据编译器选择选项
target_compile_options(mylib PRIVATE
    $<$<CXX_COMPILER_ID:GNU>:-Wall -Wextra>
    $<$<CXX_COMPILER_ID:MSVC>:/W4>
)

# 安装时和构建时使用不同的 include 路径
target_include_directories(mylib PUBLIC
    $<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/include>
    $<INSTALL_INTERFACE:include>
)

常用生成器表达式：

表达式	含义
`$<CONFIG:Debug>`	当前是 Debug 配置
`$<CXX_COMPILER_ID:GNU>`	编译器是 GCC
`$<TARGET_FILE:foo>`	foo 目标的输出文件路径
`$<BUILD_INTERFACE:...>`	构建时使用的路径
`$<INSTALL_INTERFACE:...>`	安装后使用的路径

Q12：怎么让自己的 CMake 项目支持 find_package？

记忆点：导出 target + 生成 Config.cmake + install 规则

  
# 安装库文件
install(TARGETS mylib
    EXPORT mylib-targets
    ARCHIVE DESTINATION lib
    LIBRARY DESTINATION lib
    RUNTIME DESTINATION bin
)

# 安装头文件
install(DIRECTORY include/mylib DESTINATION include)

# 导出 targets
install(EXPORT mylib-targets
    FILE mylibTargets.cmake
    NAMESPACE mylib::
    DESTINATION lib/cmake/mylib
)

# 生成 Config 文件
include(CMakePackageConfigHelpers)
configure_package_config_file(
    cmake/mylibConfig.cmake.in
    ${CMAKE_CURRENT_BINARY_DIR}/mylibConfig.cmake
    INSTALL_DESTINATION lib/cmake/mylib
)
write_basic_package_version_file(
    ${CMAKE_CURRENT_BINARY_DIR}/mylibConfigVersion.cmake
    VERSION ${PROJECT_VERSION}
    COMPATIBILITY SameMajorVersion
)
install(FILES
    ${CMAKE_CURRENT_BINARY_DIR}/mylibConfig.cmake
    ${CMAKE_CURRENT_BINARY_DIR}/mylibConfigVersion.cmake
    DESTINATION lib/cmake/mylib
)

安装后，其他项目可以：

  
find_package(mylib 1.0 REQUIRED)
target_link_libraries(app PRIVATE mylib::mylib)

Q13：交叉编译怎么配置？什么是 toolchain file？

记忆点：toolchain file = 告诉 CMake 用哪个编译器、目标平台是什么

  
# aarch64-linux-toolchain.cmake
set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR aarch64)

set(CMAKE_C_COMPILER   aarch64-linux-gnu-gcc)
set(CMAKE_CXX_COMPILER aarch64-linux-gnu-g++)

set(CMAKE_FIND_ROOT_PATH /usr/aarch64-linux-gnu)
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)

  
# 使用 toolchain file
cmake -B build \
  -DCMAKE_TOOLCHAIN_FILE=cmake/aarch64-linux-toolchain.cmake
cmake --build build

第六部分：调试构建与发布

Q14：Debug 和 Release 构建的区别？还有哪些构建类型？

记忆点：Debug = 调试信息 + 无优化，Release = 优化 + 无调试

构建类型	优化等级	调试信息	断言	典型用途
Debug	-O0	-g	启用	开发调试
Release	-O3	无	禁用	生产部署
RelWithDebInfo	-O2	-g	禁用	生产+可调试
MinSizeRel	-Os	无	禁用	嵌入式/移动端

  
# 设置默认构建类型
if(NOT CMAKE_BUILD_TYPE AND NOT CMAKE_CONFIGURATION_TYPES)
    set(CMAKE_BUILD_TYPE RelWithDebInfo CACHE STRING "Build type" FORCE)
endif()

# Debug 特有选项
target_compile_options(mylib PRIVATE
    $<$<CONFIG:Debug>:-fsanitize=address,undefined>
)
target_link_options(mylib PRIVATE
    $<$<CONFIG:Debug>:-fsanitize=address,undefined>
)

面试加分：生产环境推荐 RelWithDebInfo——既有优化，又能在崩溃时用 core dump + GDB 调试。纯 Release 去掉了调试信息，出问题时很难排查。

Q15：CMake 的 CTest 怎么用？怎么和 Google Test 集成？

记忆点：enable_testing() + add_test() + ctest 运行

  
# 在顶层 CMakeLists.txt
enable_testing()

# 在 tests/CMakeLists.txt
find_package(GTest REQUIRED)

add_executable(test_core test_core.cpp)
target_link_libraries(test_core PRIVATE
    mylib
    GTest::gtest_main
)

# 方式1：手动添加测试
add_test(NAME test_core COMMAND test_core)

# 方式2：自动发现 Google Test 用例（推荐）
include(GoogleTest)
gtest_discover_tests(test_core)

  
# 运行测试
cd build
ctest                            # 运行所有测试
ctest -R "test_core"             # 按名称过滤
ctest --output-on-failure        # 失败时显示输出
ctest -j $(nproc)                # 并行测试
ctest --test-dir build           # 指定构建目录

第七部分：常见面试问题

Q16：头文件保护有哪几种方式？pragma once 和 include guard 哪个好？

记忆点：两种方式功能等价，pragma once 更简洁

  
// 方式1：include guard（传统，100% 可移植）
#ifndef MYPROJECT_CORE_H
#define MYPROJECT_CORE_H
// ... 内容 ...
#endif // MYPROJECT_CORE_H

// 方式2：#pragma once（简洁，所有主流编译器支持）
#pragma once
// ... 内容 ...

维度	include guard	#pragma once
标准	C/C++ 标准	非标准但广泛支持
可移植性	100%	>99%（GCC/Clang/MSVC）
编写	需要唯一宏名	一行搞定
性能	编译器通常有优化	可能更快（路径判断）
风险	宏名冲突	文件拷贝时可能误判

Q17：C++ 的编译模型有什么问题？C++20 Modules 怎么解决的？

记忆点：传统 #include = 文本替换，Modules = 编译后的接口

传统 #include 的问题：
  #include <vector>   → 展开 2万行代码
  #include <string>   → 展开 1万行代码
  #include <iostream>  → 展开 3万行代码
  → 每个 .cpp 都要重新解析这些头文件！

C++20 Modules：
  import std;          → 加载预编译的模块接口
  → 只解析一次，后续直接用二进制接口
  → 编译速度显著提升

  
// math.cppm（模块接口文件）
export module math;

export int add(int a, int b) {
    return a + b;
}

export class Calculator {
public:
    int compute(int x) { return x * 2; }
};

// main.cpp
import math;

int main() {
    auto result = add(1, 2);
    Calculator calc;
}

Modules 的优势：

维度	#include	Modules
解析开销	每个文件重复解析	只编译一次
宏泄漏	会污染	不泄漏
编译速度	慢	快（可达 10x）
依赖隔离	差（传递依赖）	好（显式导出）
编译器支持	完全	GCC/Clang/MSVC 逐步完善

Q18：静态链接和动态链接如何选择？有什么坑？

记忆点：静态 = 部署简单但体积大，动态 = 体积小但依赖管理复杂

维度	静态链接	动态链接
部署	单个可执行文件	需要带 .so/.dll
大小	大（重复打包）	小（共享库）
更新	重新编译	替换 .so 即可
版本冲突	无	DLL Hell
性能	略快（无 PLT 跳转）	略慢（间接调用）
内存	多进程不共享代码段	多进程共享代码段

常见坑：

1. 静态库顺序问题
   gcc main.o -lA -lB    # 如果 A 依赖 B，B 必须在 A 后面
   解决：-Wl,--start-group -lA -lB -Wl,--end-group

2. 动态库版本问题
   libfoo.so → libfoo.so.1 → libfoo.so.1.2.3
   soname = libfoo.so.1  ← 运行时查找这个

3. 符号冲突
   两个静态库定义了同名函数 → 链接器随机选一个
   解决：namespace 隔离 或 visibility 控制

4. RPATH 问题
   运行时找不到 .so → 设置 RPATH 或 LD_LIBRARY_PATH
   cmake: set(CMAKE_INSTALL_RPATH "$ORIGIN/../lib")

Q19：如何管理 C++ 项目的编译警告？

记忆点：高警告等级 + 警告即错误 + 逐步修复

  
# 推荐的警告配置
function(set_project_warnings target)
    target_compile_options(${target} PRIVATE
        $<$<CXX_COMPILER_ID:GNU,Clang>:
            -Wall -Wextra -Wpedantic
            -Wshadow
            -Wnon-virtual-dtor
            -Wold-style-cast
            -Wcast-align
            -Woverloaded-virtual
            -Wconversion
            -Wsign-conversion
            -Wnull-dereference
            -Wdouble-promotion
            -Wformat=2
        >
        $<$<CXX_COMPILER_ID:MSVC>:
            /W4 /permissive-
        >
    )
endfunction()

# 对自己的代码开启警告即错误
target_compile_options(mylib PRIVATE
    $<$<CXX_COMPILER_ID:GNU,Clang>:-Werror>
    $<$<CXX_COMPILER_ID:MSVC>:/WX>
)

面试加分：对第三方库不要开 -Werror（它们的警告你改不了），只对自己的代码开。用 SYSTEM 标记第三方头文件路径可以抑制其警告。

Q20：Makefile、CMake、Bazel、Meson 怎么选？

记忆点：小项目 CMake，超大单仓 Bazel，追求速度 Meson

构建系统	适用规模	特点	代表用户
Makefile	小项目	直接、手动、灵活	Linux 内核
CMake	中大型	事实标准、生态最好	KDE/Qt/LLVM
Bazel	超大型单仓	增量构建、远程缓存	Google
Meson	中型	语法简洁、速度快	GNOME/systemd
xmake	中型	Lua 语法、内置包管理	国内项目