为何GeeksforGeeks 30天代码挑战中ans+=与ans=ans+表现差异致超时？

• 在GeeksforGeeks平台参与30天代码挑战、使用平台内置代码编辑器编写C++代码时，出现了非常反常的运行表现：
  • 采用写法ans += st.top().first时，程序可正常运行，顺利通过判题
  • 将这行代码替换为自认为“逻辑完全等价”的ans = ans + st.top().first后，程序直接触发时间超限（TLE）

• 两种写法对绝大多数自定义类型根本不是编译等价的
  • +=是原地修改操作：直接在ans原本的内存空间上追加st.top().first对应的值，不需要申请额外的临时对象内存，也不会触发完整的对象深拷贝，性能开销极低
  • +是临时值生成操作：执行时会先创建一个和原ans完全一致的临时副本，在临时副本上完成值相加的逻辑，最后再把临时副本的全部内容拷贝回原ans变量。如果这段逻辑处于高频循环中，每次累加都要触发一次完整的对象拷贝，当循环次数达到十万、百万量级时，额外的拷贝开销会直接把总运行时间推高到判题阈值以上
  • 哪怕是std::string这类标准库类型，+的开销也远高于+=：循环拼接10万次短字符串的场景下，用+写法的耗时可能是+=的5~10倍，完全可能触发TLE
• 编译优化档位的隐性影响
  • 当判题编译器开启O2全量优化时，哪怕是int、long long这类基础整型场景下，两种写法的机器码会被优化成完全一致的结果，不会出现性能差异
  • 但如果判题链路临时切换到O0无优化档位，ans = ans + x的写法会多一次寄存器中转的指令开销，在高密度循环场景下，这类细碎的开销积累起来，也可能突破判题的时间限制
• 未定义行为的隐性触发
  • 如果st.top().first是需要临时构造的非静态成员，+运算符因为要创建临时副本，可能触发临时对象生命周期截断的未定义行为，导致程序逻辑跑偏，进入无意义的空循环或重复计算分支，最终表现为超时。而+=直接绑定栈顶元素的原引用操作，不会触发这类生命周期问题，可以正常完成计算。

实操提示：在算法题场景下，只要是对容器、字符串、自定义封装类型做累加操作，优先用+=写法，既能减少不必要的临时对象开销，也能避免潜在的未定义行为，从根源上规避这类无意义的TLE问题。

内容的提问来源于stack exchange，提问作者dml