不是我的问题，是编译器的问题
本文探讨了程序员在遇到代码错误时，常常倾向于将责任归咎于编译器而非自身代码的心理现象。作者通过具体案例分析了编译器优化、未定义行为以及开发者对底层机制理解不足等问题，揭示了这种思维误区背后的技术原因。文章旨在帮助开发者更理性地排查错误，提升对编译器行为的认知。
背景速读
- 这篇文章讨论的核心现象：程序员抱怨自己的代码"被编译器优化坏了"或"编译器有 bug"，但实际往往是程序员对 C/C++ 中的未定义行为（Undefined Behavior, UB）理解不足。
- 未定义行为是 C/C++ 语言标准的设定——当代码触发了标准未定义的操作（如有符号整数溢出、解引用空指针、数据竞争），编译器可以"自由发挥"，结果是程序可能崩溃、输出错误结果，甚至"看似正常工作"但换个编译选项就出问题。
- 典型的例子：检查指针是否为空后解引用，编译器可能认为空指针解引用是未定义行为，于是推断出"空指针检查永远不会为真"，直接删掉检查代码，导致后续真正空指针时程序崩溃——这并非编译器 bug，而是标准允许的优化。
- 文章作者 Parsa 是伊朗裔加拿大程序员，主要写 C/C++/Rust 相关技术博客；这类话题在系统编程社区（如 LLVM、Linux 内核开发者）中长期存在争议：编译器是否应默认开启"利用 UB 做激进优化"的行为？Rust 语言部分通过更安全的所有权模型回避了此类问题。