C#中存储金额用int AmountInCents还是decimal Amount？哪种更优？

首先是两种方案的参考实现：
使用AmountInCents（分单位整数存储）：

public class Money
{
   public int AmountInCents { get; set; }
   ...
}

使用decimal Amount（标准单位十进制存储）：

public class Money
{
   public decimal Amount { get; set; }
   ...
}

int类型存储分单位金额的优缺点 #

优点 #

• 彻底规避浮点精度问题：整数运算不存在精度丢失风险，不需要额外处理四舍五入尾差，不会出现类似0.1 + 0.2 != 0.3的底层逻辑bug
• 运算、存储性能更高：整数的读写、计算开销远低于decimal类型，高并发交易场景下性能优势更明显
• 跨系统兼容性更强：对接第三方接口、跨语言交互时，整数的序列化/反序列化规则统一，不会出现不同语言decimal精度处理不一致的问题

缺点 #

• 开发心智负担高：所有金额展示、业务计算都需要手动做单位转换，比如展示人民币元时要除以100，一旦遗漏转换就会出现金额放大100倍的严重业务bug
• 存储范围受限：32位int的最大值对应人民币仅约2147万元，大额交易、外汇场景下必须替换为long类型，处理不当容易出现溢出问题
• 适配场景有限：不支持厘级及更细粒度的金额运算（比如利息计算、手续费分摊），也无法适配非十进制的特殊货币

decimal类型存储标准单位金额的优缺点 #

优点 #

• 符合业务直觉：直接存储对应货币单位的金额数值，不需要做单位换算，业务代码可读性更高，能大幅降低单位转换类bug的出现概率
• 适用场景更广：支持任意精度的金额运算，不管是细粒度计息还是超大额交易，decimal的精度范围都可以覆盖绝大多数金融场景的需求，也能适配非十进制的特殊货币
• 扩展成本低：后续业务调整币种、新增细粒度金额计算需求时，不需要改造底层存储结构

缺点 #

• 需要额外处理精度规则：乘除运算时必须显式指定四舍五入规则、保留小数位数，处理不当容易出现尾差不一致的问题
• 性能略低于整数：虽然普通业务场景下性能差异几乎感知不到，但超高并发的核心交易链路可能会有细微的性能损耗
• 跨系统对接有兼容风险：部分序列化协议、编程语言对decimal的支持不完善，比如JSON标准没有定义decimal类型，传输时如果误转成float/double会直接丢失精度，需要额外做兼容处理

选型建议 #

不存在绝对最优的实现，需要结合业务场景选择：

• 如果业务为单一十进制货币、无细粒度金额计算需求、并发量极高，优先选择int/long存储分单位的方案，性能高且精度问题少
• 如果业务涉及多币种、需要支持细粒度金额计算、业务逻辑复杂，优先选择decimal方案，开发效率更高、可扩展性更强

注意：无论选择哪种方案，绝对不能使用float、double这类二进制浮点类型存储金额，必然会出现精度丢失问题。

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