同一表达式多次修改同一变量会触发未定义行为，因C++标准禁止在两个序列点间多次修改变量，如i++ + ++i或a[i++] = i++，编译器可任意解释顺序，导致跨编译器、优化级别结果不一致。
同一表达式多次修改变量会触发未定义行为
因为 C++ 标准明确禁止在两个序列点之间对同一变量进行多次修改。像 i++ + ++i、a[i++] = i++ 这类写法，编译器可以任意解释执行顺序——可能左到右，也可能右到左，甚至整个子表达式被优化掉。这不是“结果不确定”，而是“标准不保证任何行为”。
常见错误现象包括：
- 同一段代码在 GCC 和 Clang 下输出不同结果
- 开启
-O2后逻辑突变，比如if (x++ 被判定为永真或永假 - 调试时值正常，上线后偶发崩溃或计算错乱
函数参数里用多个 i++ 是最隐蔽的坑
函数调用的参数求值顺序在 C++17 之前完全未指定。写 func(i++, i++) 或 printf("%d %d", i++, i++)，你无法预知哪个 i++ 先执行，也无法预知中间是否穿插了其他副作用。
即使 C++17 对 ||、&&、,、?: 引入了更严格的求值顺序，它依然没规定函数参数间的顺序。所以这类写法在所有 C++ 标准下都属于未定义行为。
立即学习“C++免费学习笔记（深入）”；
容易被忽略的场景：
- 宏展开后隐式构造出多修改表达式，例如
#define MAX(a,b) ((a)>(b)?(a):(b))套用MAX(i++, j++) - 模板推导或重载运算符内部若也含多次修改，同样传染 UB
it = vec.erase(it++) 看似自然实则危险
这行代码表面上想“删当前元素，然后移动迭代器”，但它让 it++ 和 vec.erase() 都对 it 执行写操作。C++ 不保证 it++ 的副作用（即 it 自增）发生在 erase 返回前还是后，因此 it 可能变成悬垂迭代器。
安全写法只有一种：it = vec.erase(it)。因为 erase 返回的是下一个有效迭代器，无需手动递增。
其他类似陷阱：
-
a[i++] = i：读i、写i、再写i，三重修改 -
y = (4 + x++) * (6 + x++)：两个x++无序，x最终值和乘积均不可预测
为什么不能靠“我试过它在 GCC 下跑通”来判断安全
未定义行为不是“偶尔出错”，而是“任何时候都可能出错”。编译器有权：
- 将整个表达式替换为常量（比如直接算成
42） - 在 LTO 阶段跨函数删除看似冗余的自增
- 因寄存器分配变化导致调试版和发布版行为分裂
静态分析工具如 clang-tidy 的 bugprone-multiple-statement-relay 规则能捕获部分情况，但覆盖不全。真正可靠的防线是：**一次表达式只做一次写**——把 a[i++] = i++ 拆成 a[i] = i; ++i;，把 func(x++, x++) 拆成两行赋值再传参。
最容易被忽略的一点：宏、模板、重载运算符如果内部也做了多次修改，UB 会透传出来。不要以为“没直接写 ++ 就安全”。
