你写好一段C代码，敲下gcc -O2 hello.c -o hello，程序跑起来比-O0快了一截——背后不声不响干活的，就有“窥孔优化”（Peephole Optimization）。
不是放大镜，是编译器的“火眼金睛”
它不看整段函数，也不分析数据流，就盯住汇编代码里连续几条指令（通常3～5条），像凑近显微镜一样，挨个扫：有没有更短、更快、更省资源的替代表达？发现就直接换掉。比如把mov eax, 0和add ebx, eax这两句，一眼看出eax是0，立马换成add ebx, 0，再进一步简化成nop（空操作）或干脆删掉。
真实场景里它干过啥？
某次调试嵌入式设备时，同事发现一段循环里反复执行test eax, eax再跳转。生成的汇编里紧跟着jz label——其实test eax, eax本身就会设置零标志位，而jz正是查这个标志。窥孔优化器直接把这两条合成一条：je label，少了一条指令，循环每跑一次就省一个周期。
再看个代码片段
原始生成的x86-64汇编（未优化）：
mov ecx, 1
shl edx, cl
mov eax, edx窥孔优化后可能变成：
mov eax, edx
shl eax, 1不仅少了一次寄存器搬运，还避免了用cl作为移位计数器带来的潜在性能惩罚（某些CPU对非cl寄存器移位有额外延迟）。
它和电脑安全有啥关系？
很多人以为优化只关乎速度，其实它也影响安全行为。比如，某些防御性检查（如数组越界断言）如果被窥孔优化误判为“永不触发”，就可能被整块删掉；又比如，加了volatile关键字的内存访问，若优化器没识别到位，也可能被合并或重排，导致安全机制失效。逆向分析恶意软件时，看到一堆看似冗余的mov reg, reg或无意义的xor eax, eax，十有八九就是窥孔优化留下的痕迹——它删掉了中间步骤，但保留了必要副作用。
它不是万能的
窥孔优化只看局部，没法跨基本块推理。比如一个变量在前一个if分支赋值为0，在后面用到，它不会追过去确认；它只信眼前这几条指令的语义。所以现代编译器会把它放在优化流水线靠后的阶段，先做完全局优化，再用这双“小眼睛”做最后一遍精修。