限购字段（limit_number）后台能配，加购和提交也会拦。运营要的是礼盒「2 件起购」——这个下限字段默认没有。我补的是 min_buy，别和限购混成一锅。写成「系统没有限购」会被读者打脸。
背景就一句，但我得多掰扯两句
礼盒不能买 1，又怕黄牛囤。这不是秒杀。别上 Redis。有人一听限购就上 Redis，搞半天，日常几十单的店，维护成本比业务高。真没必要。min_buy / limit_number 挂商品或 SKU，日常够用。
能直接粘的校验
CartService 加购拦一次。OrderCheckService 再拦一次。只拦前端等于没拦：
<?php
namespace app\service\front\product;
class BuyLimitCheck
{
public static function assert(array $product, int $qty, int $bought = 0): void
{
$min = (int)($product['min_buy'] ?? 0);
$max = (int)($product['limit_number'] ?? 0);
if ($min > 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 件。」比报错弹窗友好。友好一点，客诉少一点。真的少一点。起购是零售场景高频需求，别和秒杀限购混为一谈。混了，报价和工期都乱。
