推荐用 gin 快速启动电商后端，因其轻量常用、生命周期清晰；需设 releasemode、结构化 handler、统一 json 响应；分页用游标替代 offset；超卖防护需 db 条件更新+应用层锁；jwt 仅存不可逆标识并查缓存鉴权。
用 gin 快速启动电商后端服务
不推荐从零写 http 服务器，gin 是当前 go 生态中最轻量、最常用的 Web 框架，适合快速搭建商品、订单、用户等基础接口。它默认不带 ORM 和中间件自动注册，反而让初学者更清楚请求生命周期。
安装与最小启动：
go mod init shop-api go get -u github.com/gin-gonic/gin关键点：
-
gin.SetMode(gin.ReleaseMode)必须在开发完成前加上，否则日志会暴露路由和参数结构 - 不要直接用
router.POST("/product", handler)处理全部逻辑，先拆出ProductHandler结构体，为后续加校验、日志、事务留扩展位 - 所有 JSON 响应统一用
c.JSON(http.StatusOK, response{Code: 0, Data: ...})格式，避免前端反复适配不同字段名
商品列表分页为什么总漏数据？查 OFFSET 和 LIMIT 的坑
电商首页商品列表看似简单，但用 OFFSET 做分页在高并发写入场景下极易跳过或重复返回记录——因为新商品插入会导致后续页的 OFFSET 偏移错位。
立即学习“go语言免费学习笔记（深入）”；
正确做法是游标分页（cursor-based pagination）：
- 前端传上一页最后一条的
id或created_at，后端查WHERE id > ? ORDER BY id LIMIT 20 - 必须确保排序字段有索引，且不能是可能重复的字段（如
price） - 首次请求无 cursor 时，用
WHERE id > 0而非OFFSET 0，保持逻辑一致
Go 里用 database/sql 查询时，注意 rows.Scan() 必须按 select 字段顺序匹配，少一个字段就会静默失败，建议用结构体指针接收：
type Product struct { ID int64 `db:"id"` Name string `db:"name"` Price int `db:"price"` } var products []Product err := db.Select(&products, "SELECT id,name,price FROM product WHERE id > ? ORDER BY id LIMIT ?", lastID, limit)下单接口如何避免超卖？别只靠 UPDATE ... SET stock = stock - 1
单纯用 SQL 减库存在并发请求下必然超卖，因为 SELECT stock 和 UPDATE 不是一次原子操作。
真正有效的方案是组合使用：
- 数据库层：用
UPDATE product SET stock = stock - 1 WHERE id = ? AND stock >= 1，检查sql.Result.RowsAffected()是否为 1 - 应用层：对单个商品 ID 加读写锁（如
sync.map存正在处理的productID → *sync.RWMutex），防止同一商品瞬间多笔扣减穿透到 DB - 兜底层：异步任务监听订单创建事件，若发现库存为负，触发告警并人工干预，而不是当场回滚事务（事务已提交）
注意：redis 分布式锁（如 SET key value EX 10 NX）在这里作用有限——它只能防住「同时抢同一商品」，但无法替代 DB 层的 WHERE 条件校验。
JWT 用户鉴权后，怎么安全存用户 ID 和权限？
别把 user_id、role 等敏感字段明文塞进 JWT payload，即使加了签名，前端仍可解码看到。更危险的是用 HS256 时密钥泄露等于全站沦陷。
实际做法要分两层：
- 签发时只放不可逆标识：
sub: "u_7f3a"（用哈希或短 ID 替代原始数字 ID），不放 role、phone、email - 每次请求解析 Token 后，立刻查一次缓存（如 Redis）获取完整用户上下文：
GET user:u_7f3a，缓存 TTL 设为 30 分钟，和 token 过期时间错开 - 权限判断逻辑不要写死在中间件，而是在每个 handler 里调用
canAccessOrderAPI(userID, reqPath)，方便后期对接 RBAC 或 ABAC
如果用 github.com/golang-jwt/jwt/v5，记得验证 token.Claims.(jwt.MapClaims)["exp"] 是否过期，且必须校验 token.Valid，否则伪造的空 token 也能通过解析。
电商后端真正的复杂度不在语法或框架，而在状态一致性——库存、订单、支付三者任何一环延迟或失败，都会导致资金和数据错乱。动手前先画清楚各接口的幂等性设计和补偿路径，比急着写 CRUD 重要得多。