你写完一段 C 代码，敲下 gcc -O2 hello.c，程序跑得比 -O0 快了一截——背后不声不响干苦力的，除了循环展开、内联函数这些大动作，还有一群在指令流里“扒缝儿找漏洞”的小能手：窥孔优化（Peephole Optimization）。
不是宏观调度，是微观修图
想象你在修一张高清照片：全局调色是编译器前端做的语义分析和中间表示优化；而窥孔优化，就像打开 Photoshop 的放大镜工具，只盯着连续三五条汇编指令，看有没有“多余动作”、“画蛇添足”或者“本可一步到位”的地方。它不关心整个函数逻辑，只信奉一条铁律：局部看起来冗余，就删；局部能合并，就合；局部有更优等价替换，就换。
真实场景里它干了啥？
比如这段常见操作：
mov eax, 5
add eax, 0加 0？纯属摆设。窥孔优化器扫到这两行，直接砍掉第二行，省一个指令周期。
再比如：
shl ebx, 1
shl ebx, 1左移两次，等于左移两位。它会替换成：
shl ebx, 2更省指令，也更利于后续流水线调度。
还有经典例子：用加法代替乘法。
imul eax, 8在 x86 上，会被替换成：
shl eax, 3因为移位比乘法快得多——这不是猜的，是目标平台指令延迟表写死的常识。
它为啥不怕“改错”？
关键在于：所有窥孔规则都基于等价变换。它从不改变程序行为，只压缩表达形式。比如把 test eax, eax + jz label 替换成 cmp eax, 0 + jz label，表面看没变，但某些 CPU 对 test 的标志位预测更准；又或者把连续两条 push 合并成一条 push imm32 指令（如果架构支持），都是硬件层面确认过“效果完全一样，只是更快”的安全替换。
它藏在哪？你其实天天在用
LLVM 的 PeepholeOptimizer pass、GCC 的 combine 和 redundant_set 优化阶段、甚至 Java HotSpot 的 C2 编译器后端，都有它的影子。你用 -O2 或 -O3 编译时，它就在后台默默扫描每一块生成的机器码片段，像老裁缝对着布料找线头，一揪一个准。
它不炫技，不造轮子，只做一件事：让本该干净的指令流，变得更干净一点。