Solidity中为何不支持小数、float/double浮点数类型？

• 共识机制的确定性要求是最核心约束
  区块链网络要求所有节点对同一笔交易的执行结果完全一致，否则全网根本达不成共识。通用的IEEE 754标准浮点数，在不同CPU架构、不同编译器实现、不同编译优化等级下，运算的舍入规则、精度截断结果都可能出现细微差异——比如x86平台FPU浮点单元的扩展精度运算结果，和ARM平台的标准浮点运算结果就可能对不上，这种非确定性行为会直接导致链上状态分叉，是公链设计绝对不能碰的底层风险。
• 浮点数的精度特性天然不匹配Solidity的核心场景
  Solidity从诞生起核心定位就是面向链上资产、金融逻辑的合约开发语言，IEEE 754浮点数用二进制科学计数法存储，绝大多数十进制小数都没法精确表示，比如大家熟悉的0.1存成浮点数实际是个无限趋近于0.1的近似值，经过多轮乘除、累计运算后误差会被持续放大，很容易在转账、分红、价格清算这类对精度零容忍的场景里捅出资金漏洞，这类问题在不可篡改的链上环境里连事后补救的机会都没有。
• EVM指令集与Gas模型的设计取舍
  EVM从最初设计时就没加浮点运算的专用指令，如果要在语言层面实现符合共识要求的浮点数逻辑，每一步运算的舍入、进位、异常处理都得用确定性的通用指令模拟，运算步骤数会比整数运算多好几倍，对应的Gas消耗会高到离谱，执行效率也极差。反过来行业通用的定点数方案——也就是根据业务需要的精度把小数放大成整数存储（比如要保留18位精度就把数值乘1e18转成uint256类型存），可以直接复用EVM原生的整数运算指令，执行成本低、结果完全可控，能覆盖绝大多数需要小数运算的场景，根本没必要为了支持浮点数承担额外的风险和成本。
• 底层设计的路径依赖
  EVM早期设计参考了比特币脚本的实现逻辑，比特币脚本作为面向转账场景的简单栈式脚本，本身就只支持整数运算，Solidity作为EVM上最早落地的高级语言，自然继承了底层的整数运算设计，后续版本迭代也一直没加原生浮点支持，本质就是前面三类核心约束到现在也没发生变化。

你能搜到的绝大多数资料提到的浮点数缺失应对方案，本质都是用整数实现的定点数方案，通过提前约定固定的小数位数，把小数运算全部转化为整数运算，绕开浮点数的固有缺陷。

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