最稳方式是链接libgtest.a或用find_package(gtest)，ubuntu需装libgtest-dev并手动构建静态库，mac用brew install googletest；test用于无状态纯函数测试，test_f用于需共享fixture资源的场景；断言应配合gtest_fail等增强可读性。
怎么让 gtest 在 C++ 项目里跑起来
直接链接 libgtest.a 或用 find_package(GTest) 是最稳的启动方式，别手写 add_library 去编译 gtest 源码——除非你真要改它内部逻辑。CMake 3.14+ 默认带 FindGTest.cmake，但注意它只找系统级安装（比如 apt install libgtest-dev 装的），而没装头文件和静态库是白搭。
常见错误现象：fatal error: gtest/gtest.h: No such file or directory，本质是头文件路径没进 include_directories 或 target_include_directories；或者链接时报 undefined reference to testing::InitGoogleTest，说明 libgtest_main.a 没链上，或 main() 冲突了。
- Ubuntu/Debian 下先装全：
sudo apt install libgtest-dev cmake，再手动构建静态库：sudo cmake /usr/src/googletest -B /usr/src/googletest/build && sudo cmake --build /usr/src/googletest/build --target install - Mac 上用
brew install googletest更省事，头文件和库自动就位 - CMakeLists.txt 里必须显式链接
gtest和gtest_main，尤其后者提供默认main，否则自己写main容易漏掉testing::InitGoogleTest
TEST 和 TEST_F 到底该选哪个
单测函数要不要共享状态，决定了用哪个宏。TEST 是纯函数式，每次执行都是干净环境；TEST_F 绑定一个 fixture 类，适合需要构造/析构资源（比如临时文件、mock 对象、数据库连接）的场景。
容易踩的坑：在 TEST_F 的 SetUp 里抛异常，gtest 会直接 abort，不走 TearDown；还有人把 fixture 成员变量声明成 static，结果测试间互相污染——fixture 实例是每个 test 独享的，static 就破了这个隔离。
立即学习“C++免费学习笔记（深入）”；
- 用
TEST：验证数学函数、字符串处理等无副作用逻辑，例如TEST(StringUtilTest, TrimWhitespace) - 用
TEST_F：要初始化 mock、打开文件、设置全局 flag，例如class FileIoTest : public ::testing::Test { void SetUp() override { temp_file_ = std::tmpnam(nullptr); } }; TEST_F(FileIoTest, ReadEmptyFile) - 别在 fixture 构造函数里做 heavy 初始化，gtest 要求
SetUp才是标准入口，构造函数可能被跳过（比如用TEST时不走 fixture）
断言失败时怎么快速定位问题
别只靠 EXPECT_EQ(a, b) 看红字，gtest 默认只打出行号和表达式文本，a、b 的实际值藏在日志末尾，翻起来费劲。加 流式输出能立刻看到上下文，而且不影响断言逻辑。
性能影响很小，但调试效率差十倍。另一个盲点是 ASSERT 和 EXPECT 的区别：前者失败直接 return，后者继续跑完当前 test 函数——这对有清理逻辑（比如关 socket、删临时目录）的 fixture 很关键。
- 写成这样：
EXPECT_EQ(result.size(), expected_size) - 涉及资源释放时，优先用
EXPECT；若后续语句依赖前一步成功（比如解析 JSON 后再取字段），才用ASSERT - 自定义类型要重载
operator 到 <code>std::ostream&，否则打印出来是地址或乱码，gtest 不会自动调to_string
CI 环境下 gtest 报 Segmentation fault (core dumped)
本地跑得好，CI 上 core dump，八成是链接了不同 ABI 版本的 STL 或线程库。尤其在 Ubuntu 20.04+（GLIBCXX_3.4.29）上编译，又在 CentOS 7（GLIBCXX_3.4.20）运行，std::string 内存布局不兼容，一碰就崩。
另一个高频原因是测试进程被 OOM killer 干掉——gtest 默认并行跑所有 test，内存峰值翻倍。不是所有 CI runner 都告诉你“被 kill -9”了，只显示 segmentation fault。
- 用
ldd your_test_binary | grep stdc\+\+看链接的 libstdc++ 路径，对比 CI 环境的strings /usr/lib/x86_64-linux-gnu/libstdc++.so.6 | grep GLIBCXX - 加
--gtest_filter=-*Performance*排除耗内存的测试，或强制串行：--gtest_repeat=1 --gtest_shuffle --gtest_random_seed=0不解决根本，但能绕过并发触发的竞态 - 在 CI 脚本里加
ulimit -v $((1024 * 1024))设虚拟内存上限，让 OOM 时明确报 “Killed” 而非 segfault
fixture 的生命周期、STL ABI 兼容性、以及 CI 资源限制这三块，最容易在集成阶段突然冒头，而且现象模糊——得从二进制依赖和系统限制两个层面同时查。
