google test 的 expect_eq 和 assert_eq 不可在子线程中调用，因断言依赖主线程的 testing::test 上下文；子线程应仅记录状态，由主线程 join 后统一断言；须用 std::condition_variable 精确控制竞态时序，并始终配合 threadsanitizer 编译与运行。
EXPECT_EQ 不能在子线程里调用
子线程里写 EXPECT_EQ(x, 42) 失败了，测试仍显示 PASSED，不是断言没生效，而是 Google Test 的断言机制根本没绑定到那个线程。它依赖 testing::Test 实例的上下文，而子线程没有这个上下文。
更危险的是 ASSERT_EQ：它在子线程里直接触发 abort()，整个进程崩溃，不是测试失败，是测试中断。
- 子线程只做操作和状态记录，比如把结果 push 到
std::vector<int></int>或写入std::atomic<bool></bool> - 主线程调用
t.join()后，再统一用EXPECT_EQ检查收集的数据 - 避免任何跨线程的断言宏调用，这是硬性边界
用 std::condition_variable 控制线程执行节奏
裸调 std::thread + join() 是无效测试：它串行化了执行，掩盖真实竞态；加 sleep_for() 更糟，时序不可控、CI 上容易飘红。
真正可复现的测试必须精确控制“T1 执行到哪、T2 此刻改什么、T1 接着读什么”——这靠 std::condition_variable 和 std::mutex 配合实现。
- 主线程先锁住条件变量的互斥量，设置好初始状态（如
ready = false） - 启动子线程，它立刻等待
cv.wait(lock, [&]{ return ready; }) - 主线程修改共享变量后，置
ready = true并调用cv.notify_one() - 这样就能稳定复现“读-改-读”或“写-读-写”等特定竞态路径
ThreadSanitizer 必须和测试一起开
TSan 不是调试时才开的“附加选项”，它是多线程测试的基础设施。没它，你写的测试可能漏掉所有真实数据竞争；只有它，又无法定位是哪条执行路径触发的。
编译命令里漏掉任一环节都会让 TSan 失效：既要在编译时加 -fsanitize=thread -g，也要在链接时加 -fsanitize=thread。
- TSan 报错格式固定：
WARNING: ThreadSanitizer: data race后紧跟Previous write和Current read的栈帧 - 这两行的行号，就是你要在测试里用
std::condition_variable精确复现的点 - CI 的 Debug 构建中应默认开启 TSan，性能开销（5–15 倍）在测试阶段完全可接受
每个测试只验证一种竞态路径
别写一个叫 TEST(MultiThread, BusinessLogicWorks) 的测试去跑完整流程。它不可复现、难调试、失败后不知道是哪步出问题。
好的测试名要暴露意图，比如 TEST(DataRaceOnCounter, ReadBeforeWriteWithoutLock)，说明它只盯住“无锁下先读后写导致计数器错乱”这一种情况。
- 共享变量用
std::atomic或加锁保护，不是为了“让测试过”，而是为了隔离出你要验证的那个未保护路径 - 测试夹具（
Test派生类）里所有成员变量必须线程安全，比如用std::queue收集日志时得配std::mutex - 资源隔离要彻底：每个测试实例独占一份共享状态，不能靠全局变量或静态变量
EXPECT_EQ 一样每天敲进代码里的基本动作。C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
