Golang搭建在线教育平台后端应采用四层结构（handler/service/repository/model），聚焦早期闭环验证，克制选型：用sqlx而非gorm、chi优于Gin、Redis仅用于登录态/计数/在线人数，JWT校验自定义中间件，所有SQL必须带context.WithTimeout。
直接上结论：Golang 搭建在线教育平台后端，不靠堆框架，而靠分层清晰 + 关键组件选型克制 + 早期验证闭环。别一上来就搞微服务或全链路监控，先让 student 能注册、course 能查、progress 能存，三件事跑通再谈扩展。
怎么组织代码结构才不会两个月后自己都看不懂
用四层结构（handler / service / repository / model），不是为了炫技，是为避免改个「课程搜索」逻辑时，不得不翻遍 main.go 和三个中间件文件。
-
model层只放纯结构体，比如Student、Course、Chapter，字段名和数据库列严格对齐，不加方法、不引入第三方包 -
repository层只做“增删改查”，用sqlx或gorm都行，但建议初学用sqlx——报错信息直指 SQL 本身，不绕弯；GetCourseByID这类函数名必须和实际行为一致，不塞业务判断 -
service层处理规则，比如「学生不能重复选同一门课」「删除课程前需清空关联的章节和进度」，这里才该用errors.Is(err, repository.ErrNotFound)做分支 -
handler层只干三件事：解析c.Param("id")或c.ShouldBindJSON、调service、写c.JSON(200, resp)；JWT 校验统一走middleware.JWTAuth()，不散落在每个 handler 里
用 Gin 还是 net/http + chi？别被 benchmark 带偏
Gin 确实快，但它的中间件机制和错误恢复逻辑，在你还没写满 50 个接口时，大概率会掩盖真实 panic（比如在 service 层空指针，Gin 自动 recover 成 500 却不打日志）。而 net/http + chi 更贴近原生，panic 就是 panic，调试路径短。
- 如果你团队有运维习惯看
http.Server.Addr和http.TimeoutHandler，选chi；它路由树结构清晰，chi.URLParam(r, "id")比c.Param("id")更容易 grep 定位 - 如果项目要快速交付 MVP 给非技术方演示，Gin 的
c.ShouldBind和c.BindJSON省掉一堆类型转换胶水代码，可接受 - 无论选哪个，立刻禁用
gin.DefaultWriter，把日志重定向到slog.With("service", "api")，否则上线后连「哪个接口超时」都得靠猜
Redis 放哪儿？别一上来就 cache all the things
Redis 不是银弹，乱用反而拖慢关键路径。教育平台真正需要 Redis 的地方其实很窄：
立即学习“go语言免费学习笔记（深入）”；
- 用户登录态：用
SET session:abc123 {"uid":123,"role":"student"} EX 3600，不用JWT自校验，省去每次解析签名开销；注意 key 必须带前缀，避免和其他服务混用 DB - 课程浏览计数：用
INCR course:456:views，别用 MySQLUPDATE courses SET views = views + 1，高并发下锁表风险大 - 直播课在线人数：用
SETNX user:789:live:20260404:123 true+EXPIRE组合，比轮询数据库高效得多 - 千万别把课程详情、章节列表这种结构化数据全塞 Redis —— 更新时一致性难保，且 Go 解析 JSON 到 struct 比从 Redis 取 string 再
json.Unmarshal慢不了多少，纯增加故障面
为什么 JWT 验证要自己写中间件，而不是用现成库
因为现成库（如 github.com/gofrs/uuid 配套的 JWT 库）默认把 exp 校验、iss 校验、nbf 校验全打开，而教育平台往往需要「允许 token 过期后 5 分钟内仍可提交作业」这类柔性策略——这必须自己控制校验逻辑。
- 中间件里用
jwt.ParseWithClaims(tokenStr, &Claims{}, keyFunc)，keyFunc返回[]byte即可，别碰jwt.Keyfunc那套反射 -
Claims结构体必须显式定义UserID uint、Role string字段，不依赖map[string]interface{}，否则后续 service 层取claims["uid"]时类型断言极易 panic - 校验失败统一返回
c.AbortWithStatusJSON(401, gin.H{"error": "invalid or expired token"})，不抛 error 让上层处理，避免 handler 里漏写if err != nil
最常被跳过的一步：没在 repository 层给每个 SQL 查询加 context.WithTimeout。线上一旦 MySQL 主从延迟或连接池耗尽，整个 API 就卡死在 db.QueryRowContext，超时时间由 HTTP server 控制根本没用——必须在数据访问层就设好底线。
