重构方案：订单金额计算 calcTotal()

跑完四步工作流后，对一段 120 行的遗留 calcTotal() 得到的产出。

1. 现状理解

该函数同时做了四件事：取购物车、算折扣、算税、发埋点。隐含假设：items 非空、币种恒为 CNY。最危险的 3 点：

• 折扣与税的计算顺序写死，改顺序会静默改变结果
• 浮点直接相加，存在分位误差
• 中途 throw 但调用方未捕获

2. 刻画性测试（先锁住现有行为）

| 场景 | 输入 | 当前输出 | 说明 | |---|---|---|---| | 正常 | 2 件 + 满减 | 168.00 | 基准 | | 空购物车 | [] | 抛错 | 记录现状（即便是 bug） | | 临界 | 折扣后为负 | -3.00 | 现状有问题，先锁住 |

3. 小步重构计划（每步可独立提交）

1. 抽出 applyDiscount() 纯函数 —— 跑测试
2. 抽出 applyTax() 纯函数 —— 跑测试
3. 把埋点移出计算函数，由调用方负责 —— 跑测试
4. 金额改用整数分运算，消除浮点误差 —— 跑测试
5. 空购物车返回 0 而非抛错（行为变更，需产品确认）

4. 回归自检

• [x] 折扣 / 税 / 埋点已解耦，顺序显式可见
• [x] 浮点误差用例通过
• [ ] 第 5 步为行为变更，单独 PR + 知会调用方

结论： 前 4 步纯结构改进、行为等价，可合并；第 5 步另起 PR。