未定义行为指C++标准未规定操作的执行结果，如数组越界访问、使用未初始化变量、迭代器失效后使用等，编译器可生成任意代码，程序可能崩溃或输出错误结果；常见陷阱包括原生数组和std::vector::operator[]越界、未初始化局部变量；建议使用std::vector::at()、开启调试检查、启用编译警告、采用智能指针与容器、结合Clang-Tidy和ASan/UBSan工具预防。
在C++中，未定义行为（Undefined Behavior, UB）是指语言标准没有规定程序应如何执行的某些操作。一旦触发未定义行为，编译器可以生成任意代码，程序可能崩溃、输出错误结果，甚至看似正常运行。这类问题往往难以调试，且在不同平台或编译器下表现不一，是C++开发中的“隐藏陷阱”。
访问越界内存
最常见的未定义行为之一是访问数组或容器的非法位置。
- 使用原生数组时，下标超出范围：如 int arr[5]; arr[10] = 1;，不会报错但行为未定义。
- 使用 std::vector::operator[] 越界访问（不进行边界检查），同样属于UB。
- 迭代器失效后继续使用，例如在遍历中删除元素导致迭代器无效。
建议：优先使用 std::vector::at() 或开启调试模式下的边界检查来捕获此类错误。
使用未初始化的变量
局部内置类型变量（如 int、float、指针）若未显式初始化，其值是不确定的。
立即学习“C++免费学习笔记（深入）”；
- int x; std::cout —— 输出不可预测。
- 尤其危险的是未初始化的指针，解引用会导致崩溃或安全漏洞。
建议：始终初始化变量，尤其是内置类型。使用 = {} 进行零初始化，或启用编译器警告（如 -Wall -Wuninitialized）。
空指针或野指针解引用
对空指针或已释放的内存进行解引用是典型的未定义行为。
- int* p = nullptr; *p = 1;
- 释放内存后未置空指针，后续误用：delete p; *p = 2;
- 返回局部变量的地址：int* f() { int x; return &x; }
建议：释放后立即将指针设为 nullptr，避免返回局部对象地址，使用智能指针管理生命周期。
修改字符串字面量
字符串字面量存储在只读内存区域，尝试修改会触发UB。
- char* s = "hello"; s[0] = 'H'; —— 危险操作。
正确做法：使用数组复制内容：char s[] = "hello"; 再修改。
有符号整数溢出
无符号整数溢出是定义良好的（模运算），但有符号整数溢出属于未定义行为。
- int x = INT_MAX; x++; —— UB。
这可能导致编译器优化掉看似“不可能”的条件判断。例如，if (x + 1 可能被优化为恒真或恒假。
多次修改同一变量无序列点
在两个序列点之间对同一变量进行多次写操作，顺序不确定。
- i = i++; —— 经典UB示例。
- func(i++, i++); —— 参数求值顺序未定义，且修改了同一变量。
C++17起部分表达式引入了更强的求值顺序规则，但此类代码仍应避免。
函数返回局部对象的引用或指针
函数结束后，局部对象被销毁，返回其引用或指针将指向无效内存。
- const std::string& getName() { std::string name = "Tom"; return name; }
调用方使用返回值时访问的是已析构对象，行为未定义。
虚函数构造/析构期间调用
在基类构造函数或析构函数中调用虚函数，不会发生多态行为，而是调用当前层级的版本。
- 虽然不一定是崩溃，但行为与预期不符，容易引发逻辑错误。
- 严格来说，这不是UB，但常被误解，属于“陷阱”行为。
真正UB出现在通过未完成构造的对象调用虚函数（如构造函数中传 this 到其他线程并调用虚函数）。
类型双关（Type Punning）违反严格别名规则
C++禁止通过非兼容类型指针访问对象，除非使用允许的方式。
- int x = 42; float* p = (float*)&x; *p = 1.0f; —— 违反严格别名，UB。
正确方式：使用 memcpy、联合体（union，C++17起放宽限制）或 std::bit_cast（C++20）。
未定义的移位操作
移位操作中，若移位量为负或大于等于数据宽度，行为未定义。
- int x = 1 （在32位int上）—— UB。
- int x = 1 >> -1; —— 同样UB。
基本上就这些常见又容易踩坑的未定义行为。它们大多源于对内存和类型的直接操作，而编译器为了性能放弃安全性检查。预防的关键是：开启编译警告、使用现代C++特性（如智能指针、容器）、借助静态分析工具（如Clang-Tidy）和 sanitizer（如ASan、UBSan）。理解这些陷阱，才能写出更健壮的C++代码。
