价格为什么必须服务端算
价格、数量、折扣、运费这类数值只要由客户端提交，就必须在服务端重新计算与校验。典型问题是负数量、零元单、精度截断（如 0.001 元）、跨币种混算与折扣重复叠加。判断标准很直接：订单最终金额是否完全由服务端的商品与规则数据推导，客户端数值只作为选购意向。
基本信息
| 检查对象 | 下单、改单、加购、结算、运费与发票金额接口 |
|---|---|
| 核心原则 | 服务端重算价格链，客户端数值不可信 |
| 验证方式 | 测试商品 + 测试账号，构造边界数值 |
| 风险控制 | 涉及真实库存与资金，禁止在生产环境制造真实订单 |
典型使用场景
- 电商结算链路的价格与优惠校验核查
- 验证数量字段是否接受负数、零、超大值与小数
- 检查折扣、券、积分叠加顺序是否与规则一致
- 排查“改包重放”式的价格篡改路径
- 评估退款、部分退款场景下金额是否可被反向利用
验证思路（测试环境）
验证思路（测试环境）
1. 抓取下单请求，标注所有金额与数量字段（单价、总价、运费、折扣、币种）
2. 逐个改为异常值：负数、零、0.001、超精度、跨币种；观察服务端是否拒绝
3. 对照服务端返回的结算明细，确认金额来源是订单数据库而非请求体
4. 验证后回滚测试数据，并在报告中注明使用的测试商品与账号常见问题与判据
| 问题形态 | 现象 | 判定要点 |
|---|---|---|
| 负数量 | 提交负数导致总价反向减少 | 服务端未对数量下限做校验 |
| 精度截断 | 0.001 元单价被截断为整数 | 金额用浮点运算或未按最小单位校验 |
| 折扣叠加 | 券与折扣同时生效形成折上折 | 规则校验只看单条不看成组 |
| 跨币种 | 币种字段可随意切换 | 币种与商品定价未做绑定 |
| 客户端定价 | 请求体价格被直接采用 | 服务端没有重算价格链 |
金额建议以最小货币单位（整数分）存储与计算，避免浮点误差带来的对账偏差，这也是很多“偶发一分钱问题”的根因。
验证必须在联调或测试环境完成；在生产环境构造低价订单会直接产生真实资金与库存影响，属于超出验证边界的动作。