推荐用 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 字段顺序匹配，少一个字段就会静默失败，建议用结构体指针接收：
ERMEB云盘发卡系统官方正版系统，发卡系统操作简单、方便、易懂。 系统微信小程序前端采用nuiapp后端采用think PHP6PC前端采用vue开发 使用场景：文件上传储存，适合个人/个体/中小企业使用。本系统配合微信小程序端进行使用，文件下载以及发卡商品卡密领取都需要进入小程序内获取下载码以及卡密领取，小程序内可设置积分充值以及任务获取积分，支持微信激励广告领取文件下载码以及卡密商品，可实现
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 重要得多。
