新建优惠券后少量测试，前台突然提示 Usage limit has been reached，后台列表看起来使用次数为零。Magento 同时存在规则总次数、单个 Coupon 次数和每客户次数，定制模块还可能在下单前预占，不能只看一个字段。

先区分三个限制

检查 Sales Rule 的 Uses per Customer、Coupon 的 Uses per Coupon，以及自动生成 Coupon 自身记录。没有登录的访客通常无法按 customer_id 精确限制，扩展可能改用邮箱或 Session。

SELECT rule_id, code, usage_limit, usage_per_customer, times_used
FROM salesrule_coupon
WHERE code = 'TESTCODE';

字段以实际版本结构为准，只读诊断。规则级使用统计还可能在其他表中。

取消订单是否回退

Coupon 一般在订单提交时计数；失败支付、取消、退款是否回退，取决于核心流程和扩展实现。按订单号追踪 applied_rule_ids、coupon_code 与状态历史，不能直接把 times_used 清零，否则可能让真实已用客户重复享受。

并发最后一次额度

两名客户同时使用仅剩一次的券时，简单“先查次数再加一”存在竞态。需要数据库原子更新/锁和幂等订单键。支付重试也不能为同一订单重复计数。

客户记录不一致

规则总次数未满，但某客户提示到限，检查 customer-rule usage 表是否因测试账号、网站范围或客户合并留下记录。多网站共享账号时，业务期望是全局一次还是每网站一次必须明确。

修复后测试访客、登录客户、最后一个名额的并发、支付失败、取消和重复回调。次数统计应可由订单审计解释，不能只让提示消失。

规则 ID 与 Coupon ID 不要混淆

一个 Sales Rule 可有大量自动 Coupon，每个 code 有独立 coupon_id。自定义统计若只按 rule_id 聚合，会把其他券使用次数算到当前 code；反过来只看 coupon 表会漏掉无券自动规则。对账需从订单 coupon_code、applied_rule_ids 和 usage 表建立对应。

缓存与多节点

使用次数更新到数据库后，某节点仍缓存旧 rule/coupon 对象，可能继续放行或错误拒绝。高并发限额必须以数据库原子条件为最终权威，缓存只能加速。规则变更后按支持方式失效缓存，并验证所有节点。

恢复统计

如果历史 times_used 已不一致，先从可确认的有效订单重算报表，列出差异和取消/失败策略，再以审计脚本修正。直接重置为零会改变促销成本和客户资格。

错误文案可能掩盖真正条件

第三方促销模块常把多种拒绝原因统一成 Usage limit reached，例如日期范围、客户组、网站或最小金额失败。对同一 quote 开启受控调试，记录规则逐条件结果，确认确实命中次数限制后再修统计，不能被前台一句提示带偏。

高峰活动前做容量与竞态测试

限量券最容易在秒杀流量下暴露并发问题。用多请求争夺最后几个名额，统计成功订单、失败订单与 times_used，三者必须能对账；再重复支付回调和取消流程，确认不会超发，也不会永久吃掉未成交额度。