由于部门所做的都是与财务相关的系统，所以无时无刻不在与金钱打交道，在处理金额相关的数据时难免出现一些错误，甚至会出现一些匪夷所思的结果。本文针对工作中出现的问题做一下总结。
项目中遇到的金额计算结果精度问题，比如下例：
我们期望的结果是0.2，用JS这样计算也会出现类似的精度问题，可为什么会出现这么匪夷所思的结果呢？ 这是由于浮点数（Float）的存储规则导致的，因为Float和Double都是浮点数，都有取值范围，都有精度范围。浮点数与通常使用的小数不同，使用中往往难以确定。我们先来看十进制0.2如何转换成二进制（使用乘2取整，顺序排法），我们发现0.2不能用二进制准确表示，在二进制世界里这是个无限循环的小数，常见的问题是定义了一个浮点数, 经过一系列的计算, 它本来应该等于某个确定值, 但实际上并不是!
使用BigDecimal，BigDecimal类是专门为解决浮点数无法精确计算而设计的，并且提供了常用的算术运算方法。特别是与数据库Decimal映射时，BigDecimal是最优方案。针对mysql数据库，BigDecimal在进行入库时，数据库可选择decimal类型，长度可以自定义，如18；小数点我们项目中用的是2， 保留2位小数。此外还要注意的就是默认值，一定写成0.00，不要用默认的NULL，否则在进行加减排序等操作时，会带来转换的麻烦！
系统之间需要传递金额类型的数据时，可用字符串类型进行系统间的交互。不过在金额字符串转换成金额数值的时候要注意，否则可能会出现错误。比如下面这个例子：
我们希望得到金额数值，结果却是用科学计数法表示的字符串，原因是浮点型数据位数超过10位之后，数据变成科学计数法显示。解决这个问题可用下列方法：
对金额数据格式化输出，比如我们常见的金额数据千分位显示，可用NumberFormat进行格式化。与 DateFormat 类似，NumberFormat 是一个抽象类。您永远不会创建它的实例，相反您总是使用它的子类。虽然可以通过子类的构造函数直接创建子类，不过NumberFormat 类提供了一系列 getXXXInstance() 方法，用以获得不同类型的数值类的特定地区版本。如果做一些国际化的系统，也可以用此类做一些国际化的输出。
在系统列表页面显示金额数据时建议采用右对齐的方式，方便用户很直观的比较金额数据的大小。如下图所示：
