应采用策略模式解耦会员级别与折扣规则，定义DiscountStrategy接口及VIP、Gold等具体实现类，通过外置配置映射级别到策略，购物车委托计算并支持组合与单元测试。
用标准面向对象结构实现购物车折扣计算，核心是把“会员级别”和“折扣规则”解耦，让不同级别可独立扩展、互不影响。关键不是硬编码 if-else，而是通过多态和策略模式让系统自然适配变化。
定义统一折扣策略接口
所有会员级别的折扣逻辑，都应实现同一个抽象行为。定义一个 DiscountStrategy 接口（或抽象类），只暴露一个方法：calculateDiscount(cartItems, originalTotal)。
- 接口不关心谁调用、何时调用，只承诺返回一个折扣金额（或折扣后金额）
- 具体实现类如 VIPDiscountStrategy、GoldDiscountStrategy、BasicDiscountStrategy 各自封装自己的计算逻辑
- 避免在策略里访问用户数据库或 session —— 折扣策略只接收已知参数，保持无状态
会员级别与策略一一绑定
购物车不直接判断“用户是不是 VIP”，而是根据用户当前的 memberLevel 字段，查表或配置映射到对应策略实例。
- 可用简单工厂或依赖注入容器完成绑定，例如：strategy = strategyFactory.getStrategy(user.getLevel())
- 映射关系建议外置（如 YAML/JSON 配置），避免改代码就能切换某级别折扣规则
- 若某级别暂时无特殊规则，可返回 NoDiscountStrategy，而非空指针或条件跳过
购物车聚合策略并延迟计算
购物车对象本身不持有折扣逻辑，只持有一个 DiscountStrategy 引用，并在需要时委托计算。
- 调用时机明确：比如 checkout() 或 getFinalAmount() 时才触发计算，避免冗余执行
- 传入参数应包含必要上下文：商品列表、原价、是否叠加优惠券、是否跨店等 —— 策略内部决定哪些字段有用
- 支持组合策略：如“VIP + 满300减50”可设计为 CompositeDiscountStrategy，包装多个子策略顺序执行
测试与扩展要点
每个策略类应能被单独单元测试，无需启动整个应用。
- 测试用例覆盖边界：VIP买1元商品是否仍享85折？黄金会员满减是否低于最低折扣门槛？
- 新增会员等级只需新增策略类 + 更新映射配置，不改动购物车、订单、用户模块
- 若折扣规则含时间敏感逻辑（如“双十二期间VIP额外加赠5%”），把时间作为策略构造参数传入，而非在策略内调用 new Date()
