limit_number 这个限购字段后台本身就能配置，加购和提交订单时也会进行拦截。运营真正需要的是礼盒类商品“2 件起购”这样的购买下限，而系统默认并没有这个下限字段。我补充实现的是 min_buy，不要和限购逻辑混为一谈。要是直接写成“系统没有限购”，很容易被熟悉业务的人当场指出问题。

背景就一句，但我得多掰扯两句

礼盒商品不能只买 1 件，同时还得防止黄牛大量囤货。但这类需求并不是秒杀场景，没必要动不动就上 Redis。很多人一听到“限购”就想用 Redis 控制，结果折腾半天，对于日常只有几十单的小店来说，维护成本反而比实际业务成本还高，确实没必要。把 min_buy / limit_number 配在商品或 SKU 维度上，日常商城运营基本就够用了。

能直接粘的校验

在 CartService 里加购时拦一次，OrderCheckService 提交订单时再拦一次。只做前端校验，基本等于没做：

 0 && $qty < $min) { throw new Exception("该商品 {$min} 件起购");}if ($max > 0 && ($bought   $qty) > $max) { throw new Exception('超过每人限购数量');}}}

口径你自己定

待付款订单是否占用限购额度，这个规则要提前定清楚。我的做法是占用，关单后再释放。如果不占，就很容易有人挂一堆待付款订单来占额度、囤资格。到底按 SPU 维度还是按 SKU 维度限制，也一定要写进需求文档。规则含糊就上线，最后往往不是代码出问题，而是客服电话先被打爆。我踩过这个坑，确实很惨。

Admin 别装死

后台商品编辑页最好加上“起购数量”字段，默认值设为 0，表示不限购数量下限。商品详情页也建议明确展示“X 件起购”。否则用户加购失败时一脸懵，不知道为什么不能买，体验分会直接下降。系统里有限购字段，却没有起购数量配置，运营很容易误以为商城系统出故障了。

怎么测

至少要把这几种情况测完整：未达到起购数量、刚好达到起购数量、超过限购数量、关单后再次购买。四种核心流程都走通了，这个购买限制闸门才算真正装好。少测一项，问题大概率就会留到线上补；而线上修补，往往才是成本最高的。

跟限购怎么配合

一定要理清这两个字段的边界：limit_number 用来控制购买上限，min_buy 用来限制起购下限，两者必须独立配置、分别生效。以礼盒商品为例，如果设置为“2 件起购、5 件限购”，那这个数字一定要填写准确——运营一旦填反，系统可不会替你背锅。商品详情页直接展示“2 件起购，每人限购 5 件”，比用户提交订单后才看到报错提示要友好得多。展示清楚，用户体验更好，售后咨询和客诉自然也会少一些。说到底，起购数量是零售商城场景中的高频需求，千万别把它和秒杀限购逻辑混在一起；一旦混淆，不仅产品规则会乱，连报价逻辑和开发工期都会跟着失控。