必须用嵌套if-else判断会员等级，因其支持条件组合、提前中断和参数动态赋值，而switch无法处理VIP/SVIP/黑卡等需叠加运算的复杂分摊逻辑。
会员等级判断必须用嵌套 if-else，不能只靠 switch
电商系统里会员价格分摊不是简单查表，而是要按等级阶梯动态计算：比如普通用户付全价，VIP 用户扣 5%，SVIP 扣 12% 再叠加满减，而黑卡用户还涉及运费豁免和返现。switch 无法处理这种带条件组合、需提前中断或叠加的逻辑。if-else 的执行顺序和可中断性才是关键。
实操建议：
- 把最常触发的等级（如普通用户、VIP）放在前面判断，避免每次都要穿透到最后一层
- 每个分支内不要只写折扣率，要明确写出该等级对应的
discountRate、freeShipping、cashback等字段赋值，方便后续统一结算 - 避免在 if 分支里直接返回价格——分摊算法通常要先算折扣，再算运费，最后加返现，流程必须解耦
多级分摊必须拆成「基础价→等级折扣→活动叠加→最终价」四步
很多人试图在一个 if 分支里把所有计算塞进去，结果改个满减规则就要重测全部等级。正确做法是让 if-else 只负责生成「分摊参数对象」，不碰具体运算。
示例结构（伪代码）：
let params = { basePrice: order.total, discountRate: 0, freeShipping: false, cashback: 0 };
if (user.level === 'black') {
params.discountRate = 0.12;
params.freeShipping = true;
params.cashback = 0.03;
} else if (user.level === 'svip') {
params.discountRate = 0.12;
params.freeShipping = false;
params.cashback = 0.02;
} else if (user.level === 'vip') {
params.discountRate = 0.05;
params.freeShipping = false;
params.cashback = 0;
} else {
params.discountRate = 0;
params.freeShipping = false;
params.cashback = 0;
}
// 后续统一调用 calcFinalPrice(params)这样改黑卡返现比例时，只动那一行 params.cashback = 0.03，不影响其他逻辑。
注意浮点数精度和整数截断陷阱
用 if-else 算出来的折扣金额如果直接 Math.floor() 或四舍五入，会导致不同等级用户在临界订单（比如 99.99 元）上分摊结果不一致，财务对账会出问题。
常见错误现象：99.99 * 0.12 = 11.9988，前端显示 12.00，后端存储 11.99，两边差 1 分钱。
实操建议：
- 所有中间计算保留小数点后 4 位（用
parseFloat((x).toFixed(4))），最终价统一按分（整数）存储和比对 - if 分支里不要出现
Math.round()，把精度控制收口到最终结算函数 - 测试时必须覆盖边界值：99.99、199.99、999.99，检查各等级下
finalPriceInCents是否严格相等
if-else 链过长时，用 Map + 函数映射替代硬编码
当会员等级超过 5 级，或者要支持区域化配置（如海外黑卡返现 5%），硬写 if-else 不仅难维护，还会让单元测试爆炸式增长。
更可控的做法是用 Map 存等级策略，if-else 只做兜底和默认分支：
const levelStrategy = new Map([
['black', () => ({ discountRate: 0.12, freeShipping: true, cashback: 0.03 })],
['svip', () => ({ discountRate: 0.12, freeShipping: false, cashback: 0.02 })],
['vip', () => ({ discountRate: 0.05, freeShipping: false, cashback: 0 })],
]);
const strategy = levelStrategy.get(user.level) || (() => ({ discountRate: 0, freeShipping: false, cashback: 0 }));
const params = strategy();这样新增等级只需往 Map 里加一项，不用动主干逻辑，也方便从配置中心动态加载。
真正麻烦的是跨系统一致性：订单服务用 if-else 算价，营销服务又用另一套规则校验，两边参数名稍有不一致（比如 cashback vs rebate），就会导致分摊结果错位。这类问题往往上线后才暴露，得靠契约测试卡住。
