Iris不是为秒杀“开箱即用”的框架，不内置分布式锁或原子扣减，但其高性能底座（零分配Context、radix tree路由、并发安全）可快速构建秒杀HTTP入口层，关键逻辑需在handler内同步完成并加锁。
Iris 本身不是为秒杀场景“开箱即用”的框架，它不内置库存扣减、分布式锁或原子计数器。但它的高性能底座（零分配 Context、radix tree 路由、并发安全设计）让你能快速搭出秒杀链路的 HTTP 入口层——关键在于你如何在 iris.Context 之外组织并发控制逻辑。
为什么不能直接用 go 启动 goroutine 处理下单？
常见错误是这么写：
app.Post("/seckill", func(ctx iris.Context) {
go func() {
// 扣库存、写订单……
deductStock()
createOrder()
ctx.WriteString("done") // ❌ 错！ctx 已随请求结束被回收
}()
})
这会导致 panic 或空响应，因为 ctx 生命周期只到 handler 函数返回。goroutine 里访问 ctx 是竞态行为。
- 真正该异步的，是「通知下游」或「记录日志」这类非关键路径
- 库存校验、扣减、订单落库必须在 handler 内同步完成，且需加锁或原子操作
- 如果你把耗时操作扔进 goroutine 却不等结果就返回，用户根本不知道抢没抢到
sync/atomic 和 redis.Incr 哪个更适合库存扣减？
单机部署且 QPS sync/atomic.Int64 最快；但秒杀本质是分布式场景，必须跨实例协调。此时 redis.Incr 不够用——它只能加，不能「先查再减」且保证原子性。
- 正确做法是用 Redis Lua 脚本做原子扣减：
EVAL "if redis.call('get', KEYS[1]) >= ARGV[1] then redis.call('decrby', KEYS[1], ARGV[1]) return 1 else return 0 end" 1 stock_key 1 - 不要用
GET + DECR两步，网络延迟会导致超卖 - Iris 中调用时，确保 Redis client 是连接池复用的（如
github.com/go-redis/redis/v9），避免每请求新建连接
怎么防止恶意刷接口压垮 Iris？
Iris 的 iris.LimitRequestBody 和 iris.LimitMaxRequests 只能防基础洪水，对真实秒杀无效——攻击者会分散 IP、用真实 UA、甚至走正常用户流量混入。
- 前置加一层
redis.SetNX做用户级令牌桶（key ="user_seckill_token:" + userID），过期时间设为秒级，每次请求先取 token 再放行 - 用
iris.WrapRouter在路由匹配前拦截，避免解析 URL 和参数的开销 - 静态资源（JS/CSS/图片）务必剥离到 CDN，别让 Iris 处理；/seckill 接口路径建议带随机前缀（如
/x7a/seckill），降低被脚本批量探测概率
最易被忽略的一点：秒杀成功后返回的订单号，不能直接暴露数据库自增 ID——它会泄露当前销量和系统负载。应该用雪花算法或 Redis INCR 生成业务 ID，且返回前做一次 redis.Exists 校验，确认订单确实已落库，再发响应。
