价格、金额设计成BigDecimal还是Long？

开发时涉及金额，用什么数据类型处理
今天组长和研发总监吵起来了，
吵架原因是系统中关于价格，金额，设计成BigDecimal还是 Long 。
组长是比较有经验的开发，他觉得应该设计成BigDecimal，他之前带过很多项目都是设计成bigDecimal，从没出过问题。
总监坚持是long，说以前公司金额这块出过大问题，财务把开发骂的狗血淋头，后来改成了long就没有问题了。
以我两年半的开发经验来看，还是设计成long爽一点，计算的时候不用转换，直接干。
大家的项目中有因金额设计问题遇到的坑吗？
bigDecimal有哪些坑？long又有哪些坑？可以一起讨论下
国美电器员工评论：
存储金额，以分为单位，类型long, 我国一般情况下最小货币结算单位就是分， 特殊会用到里，豪之类的。 如果是汇算，利息要求精度比较高的时候， 存储的时候单位就得往下，
豪，微，显示的时候以元为单位，是怎么显示呢？这种分换算成元啊！
test1127算法工程师评论：
long是长整数，财务金额不支持小数点？bigdecimal虽然支持小数点，但是数额溢出就有问题了。
Java中BigDecimal类的最大值和最小值取决于BigDecimal的scale和precision属性。
徐斯远：多加一位精度位数就行了，前端展示直接插入小数点
zyxwvut评论：
用long的通常是不涉及到算利息的纯交易场景，普通交易打折可以直接抹零的。 涉及利息和收益计算的场景，不可能用long。
路漫漫其修远兮l：long单位不是存元，是直接存能结算的最小单位，甚至多预留几位，没有小数问题的。 用long也能行的，而且程序算起来方便！
后厂村少侠程序员评论：
做过三套金融系统，一套理财用BigDecimal，两套信贷用的long。如果再让我选择，我肯定用long。单位到分一般就够了，到厘的话道理是一样的，全局一致就行。很多运算变得简单不易出错，你不能指望人人都会处理好精度问题，long会避免很多麻烦，包括前后端交互也统一用long。实际上连利率都可以用long，系统设置全局精度（倍数），可以避免很多精度问题。
网络侠客新华智云员工评论：
存储用long，但是数值单元用分或者更细的精度；计算用BigDecimal，控制好过程精度。
诸葛瑾ZBoP评论：
什么年代了还讨论低端技术问题，直接问GPT4不就得了：
综合考虑，如果你们的系统需要处理大量的高精度金融计算，并且对计算的准确性有非常高的要求，那么使用BigDecimal是比较合适的。如果系统对性能要求极高，并且可以确保不会出现精度问题（例如总是以最小货币单位进行计算），则可以考虑使用Long。
在实际工作中，应该根据具体需求和团队习惯来决定。同时，也要考虑到现有系统架构和历史代码的兼容性。最好能够有详细的测试来验证所选数据类型在各种情况下的表现，确保不会因为数据类型选择错误而导致财务数据不准确。