ASSERT_EQ失败立即终止测试，EXPECT_EQ仅记录错误并继续执行；字符串比较须避免const char*指针比较，应使用EXPECT_STREQ、std::string转换或"s"后缀。
ASSERT_EQ 和 EXPECT_EQ 的行为差异直接决定测试是否继续
两者都做相等判断，但失败时的处理完全不同：ASSERT_EQ 会立即退出当前测试函数，后续语句不执行；EXPECT_EQ 只记录失败、打印信息，测试函数继续跑完。这意味着如果你在 ASSERT_EQ 后面有资源清理代码（比如 delete ptr 或 fclose(fp)），失败时这些代码就被跳过了，可能造成泄漏或状态残留。
常见误用场景：
- 在循环里用
ASSERT_EQ比较数组元素 —— 第一个失败就停，看不到后面还有多少错 - 把
ASSERT_EQ放在需要保证前置条件的位置（比如检查指针非空），这是合理用法；但若只是验证业务逻辑输出，优先选EXPECT_EQ - 混合使用时没注意作用域：一个测试函数里既有
ASSERT_EQ又有EXPECT_EQ，失败顺序会影响你看到哪些断言结果
字符串比较必须避开 const char* 的坑
EXPECT_EQ("hello", str.c_str()) 看似自然，实则危险 —— 它比较的是两个指针地址，不是内容。哪怕两个字面量都是 "hello"，编译器也可能分配不同地址，导致恒为 false。
安全写法只有三种：
- 用
EXPECT_STREQ("hello", str.c_str())，专为 C 风格字符串设计 - 转成
std::string再比：EXPECT_EQ(std::string("hello"), str) - C++14 起可用字符串字面量后缀：
EXPECT_EQ("hello"s, str)，s后缀强制推导为std::string
错误示例触发的报错典型长这样：Expected: "abc" Which is: 0x55e2a1234000 —— 这个十六进制地址就是你在被指针比较绑架。
报错信息太简略？手动塞上下文是刚需
裸写 EXPECT_EQ(x[i], y[i]) 失败时只告诉你“第 i 个元素不对”，但不会告诉你 i 是几、x[i] 实际是多少。调试时得靠猜。
补救方式统一用 操作符追加说明：
EXPECT_EQ(x[i], y[i])EXPECT_EQ(actual.size(), expected.size())- 复杂表达式建议提前赋值再断言，方便在日志里打出原始变量名：
auto got = calc_result(); auto want = 42; EXPECT_EQ(got, want)
链接和编译参数错一个，test 就静默崩溃
最常踩的坑不是逻辑，而是构建层面：
- 忘了
-pthread：Linux/macOS 下大概率 segfault，且不报明显错误 - 误链
-lgtest却没写自己的main()：链接失败，提示 undefined reference tomain - 写了自定义
main()却又链了-lgtest_main：符号重复定义 - 没调
::testing::InitGoogleTest(&argc, argv)：部分功能（如命令行参数解析）失效，但不一定立刻报错
简单验证是否真跑起来了：加一个故意失败的 EXPECT_TRUE(false) ，看终端是否打出这句。不打，基本是链接或初始化环节卡住了。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
