阿噫哟丶先说结论：把 0.1f 改成 0 之后性能降低 10 倍，这个问题看着像"浮点 vs 整数"的较量，但十有八九是循环本身出了状况。我最早在一段图像处理的代码里遇到过类似的坑：有人为了"优化性能"，把循环步长从 0.1f 改成了 0，结果程序不仅没变快，反而慢到像是死循环，最后排查下来才发现，步长变成 0 之后循环次数从几十次直接变成了几十万次甚至无限循环，性能当然要崩。
不过这个标题真正值得聊的地方不止于此：0.1f 在计算机里到底怎么存的、浮点运算和整数运算在 CPU 层面的执行路径有什么本质区别、编译器对浮点循环和整数循环的优化策略为什么完全不同，这些才是值得掰开揉碎讲清楚的东西。这篇文章我打算从现象入手，一层层拆到指令级别，再把编译器优化、常见误区和排查手段都过一遍，希望能帮你在以后写代码的时候少踩几个类似的坑。
1. 现象还原：一个"改错"引发的性能雪崩
1.1 原始代码到底长什么样
涉及这类性能话题时，网上流传最广的一段代码是经典的"臭豆腐"循环，用浮点数在屏幕上画一个心形或者某个函数曲线，核心结构长这样：
c复制#include <stdio.h>
int main() {
float x, y, a;
for (y = 1.5f; y > -1.5f; y -= 0.1f) {
for (x = -1.5f; x < 1.5f; x += 0.05f) {
a = x * x + y * y - 1;
putchar(a * a * a - x * x * y * y * y <= 0.0f ? '*' : ' ');
}
putchar('\n');
}
return 0;
}
这段代码里，0.1f 是内层循环的步长吗？不是，它是外层循环的步长。y 从 1.5f 开始，每轮减去 0.1f，直到 y 小于等于 -1.5f 为止。理论上，1.5 到 -1.5 之间步长 0.1，应该循环 30 次左右。
如果这时有人"灵机一动"：0.1f 是浮点数，浮点运算慢，我把 0.1f 改成 0，这样 y 减去 0 等于没减，循环条件 y > -1.5f 永远成立，程序就进入无限循环了。每秒刷屏几千次，CPU 占满，性能表象上就是"慢了 10 倍"甚至更多——实际上不是慢了 10 倍，是彻底跑不完了。
1.2 改成 0 会触发哪些连锁反应
把 0.1f 改成 0，表面上是把浮点常量换成了整数常量，实际引发的连锁反应有三个层面：
第一，循环次数从有限变成无限。y 不再变化，y > -1.5f 恒为真，外层循环永远不会退出。这是性能雪崩的最直接原因，和浮点还是整数、快还是慢没有半毛钱关系。
第二，编译器对 y -= 0 的优化。y = y - 0，在 IEEE 754 浮点标准下，y - 0 在大多数情况下等于 y，但有一个例外：-0.0f - 0.0f 在某些舍入模式下结果可能是 +0.0f。编译器如果严格遵循 IEEE 754，它不能直接把 y -= 0.0f 优化成空操作，因为要保证 -0.0f 的场景。但如果编译器开启了一些激进优化，它有可能把 y -= 0 优化成什么都不做，此时循环退化为一个纯比较循环，反而 CPU 占用率会下降。可现实中，很多编译选项不会这么激进，循环体照样执行，只是 y 永远不变。
第三，如果原始代码里不是 0.1f 而是某个变量，改成 0 后还可能破坏循环内部的依赖链，导致自动向量化失效。比如循环里用到 y 参与计算，y 不变后，原本每次迭代都要重新加载 y 和计算 a，现在虽然值不变可依赖关系变了，编译器可能因此放弃一些优化。
所以，"把 0.1f 改成 0 会导致性能降低 10 倍"这个命题，真正的主角不是浮点和整数的算力差异，而是循环语义的根本改变。 在聊清楚浮点和整数的性能差异之前，必须先把这层窗户纸捅破，否则后面所有分析都是在误导人。
1.3 什么情况下"浮点改整数"真的会慢 10 倍
当然，抛开"步长为零"这种低级错误，"浮点改整数后性能反而下降"在真实项目里也存在，而且原因相当隐蔽。我见过的一个真实案例是：一个跑在嵌入式平台上的音频算法，原本用 float 做滤波系数，后来为了"优化"把系数全部改成定点整数，结果代码跑起来慢了 8~10 倍。
原因有两层。第一，原平台有硬件 FPU（浮点运算单元），float 加减乘除都是单指令完成；改成整数后，乘法用的还是硬件整数乘法，可除法却变成了软件模拟——有些嵌入式内核没有整数除法指令，`int