优惠券满减逻辑应抽离至computed或methods中，避免模板内复杂判断；核心是校验订单金额≥minAmount且券未过期、启用；须用整数单位防浮点误差，禁用叠加并前端拦截。
优惠券满减逻辑该放在哪里写
不要在 v-for 模板里直接写复杂判断，更别用 v-if 套三层条件。满减逻辑本质是数据处理，应该抽成计算属性或方法，让视图只负责渲染。
- 推荐写在
computed里：适用于优惠券列表固定、订单金额变化时需实时重算可用券的场景 - 如果要支持“修改商品后动态刷新可用券”，用
methods+ 手动调用更可控，避免响应式依赖混乱 - 千万别把满减门槛（比如
minAmount: 100）和折扣逻辑（discount: 20）硬编码在模板里，后期改规则会疯
怎么判断一张券是否满足“满X减Y”条件
核心就两步：看订单总金额是否 ≥ 券的 minAmount，再确认该券未过期、未被使用、状态为启用。注意：满减不是“满就减”，而是“满才能用”。
-
minAmount是门槛值，不是“满多少才开始计算”，它必须 ≤ 当前订单实际支付金额（realPayAmount），才进入可选范围 - 时间判断别只比对
new Date()，uni-app 在 iOS 微信小程序里Date.now()可能不准，建议用uni.getSystemInfoSync().safeArea无关的时间戳服务或后端下发的当前时间 - 示例逻辑：
isCouponValid(coupon) {<br> const now = Date.now();<br> return (<br> coupon.status === 1 &&<br> coupon.startTime coupon.endTime >= now &&<br> this.orderAmount >= coupon.minAmount<br> );<br>}
为什么过滤后券列表为空但实际有可用券
最常见原因是金额精度问题。微信小程序和支付宝小程序对浮点数处理不一致，99.99 + 0.01 在某些环境下可能变成 99.99999999999999，导致 >= 判断失败。
- 统一用分单位（整数）做计算：后端返回
minAmount: 10000（对应100元），前端全部转成整数比对 - 不要用
parseFloat或Number()转用户输入的金额，用Math.round(parseFloat(val) * 100)强制归一 - 检查
orderAmount是否包含运费、红包抵扣等干扰项——满减门槛通常只看“商品总金额”，不是最终实付额
多张满减券能叠加吗？前端要不要限制
绝大多数业务规则明确禁止叠加，前端必须拦截。不能依赖用户自觉，也不能等提交时后端才报错。
- 在券列表渲染前就做过滤，只保留
type === 'full_reduction'且canCombine === false的券 - 选中一张满减券后，立刻禁用其他同类券的 radio 或 switch，DOM 层面阻断误操作
- 如果设计上允许“满减+折扣券”组合（如满100减20，再打9折），那要在后端校验顺序和优先级，前端只做 UI 状态同步，别自己算最终价格
满减逻辑看着简单，但金额精度、时间校准、规则耦合这三点，随便一个没兜住就会导致用户下单失败或优惠没生效。别省那几行代码，该封装的函数一个都不能少。
