我了解到Clojure阅读器将后缀为'M'（如1.23M）的十进制文字解释为BigDecimal。我还知道，没有"M"的十进制数字会变成Java双精度
但我认为正常的十进制数最好是BigDecimal，而依赖主机的十进制数有后缀，比如1.23H。因此，当数字由于IEEE double的精度限制而被损坏或截断时，我们可以很容易地注意到数字的精度受到限制。此外，我认为更简单的表达应该是独立于宿主的
除了时间性能之外，Clojure将字面小数解释为Java双精度还有什么原因吗？此外，我不认为时间性能是一个答案，因为它不是C/C++，其他声明主机相关小数的方法可以像"1.23H"一样实现。
对于整数，Clojure会在需要时自动升级到更大的大小。已更改此项，以便引发溢出异常。从远处看，我的感觉是：
- Clojure是一种实用的语言，在实用的时间内做实用的事情。他们不希望性能爆炸，因为数字运算意外地使用了任意精度库，而不是CPU整数运算。相比之下，这个方案似乎把数学的精确性置于实用性之上
- 当运行时互操作调用失败时，人们不喜欢感到惊讶，因为Java库需要32位整数，而不是任意大小的整数
因此，我们决定默认使用普通整数（我认为Java longs？），并且只有在程序员要求时，当程序员在知情的情况下决定他们愿意承担性能打击和互操作打击时，才使用任意大的整数。
我的猜测类似于对带小数点的数字所做的决定。
性能可能是一回事。也许clojure.core的开发人员可以插话说明原因。
我个人认为默认情况下不使用大小数并不是什么大不了的事情，因为：
- 正如你所指出的：
M - 有类似
+'、*'、-'的操作。。。（注意引用）"支持任意精度"