原则：前端不做金额提取和金额运算，一律不得私自做，必须上报TL评估，做好原则上不会同意的预期！

1. 为什么不做金额提取？

前端做金额提取，是个非常不可控的事情。我们常常碰到一些需求，如服务端接口返回中，只有5元优惠券这种中文文案，而推服务端改动难度太高，而业务又图便利，最后倒逼前端，由前端做金额数字提取。在特定场景下，确实这种模式帮助业务解决了问题，但埋下的风险巨大。
前端做的金额提取可靠么？？不可靠！非常不可靠！非常非常不可靠！
举几个金额提取的例子：

  • ✅5元优惠券，提取出数字5，完美；
  • 🔲“1212当天满2元优惠券”呢，会不会提取成“12122”
  • 🔲为了修复这个bad case，我们强匹配了“XX元”，结果出现了另一种券“满12元减2元”，提取出来的是“12”还是“2”？？
  • 🔲有些同学会说，我们和业务方确定好了，只会有这种类型券，不会出现其他的。。。一切很美，但抱歉，结果业务方配置的时候，拿到了一个错误的活动id，不小心配错了活动，导致引入了不相关的券，从而又中了意料之外的情况。

前端拿到的就是二手数据，所以，没法充分评估到被处理数据背后的复杂度，从而，前端做金额提取是一个高危的事情。

2. 为什么不做金额运算？

前端的浮点运算不可靠，这是每个前端应该掌握的必备知识。

  1. // 加法 =====================
  2. // 0.1 + 0.2 = 0.30000000000000004
  3. // 0.7 + 0.1 = 0.7999999999999999
  4. // 0.2 + 0.4 = 0.6000000000000001
  5. // 2.22 + 0.1 = 2.3200000000000003
  7. // 减法 =====================
  8. // 1.5 - 1.2 = 0.30000000000000004
  9. // 0.3 - 0.2 = 0.09999999999999998
  11. // 乘法 =====================
  12. // 19.9 * 100 = 1989.9999999999998
  13. // 19.9 * 10 * 10 = 1990
  14. // 1306377.64 * 100 = 130637763.99999999
  15. // 1306377.64 * 10 * 10 = 130637763.99999999
  16. // 0.7 * 180 = 125.99999999999999
  17. // 9.7 * 100 = 969.9999999999999
  18. // 39.7 * 100 = 3970.0000000000005
  20. // 除法 =====================
  21. // 0.3 / 0.1 = 2.9999999999999996
  22. // 0.69 / 10 = 0.06899999999999999

有同学反馈，前端已经有一些库能解决这个问题？那么，这些库真的完美确保能解决？直接引用第三方库你放心么？引入进来，页面提及增大了，用户体验是不是会下降。
原则上，前端不做金额计算！