必须采用分层限流+幂等+异步化+资源预占四层组合拳，因批量下单具原子性放大效应和下游雪崩杠杆；单靠goroutine+rate.limiter会失效，需按订单粒度二级限流、redis+lua预占库存、异步落库并保障幂等与超时对齐。
单靠 goroutine + rate.Limiter 会直接打崩库存服务——批量下单不是普通请求，它自带“原子性放大效应”和“下游雪崩杠杆”。必须用分层限流 + 幂等 + 异步化 + 资源预占四层组合拳。
为什么批量下单不能直接用 rate.Limiter
常见错误是给 /api/v1/orders/batch 接口配一个全局 rate.NewLimiter(50, 100)。这会导致：
- 一个批量请求含 100 个订单，
Allow()只校验一次，但实际触发 100 次库存扣减——限流形同虚设 - burst=100 不代表“允许 100 单”，而是“最多借 100 个令牌”，若库存服务响应慢（如 Redis 链路抖动），这些令牌长期不归还，后续请求全被拒
- 所有用户共用同一桶，恶意用户发 10 个大批次，就能挤占全部额度，正常用户直接 429
按订单粒度做二级限流：IP → 用户 → 单次批量内订单数
真正有效的控制点在「每个批量请求内部」，而非接口入口。关键动作：
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
- 解析请求体，提取
orders数组长度，记为n - 对每个订单构造唯一 key：
"user:" + userID + ":order:" + orderID（避免重复提交） - 用
sync.Map缓存 per-user 的*rate.Limiter，初始化参数按业务分级：
普通用户：rate.NewLimiter(rate.Limit(5), 10)（每秒 5 单，最多透支 10 单）
VIP 用户：rate.NewLimiter(rate.Limit(20), 40) - 逐个调用
limiter.Allow()，任一订单被拒，整批返回 429，并带明确提示：{"code":429,"message":"user xxx exceeded order limit"}
用 Redis + Lua 实现跨实例的库存预占
本地限流只防过载，不保一致性。批量下单必须提前锁定库存，否则超卖。推荐方案：
- 不用 SETEX，改用 Redis
EVAL执行 Lua 脚本，一次性完成：
① 检查各商品当前可用库存
② 若足够，对每个sku:123执行DECRBY stock:123 n
③ 写入预占记录：hset prelock:batch_abc sku:123 n，并设 TTL=10m - 脚本返回结果必须是原子布尔值：
1表示全部预占成功，0表示任一失败，后端不做任何补偿操作 - 失败时立即返回 409 Conflict，不走后续流程；成功则进异步队列，由 worker 持久化订单并清理预占
- 注意：Lua 中不能用
redis.call("INCR")替代DECRBY，否则负数库存无法识别
异步化与幂等落地细节
预占成功 ≠ 订单创建成功。必须解耦，且保证可重试：
- HTTP 接口只做预占和入队，响应中返回
batch_id和状态"accepted"，不等 DB 写入 - 使用
goroutine启动 worker，但必须加信号量控制并发：sem := semaphore.NewWeighted(int64(50))（根据 DB 连接池大小定）
每个 worker 先Acquire(ctx, 1)，处理完再Release(1) - 订单表主键必须用业务 ID（如
batch_id + "-" + order_seq），避免 insert on duplicate key 导致幂等失效 - 预占记录清理必须双保险：TTL 自动过期 + worker 成功后显式
DEL prelock:batch_abc
最容易被忽略的是预占 TTL 和 DB 超时的对齐——如果 worker 处理超时（比如卡在支付回调），而 Redis 预占已过期，此时重试就会重复扣减。必须让 TTL ≥ worker 最大预期耗时 + 重试窗口，且所有环节（HTTP timeout、DB context、Redis pipeline）超时值要阶梯递增，不能一样。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
