Gin on JasperSao的博客

Go 项目反推：Feed 流系统实战——认证体系

Sat, 25 Jul 2026 00:00:00 +0800

承接 Go 项目反推：Feed 流系统实战——请求生命周期，这一篇继续反推 feedsystem_video_go 的认证代码，梳理 JWT、Refresh Token、Token 撤销，以及软硬鉴权中间件之间的关系。

一、jwt.go 文件结构

文件位置：internal/auth/jwt.go

jwtSecret() → 获取密钥
Claims → Token 里存什么
GenerateToken() → 生成 accessToken（JWT 格式，15 分钟）
GenerateRefreshToken() → 生成 refreshToken（随机字符串）
ParseToken() → 验证 Token（签名 + 过期）

二、密钥与 Claims

jwtSecret()：获取密钥

优先使用环境变量 JWT_SECRET，没有就随机生成：

JWT_SECRET=*** go run ./cmd

如果没有设置环境变量，每次服务器启动时密钥都会改变，之前签发的 Token 将全部失效，所有用户都要重新登录。因此正式环境必须设置稳定且足够随机的 JWT_SECRET。

Claims：Token 里存什么

type Claims struct {
 AccountID uint // 用户 ID
 Username string // 用户名
 jwt.RegisteredClaims // 标准字段（过期时间、签发时间等）
}

可以把 Claims 类比为一张有有效期的身份证，上面记录用户名、用户 ID、签发时间和过期时间。

需要注意：JWT Payload 只是经过 Base64URL 编码，并不是加密，客户端也能读取其中的内容。因此 Claims 里不能放密码、密钥等敏感数据。

三、生成 Token

GenerateToken()：生成 accessToken

1. 创建 Claims，写入用户 ID、用户名和 15 分钟后的过期时间
2. 使用 HS256 算法创建 Token 对象
3. 使用 JWT Secret 签名，生成 Token 字符串

结果是一串类似 eyJhbG...xxxx 的 JWT。它内部包含经过编码的 Header 和 Payload，以及用于防止内容被篡改的签名。

HS256 只负责签名和验签，不负责加密。其他人虽然可以读取 Payload，但没有 JWT_SECRET 就无法生成有效签名。

GenerateRefreshToken()：生成 refreshToken

Refresh Token 和 Access Token 完全不同：

accessToken → JWT 格式，携带 Claims，并使用密钥签名
refreshToken → 随机字符串，本身不携带用户信息

项目使用 32 个随机字节，再转换为 64 位十六进制字符串。Refresh Token 不需要携带 Claims，它只需要成为一个难以猜中的长期凭证。

双 Token 时间设定

accessToken 15 分钟：泄露后的可利用时间较短
refreshToken 7 天： 用于换取新的 Access Token，减少重复登录

Access Token 有效期短，降低泄露风险；Refresh Token 有效期长，保证使用体验。二者配合，在安全性和便利性之间取得平衡。

四、验证 Token

ParseToken()：验证 Token

输入：客户端发送的 Token 字符串
输出：Claims（用户 ID、用户名）或错误

流程：

1. 解析 Token
2. 确认签名算法是 HS256
3. 使用 JWT Secret 验证签名
4. 检查 Token 是否过期
5. 全部通过 → 返回 Claims
6. 任一失败 → 返回错误

这里不是“解密 Token”，因为 JWT Payload 没有被加密。服务器做的是解析内容并验证签名。

还需要注意：ParseToken() 只检查格式、签名和过期时间，不检查 Token 是否已被撤销。

五、Refresh 流程

Access Token 过期后，可以使用 Refresh Token 换取新的 Access Token：

客户端：Access Token 过期，这是 Refresh Token，请签发新的 Access Token

服务器：
 1. 使用 Refresh Token 查询 Redis 中的 refresh:<token>
 2. 查询成功后得到 accountID
 3. 查询数据库，确认 Refresh Token 与账户记录匹配
 4. 生成新的 Access Token
 5. 将新 Token 写入数据库和 Redis
 6. 返回给客户端

可以类比为：短期门禁卡过期后，使用长期凭证到前台换一张新卡。

关键点是：使用 Refresh Token 换取 Access Token，而不是反过来。

六、Token 撤销

JWT 的签名和过期时间一旦确定，单靠 ParseToken() 无法让一个尚未过期的 Token 提前失效。因此项目额外在 Redis 和 MySQL 中保存当前有效 Token。

登出时删除旧 Token：

删除 Redis 中的三个 Key：
 account:<id> → accessToken
 account:<id>:refresh → refreshToken
 refresh:<token> → accountID

清空 MySQL 中的字段：
 token
 refresh_token

删除后，即使旧 JWT 的签名正确且尚未过期，中间件也无法在 Redis 或 MySQL 中匹配到它，因此会拒绝请求。

修改密码时也可以使用相同思路：

清空旧 Token
→ 签发新 Token
→ 让其他设备上的旧登录状态立即失效

七、JWTAuth 中间件

文件位置：internal/middleware/jwt/jwt.go

处理流程：

1. 从请求头读取 Authorization
2. 检查格式是否为 Bearer <token>
3. 调用 auth.ParseToken() 验证格式、签名和过期时间
4. 调用 check() 检查 Token 是否仍是当前有效 Token
5. 验证通过后将用户信息写入 Gin Context

客户端发送：

Authorization: Bearer ***

check()：为什么同时查询 Redis 和 MySQL

第一步：查询 Redis
 查到 → 对比请求 Token 是否为当前有效 Token
 相同 → 放行
 不同 → 拒绝，Token 已被替换或撤销

 Redis 未命中或不可用 → 查询 MySQL

第二步：查询 MySQL
 查到账户 → 对比数据库保存的 Token
 相同 → 放行，并回填 Redis
 不同 → 拒绝

Redis 是缓存，速度快但可能未命中或不可用；MySQL 是持久化的数据来源，可以作为兜底。MySQL 本身也可能发生故障，因此更准确的说法是“Redis 失败时降级查询 MySQL”，而不是“MySQL 永远可用”。

check() 主要完成两件事：

将请求中的 Token 与服务器保存的当前 Token 对比，判断是否已被撤销
将用户信息写入 gin.Context，方便后续 Handler 使用

八、两种鉴权

JWTAuth（硬鉴权）：
 没有 Token 或 Token 无效 → 拒绝请求

SoftJWTAuth（软鉴权）：
 没有 Token → 继续放行
 有 Token且有效 → 识别用户身份后放行

项目中的使用示例：

JWTAuth（必须登录）：
 /logout
 /rename
 /uploadAvatar

SoftJWTAuth（不强制登录）：
 /feed/listLatest
 /feed/listByPopularity

用户没有 Token 也能浏览 Feed；携带有效 Token 时，系统可以识别用户并提供个性化结果。

可以类比为：

JWTAuth → 会员俱乐部，没有会员卡不能进入
SoftJWTAuth → 商场，没有会员卡也能进入，有会员卡则能获得个性化服务

九、面试要点

JWT 如何生成：Claims + HS256 + JWT Secret 签名
JWT 不等于加密：Payload 可以读取，签名用于防篡改
双 Token：短期 Access Token + 长期 Refresh Token
Refresh 流程：使用 Refresh Token 换取新的 Access Token
Token 撤销：清理 Redis 与 MySQL 中保存的 Token，使旧 JWT 立即失效
中间件 check()：优先查询 Redis，未命中或不可用时查询 MySQL
两种鉴权：JWTAuth 强制登录，SoftJWTAuth 允许匿名访问

这一套设计实际上让 JWT 从“完全无状态”变成了“带服务端状态的认证方案”。它牺牲了一部分无状态带来的简单扩展能力，换取了主动登出、修改密码后强制失效和单会话控制等能力。

Go 项目反推：Feed 流系统实战——请求生命周期

Tue, 21 Jul 2026 00:00:00 +0800

承接 Go 项目反推：Feed 流系统实战——从 Docker 到开源贡献，这一篇继续反推 feedsystem_video_go 的后端代码。这次不再从整体架构看项目，而是以 POST /account/login 为例，追踪一个请求从进来到返回的完整路径。

路由基础

router.go 是什么

router.go = 路由表 = “地址簿”。它告诉服务器：什么方式 + 访问哪个路径 → 转发到哪个函数。

POST /account/login → accountHandler.Login
POST /account/register → accountHandler.CreateAccount
GET /healthz → 返回 {"status":"ok"}

类比：router.go 是前台接待（“办 login 业务找张三”），handler.go 是张三的工位（“我来处理”）。

路由组

accountGroup := r.Group("/account")

创建一个路由组，前缀是 /account。组里的所有路由，路径前面自动加上前缀：

accountGroup.POST("/login", ...) → 实际路径 POST /account/login
accountGroup.POST("/register", ...) → 实际路径 POST /account/register

类比：把用户相关接口都放在 /account 这个“文件夹”下。

路由注册

accountGroup.POST("/login", loginLimiter, accountHandler.Login)

三个参数：

"/login" → 路径（拼上 /account，变成 /account/login）
loginLimiter → 限流中间件（先过这一关）
accountHandler.Login → 最终处理请求的函数（过了限流才到这里）

请求流程：

POST /account/login 进来
 ↓
loginLimiter（限流中间件）
 ↓
accountHandler.Login（handler 处理）

函数引用 vs 函数调用

accountGroup.POST("/login", loginLimiter, accountHandler.Login)

accountHandler.Login 是函数本身，不是调用。Go 里函数可以当变量传来传去，和 CS61A 的高阶函数一个意思：

accountHandler.Login → 函数本身（把函数“交给”路由器，等有人请求时再调用）
accountHandler.Login(c) → 调用函数（立刻执行）

类比：给你一张纸条写上张三的电话号码（函数引用） vs 现在立刻拨打电话（函数调用）。

现在不执行，等有人发 POST /account/login 时，路由器才会调用 Login(c) 并传入请求信息。

三层架构

结构创建

router.go 第 40-42 行：

accountRepository := account.NewAccountRepository(db)
accountService := account.NewAccountService(accountRepository, cache)
accountHandler := account.NewAccountHandler(accountService)

创建三个“工人”：

Repository → 操作数据库的人（查表、写表）
Service → 处理业务逻辑的人（校验密码、生成 Token）
Handler → 接收请求的人（解析参数、返回结果）

依赖关系：db → Repository → Service → Handler → 路由

类比：先招档案员（Repository）给数据库钥匙，再招业务员（Service）管档案员，再招前台（Handler）对接业务员，最后门口挂牌子（路由）：“办 login 业务找前台”。

Handler 结构体

type AccountHandler struct {
 accountService *AccountService
}

func NewAccountHandler(accountService *AccountService) *AccountHandler {
 return &AccountHandler{accountService: accountService}
}

AccountHandler 是一个结构体，里面有一个字段 accountService。NewAccountHandler 创建这个结构体并把 Service 存进去。

分层的意义

handler 只管：解析请求 → 调用 service → 返回结果
service 处理：校验密码 → 生成 Token → 写数据库
repo 处理： 操作数据库

handler 不关心密码怎么校验、Token 怎么生成，它只管“调用 service”。

文件目录结构

internal/http/router.go → 路由目录，负责“找谁”
internal/account/handler.go → 用户模块，负责“怎么干”
internal/account/service.go → 用户模块，负责“核心逻辑”
internal/account/repo.go → 用户模块，负责“操作数据库”

按模块分目录：account 目录下放所有跟用户相关的代码，video 目录下放所有跟视频相关的代码。

Handler 层：Login 函数

handler.go 第 116-133 行：

func (h *AccountHandler) Login(c *gin.Context) {
 var req LoginRequest // 声明容器
 if err := c.ShouldBindJSON(&req); err != nil { ... } // 解析 JSON
 account, err := h.accountService.FindByUsername(...) // 查数据库存不存在
 accessToken, refreshToken, err := h.accountService.Login(...) // 校验密码+生成Token
 c.JSON(200, LoginResponse{Token, RefreshToken, ...}) // 返回给客户端
}

完整流程：

1. 解析客户端发的 JSON（用户名、密码）
2. 去数据库查这个用户存不存在
3. 存在的话，让 service 校验密码、生成 Token
4. 把 Token 返回给客户端

ShouldBindJSON

c.ShouldBindJSON(&req)

把客户端发的 JSON 解析到 req 变量里。客户端发 {"username": "zhangsan", "password": "***"}，解析后 req.Username = "zhangsan"，req.Password = "123456"。

ShouldBindJSON vs json.NewDecoder：两个干的事一样，都是把 JSON 解析到变量里。c.ShouldBindJSON(&req) 是 Gin 封装的一行搞定；json.NewDecoder(r.Body).Decode(&req) 是原生写法，要三行还要检查 err。类比：自动挡 vs 手动挡。

Service 层：Login 函数

handler 调用 service 的 Login：

accessToken, refreshToken, err := h.accountService.Login(c.Request.Context(), req.Username, req.Password)

service.go 的 Login 做了 6 件事：

1. 查数据库拿用户信息（FindByUsername）
2. bcrypt 校验密码
3. 生成 accessToken 和 refreshToken
4. Token 存进 MySQL（调用 repo.Login）
5. Token 存进 Redis（3 个 key）
6. 返回两个 Token

ctx（context）

ctx = 请求的“身份证”，带着两个信息：

超时时间：这个请求最多等多久
取消信号：客户端断开了，别再查了

每一层都要传 ctx，这样整条链路都能感知到“客户端还在不在”。

类比：你去饭店点菜，等了 5 分钟走了。没有 ctx → 厨师还在炒，炒完发现你走了，菜倒掉。有 ctx → 服务员告诉厨师“客人走了”，厨师立刻停手。

bcrypt 校验密码

bcrypt.CompareHashAndPassword([]byte(account.Password), []byte(password))

传入两个参数：数据库里存的加密密码（哈希）和用户这次输入的明文密码。bcrypt 把明文密码加密，和数据库里的对比，一样返回 nil（成功），不一样返回 error（失败）。

为什么不存明文？数据库被黑了，黑客拿到的是加密字符串，反推不出原始密码。

[]byte() = 把字符串转成字节数组，bcrypt 只接收这种格式。

双 Token（JWT）

登录成功返回两个 Token：

accessToken → 短期有效（15分钟），用来证明“我是谁”
refreshToken → 长期有效（7天），用来续期 accessToken

为什么两个？只用一个 token 的问题：设太短 → 用户每 15 分钟重新登录，体验差；设太长 → 被偷了就一直能用，不安全。双 token 解决了这个问题：accessToken 短，被偷了也很快过期；refreshToken 长，用户不用频繁登录；accessToken 过期了，用 refreshToken 换新的。

类比：accessToken = 门禁卡（每天过期，重新刷卡续期），refreshToken = 身份证（长期有效，门禁卡丢了拿身份证补办）。

Token 根据用户信息生成（不是纯随机）：

accessToken → 包含用户ID + 用户名 + 过期时间（15分钟）
refreshToken → 只包含用户ID + 过期时间（7天）
用密钥加密生成一串乱码字符串

为什么有 ID 又有用户名

ID（account.ID） → 数据库主键，不可变，用来精确查找
用户名（username）→ 可以改，用来方便识别

类比：身份证号（ID）不可变，查账户用；姓名（username）可以改，写在凭证上让人看。生成 Token 时两个都存：ID 用来查人，用户名用来识别。

Repo 层：Login 函数

service 调用 repo 把 Token 存进 MySQL：

as.accountRepository.Login(ctx, account.ID, accessToken, refreshToken)

repo.go 里用 GORM 操作数据库：

ar.db.WithContext(ctx).Model(&Account{}).Where("id = ?", id).Updates(
 map[string]interface{}{"token": token, "refresh_token": refreshToken})

翻译：在 account 表里，找到 id 等于 id 的那一行，更新 token 和 refresh_token。

等价 SQL：

UPDATE account SET token = 'xxx', refresh_token = 'yyy' WHERE id = 1;

GORM = 用 Go 代码描述“我要干什么”，GORM 帮你翻译成 SQL。

Redis 缓存

登录成功后，Token 存两份：

MySQL 存一份 → 保险，重启不丢，但慢
Redis 存一份 → 快，验证时直接查这里

Redis 存了 3 个 key：

key: "account:1" → accessToken TTL 24小时
key: "account:1:refresh" → refreshToken TTL 7天
key: "refresh:xxxxx" → accountID TTL 7天

为什么存 3 个？第 1 个验证 Token 时查，第 2 个刷新 Token 时查，第 3 个用 refreshToken 反查用户 ID。

Redis 不可用时降级：跳过缓存，只靠 MySQL，功能不丢，只是慢一点。

中间件

怎么执行的

中间件 = 挡在 handler 前面的一道关卡。两个关键函数：

c.Next() → 放行，让请求继续走到下一个中间件或 handler
c.Abort() → 拦截，不让请求继续走，handler 不会执行

类比：c.Next() = 安检通过，放你进去；c.Abort() = 安检不过，拦住你。

为什么是两层函数

func Limit(cache, name string, ...) gin.HandlerFunc { // 外层：传配置
 return func(c *gin.Context) { // 内层：处理请求
 c.Next()
 }
}

外层传配置，内层处理请求。外层函数执行一次，创建中间件；内层函数每次有人访问都执行一次。

类比：外层 = 装修奶茶店（执行一次，买机器、买原料）；内层 = 每天营业（执行无数次，客人来了做奶茶）。

gin.HandlerFunc = Gin 要求中间件必须是这种格式的函数。

gin.Context 的数据传递

中间件把用户 ID 塞进 c 里：

c.Set("accountID", accountID) // 中间件：往 c 里存

handler 从 c 里取出来：

value, exists := c.Get("accountID") // handler：从 c 里取

c 就是一个“传话筒”，中间件往里塞东西，handler 从里拿东西。c 是临时对象，只活在一次请求里，请求结束就没了，不会存到 Redis。

类比：安检员检查完证件，在你手上盖个章“1号”（中间件 c.Set）；柜员看你手上的章，知道你是“1号”（handler c.Get）。

错误到 HTTP 状态码的映射

ClassifyHTTPStatus 就是一张对照表：

error 类型 → 状态码 → 含义
nil（没错误） → 200 → 成功
ErrUnauthorized（未登录） → 401 → 未授权
ErrValidation（参数错误） → 400 → 请求格式错
gorm.ErrRecordNotFound（查不到）→ 404 → 资源不存在
其他错误 → 500 → 服务器内部错误

handler 里用法：

c.JSON(apierror.ClassifyHTTPStatus(err), gin.H{"error": err.Error()})

翻译：看一眼 error 是什么类型，返回对应的状态码。

1. 用户发 POST /account/login

2. router.go 找到这条路由，先过 loginLimiter（限流中间件）

3. 进入 handler.go 的 Login 函数：
 - 解析 JSON（拿到 username 和 password）
 - 调用 service.FindByUsername（查用户存不存在）
 - 调用 service.Login（校验密码 + 生成 Token）

4. 进入 service.go 的 Login 函数：
 - 再查一次数据库（拿到密码哈希）
 - bcrypt 校验密码
 - 生成 accessToken 和 refreshToken
 - 调用 repo.Login（把 Token 存 MySQL）
 - 把 Token 存进 Redis（3 个 key）

5. 进入 repo.go 的 Login 函数：
 - 用 GORM 把 Token 写进 account 表

6. Token 一层一层返回：repo → service → handler → 客户端

涉及 4 个文件：

router.go → 注册路由，把路径和函数连起来
handler.go → 解析请求，调用 service
service.go → 校验密码，生成 Token，存数据库和缓存
repo.go → 操作 MySQL

涉及 2 个存储：

MySQL → 存用户信息和 Token（持久化，重启不丢）
Redis → 缓存 Token（快，重启会丢）

Go 项目反推：Feed 流系统实战——从 Docker 到开源贡献

Sun, 19 Jul 2026 00:00:00 +0800

承接 Go 语言基础：从变量到指针、Go 语言进阶：方法、接口与错误处理、Go 语言工程化：模块管理与项目结构、Go 语言并发：从 Goroutine 到 Worker Pool 和 Go Web 开发：从 net-http 到 Gin，这一篇跳出语法学习，反推一个真实的开源项目——feedsystem_video_go（279 star，Go + Vue 3 短视频 Feed 流系统），从跑通项目到提交 PR，走一遍完整的工程实战。

项目概览

这个项目是一个短视频 Feed 流系统，技术栈：

后端：Go + Gin + GORM + RabbitMQ + Redis
前端：Vue 3 + TypeScript
基础设施：Docker Compose 编排 MySQL、Redis、RabbitMQ

核心功能包括用户注册登录、视频发布、点赞评论、关注取关、Feed 流推送。架构上采用 API + Worker 的消息队列模式。

Docker Compose：启动基础设施

项目的三个"帮手"——MySQL、Redis、RabbitMQ——通过 Docker Compose 一键启动：

cd ~/dev/projects/feedsystem_video_go
docker compose up -d mysql redis rabbitmq

docker compose up — 根据 docker-compose.yml 启动服务
-d — 后台运行（detach），不占终端窗口
mysql redis rabbitmq — 只启动这三个，不启动 backend/worker/frontend

镜像 vs 容器

Docker 里有两个核心概念：

镜像 = 打包好的集装箱（里面有程序 + 配置），是静态文件
容器 = 集装箱正在运行的实例

类比：.app 文件是镜像，双击打开后正在运行就是容器。

端口映射

MySQL 默认端口 3306，但本机可能已经装了 MySQL 占用了 3306。所以 docker-compose.yml 里写的是：

ports: "3307:3306"

意思是：外部访问 3307 → 转发到容器内部的 3306。就像你家门牌号是 3307，但内部房间编号是 3306。项目配置文件里写的也是 3307，Go 程序连接 MySQL 时用的就是 3307。

通过 docker compose ps 可以查看所有容器的运行状态：

NAME IMAGE STATUS PORTS
feedsystem_video_go-mysql-1 mysql:8.0 Up 5 minutes (healthy) 0.0.0.0:3307->3306/tcp
feedsystem_video_go-redis-1 redis:7-alpine Up 5 minutes (healthy) 0.0.0.0:6379->6379/tcp
feedsystem_video_go-rabbitmq-1 rabbitmq:3 Up 5 minutes (healthy) 0.0.0.0:5672->5672/tcp

0.0.0.0 表示"接受任何来源的连接"，即对外部开放。

启动 Go 后端

基础设施就位后，启动后端：

cd backend
CONFIG_PATH=configs/config.compose-local.yaml go run ./cmd

CONFIG_PATH=... — 告诉程序用哪个配置文件（里面写好了 MySQL 3307、Redis 6379、RabbitMQ 5672 的地址）
go run ./cmd — 编译并运行 cmd/main.go 入口程序

日志解读

启动后会看到几段日志：

第一段：依赖下载

go: downloading github.com/gin-gonic/gin v1.11.0
go: downloading gorm.io/gorm v1.31.1

Go 在下载第三方库，类似 npm install，下载一次以后就不需要了。

第二段：连接建立

Loading config from configs/config.compose-local.yaml
Redis connected (cache enabled)
RabbitMQ connected

注意没有 “MySQL connected”，因为 GORM 连接 MySQL 是在后面 AutoMigrate 时才真正连接。

第三段：Gin 路由注册

[GIN-debug] GET /healthz
[GIN-debug] POST /account/register
[GIN-debug] POST /account/login
[GIN-debug] POST /video/publish
[GIN-debug] POST /like/like
[GIN-debug] POST /feed/listLatest

格式是 HTTP方法路由路径，后面的 (4 handlers) 表示这条路由经过几个中间件（如限流 + JWT 鉴权 + 业务处理）。

第四段：消息队列

DLX ready: exchange=dlx.events queue=like.events.dlx
Timeline consumer 已启动, queue=video.timeline.update.queue

DLX = Dead Letter Exchange（死信队列），专门处理失败的消息。

第五段：启动完成

Server is running on port 8080

为什么不把 Go 也放进 Docker？

Docker 适合最终部署，不适合日常开发调试。本地直接 go run 的好处：

日志直接打印在终端，实时可见
改了代码立刻能跑，不用重新打包镜像
出错了能直接看到报错信息

日志不是中间件

日志是 Go 标准库 log 包写出来的，是程序员手动写的"程序进行到哪一步了"的提示。中间件是处理请求的"关卡"，两者没有关系。

核心概念：缓存与消息队列

Redis 缓存

缓存 = 把经常用的数据放在"取用更快的地方"。

类比：冰箱里有水（MySQL，容量大但取用慢），你拿了一瓶放在桌上（Redis 缓存，取用极快），下次喝水直接从桌上拿，不用再去冰箱。

代码里 cache enabled 表示数据会先从 Redis 取，取不到再去 MySQL。

RabbitMQ 消息队列

消息队列是 API 和 Worker 之间的"传话筒"。API 处理完核心逻辑后，把"后续要做的事"发到队列，Worker 从队列里取任务执行。

前后端分离架构

后端和前端是两个完全不同的程序：

后端：Go 写的，负责业务逻辑、读写数据库，监听 8080 端口
前端：Vue 写的，负责页面展示、用户交互，监听 5173 端口

它们通过 HTTP 请求通信：用户在浏览器点"登录" → 前端发请求到 localhost:8080/account/login → 后端处理 → 返回结果 → 前端展示。

就像餐厅里厨房（后端）和前厅（前端）是两个地方，前厅接到顾客点单传给厨房，厨房做完菜传给前厅。

前端用 npm（Node Package Manager）管理依赖，跟 Go 的 go get、Python 的 pip install 是同一个道理：

cd frontend
npm install # 下载依赖
npm run dev # 启动开发服务器

Worker 进程模式

这是整个项目最核心的架构设计。Worker 是一个独立进程，和 API 分开启动：

cd backend
CONFIG_PATH=configs/config.compose-local.yaml go run ./cmd/worker

为什么要分开？

想象一个外卖平台：

方案 A：一个人又要接单又要送餐 — 接单时有新订单没人接，送餐时又有新订单没人接，效率低。

方案 B：两个人分工 — 前台专门接单（API），骑手专门送餐（Worker），前台接完单把订单放进"待送餐队列"（RabbitMQ），骑手从队列里取订单去送。

对应到项目：

角色	职责
API 进程	接收用户请求（点赞、评论、发布视频），处理核心业务逻辑，把"后续要做的事"发到消息队列
Worker 进程	监听消息队列，处理异步任务：更新点赞数、计算热度、推送通知

这个项目有四个 Worker：

LikeWorker — 处理点赞/取消点赞事件
PopularityWorker — 更新视频热度
SocialWorker — 处理关注/取关事件
CommentWorker — 处理评论事件

分开的好处

性能：用户点赞时，API 只需要返回"点赞成功"，不需要等热度计算完成
独立伸缩：请求量大时启动多个 API 进程，任务多时启动多个 Worker 进程
故障隔离：Worker 挂了 API 还能正常接收请求，API 挂了 Worker 还能把队列里的任务处理完

一句话总结：API 是"接单的"，Worker 是"干活的"，通过消息队列解耦。

开源贡献实战：修复 JWT 密钥缓存 Bug

跑通项目后，在实际使用中发现了一个真实 Bug。

问题复现

不设置 JWT_SECRET 环境变量，启动后端
注册一个账号
登录成功（页面提示"登录成功"）
但左侧栏仍然显示"未登录"
浏览器控制台报错：invalid or expired token (401)

登录本身成功，但所有需要鉴权的接口全部返回 401。

根因定位

文件：backend/internal/auth/jwt.go

func jwtSecret() []byte {
 secret := os.Getenv("JWT_SECRET")
 if secret == "" {
 b := make([]byte, 32)
 rand.Read(b)
 secret = hex.EncodeToString(b)
 }
 return []byte(secret)
}

问题出在这个函数每次调用都生成一个新的随机密钥：

登录时：GenerateToken() 调用 jwtSecret() → 拿到密钥 A → 用 A 签名 token
验证时：ParseToken() 调用 jwtSecret() → 拿到密钥 B → 用 B 验证
A ≠ B → 签名不匹配 → 返回 401

修复方案

用包级别的变量缓存密钥，保证每个进程只生成一次：

var cachedSecret []byte

func jwtSecret() []byte {
 if cachedSecret != nil {
 return cachedSecret
 }
 secret := os.Getenv("JWT_SECRET")
 if secret == "" {
 b := make([]byte, 32)
 if _, err := rand.Read(b); err != nil {
 log.Printf("FATAL: cannot generate JWT secret: %v", err)
 cachedSecret = []byte("fallback-unsafe-key-change-me")
 return cachedSecret
 }
 secret = hex.EncodeToString(b)
 log.Printf("WARNING: JWT_SECRET not set, generated random key.")
 }
 cachedSecret = []byte(secret)
 return cachedSecret
}

修复方案兼顾安全性（缓存保证签名一致）和灵活性（仍然允许随机密钥兜底）。

走通开源贡献流程

步骤	内容
1. 本地复现	按步骤触发 Bug
2. 阅读源码	从前端 → API → JWT 中间件，定位根因
3. 提 Issue	描述问题，附带复现步骤 → #15
4. Fork + 修复分支	`fix/jwt-secret-caching`
5. 提 PR	关联 Issue → #16

面试话术

在一个 279 star 的开源项目中发现了真实 bug
从前端（Vue/TypeScript）追踪到 API（Gin/Go）再到 JWT 鉴权中间件，定位了根因
提出的修复方案兼顾安全性和灵活性
走通了完整的开源贡献流程

这一篇从"跑通项目"出发，反推了 Docker Compose 编排、Gin 路由注册、Redis 缓存、RabbitMQ 消息队列、Worker 进程模式等工程概念，最后通过一次真实的开源贡献把整条链路串了起来。相比纯语法学习，反推真实项目能更快建立工程直觉。

Go Web 开发：从 net-http 到 Gin

Sat, 18 Jul 2026 00:00:00 +0800

承接 Go 语言基础：从变量到指针、Go 语言进阶：方法、接口与错误处理、Go 语言工程化：模块管理与项目结构和 Go 语言并发：从 Goroutine 到 Worker Pool，这一篇进入 Web 开发实战：用 Go 写 HTTP 服务器。

Handler：处理请求的函数

Go 的 HTTP 服务器一切从 Handler 开始。Handler 就是一个处理请求的函数，签名是固定的：

func handler(w http.ResponseWriter, r *http.Request)

w = 响应写入器（往里面写什么，客户端就收到什么）
r = 请求信息（客户端发来的 URL、方法、头部等）

把 w 想象成"回复窗口"，r 想象成"来信内容"。

package main

import (
 "fmt"
 "net/http"
)

func homeHandler(w http.ResponseWriter, r *http.Request) {
 fmt.Fprintf(w, "Hello, Go Web!\n")
}

func aboutHandler(w http.ResponseWriter, r *http.Request) {
 fmt.Fprintf(w, "About Page\n")
}

路由注册与启动服务器

告诉 Go：访问 / 调用 homeHandler，访问 /about 调用 aboutHandler。

func main() {
 // 注册路由
 http.HandleFunc("/", homeHandler)
 http.HandleFunc("/about", aboutHandler)

 // 启动服务器，监听 8080 端口
 fmt.Println("Server starting on http://localhost:8080 ...")
 err := http.ListenAndServe(":8080", nil)
 if err != nil {
 fmt.Println("Server error:", err)
 }
}

`ListenAndServe` 的含义

Listen = 监听（竖起耳朵听有没有人敲门）
And = 并且
Serve = 提供服务（有人来了就接待）

这行代码一旦执行，程序就卡在这不走了，一直等着。下面的 if err 只有服务器出错才会执行。

端口被占了怎么杀：lsof -ti:8080 | xargs kill -9

HTTP 方法与 curl

r.Method → 请求方法，r.URL.Path → 请求路径。

curl 是在终端发 HTTP 请求的工具，相当于用命令代替浏览器：

curl http://localhost:8080/ # GET
curl -X POST http://localhost:8080/ # POST
curl -X PUT http://localhost:8080/ # PUT
curl -X DELETE http://localhost:8080/ # DELETE

HTTP 方法表示"我想干什么"：

方法	含义	类比（快递柜）
GET	获取数据	查看 123 号格子
POST	提交数据	往里放新包裹
PUT	更新数据	换掉 123 号格子的东西
DELETE	删除数据	拿走 123 号格子的东西

返回 JSON 响应

JSON 是程序之间传递数据的标准格式。核心三步：

import "encoding/json"

type User struct {
 Name string `json:"name"`
 Age int `json:"age"`
}

func userHandler(w http.ResponseWriter, r *http.Request) {
 user := User{Name: "Tom", Age: 20}

 // 第1步：把数据变成 JSON
 jsonBytes, err := json.Marshal(user)
 if err != nil {
 http.Error(w, "序列化失败", 500)
 return
 }

 // 第2步：告诉客户端"我返回的是 JSON"
 w.Header().Set("Content-Type", "application/json")

 // 第3步：把 JSON 写出去
 w.Write(jsonBytes)
}

struct 的 json tag

type User struct {
 Name string `json:"name"` // JSON 里字段叫 name（小写）
 Age int `json:"age"`
}

不写 tag 的话字段名就是 Go 里的大写 Name、Age。反引号里整个 json:"xxx" 是一个整体，冒号后面不能有空格。

响应头是什么

HTTP 响应 = 响应头（信封）+ 响应体（信的内容）：

w.Header() = 拿信封
w.Header().Set("Content-Type", "application/json") = 在信封上写"里面是 JSON"
w.Write() = 往信里写内容

读取客户端 JSON

客户端 POST 发来 JSON，服务器解析到结构体：

func createUserHandler(w http.ResponseWriter, r *http.Request) {
 // 检查方法
 if r.Method != "POST" {
 http.Error(w, "只支持 POST 方法", http.StatusMethodNotAllowed)
 return
 }

 // 从请求体解析 JSON 到 user
 var user User
 err := json.NewDecoder(r.Body).Decode(&user)
 if err != nil {
 http.Error(w, "JSON 解析失败", 400)
 return
 }

 // 返回给客户端
 jsonData, _ := json.Marshal(user)
 w.Header().Set("Content-Type", "application/json")
 w.Write(jsonData)
}

测试：

curl -X POST http://localhost:8080/user -d '{"name":"Jerry","age":25}'

序列化 vs 反序列化

操作	函数	用途
结构体 → JSON	`json.Marshal(data)`	返回给客户端
JSON → 结构体	`json.NewDecoder(r.Body).Decode(&data)`	读取客户端数据

关键点：

Decode 的参数必须是 &user（指针），不是 user
Marshal 和 Decode 都返回 err，必须检查
出错要 http.Error + return，不能光打印

REST API 设计风格

REST 的核心思想：用 HTTP 方法 + 路径，表达"对资源做什么操作"。路径放名词（资源），HTTP 方法放动词（操作）。

本质就是 CRUD：

操作	HTTP 方法	路径	含义
Create	POST	`/user`	新建
Read	GET	`/user` 或 `/user/0`	查列表 / 查单个
Update	PUT	`/user/0`	改单个
Delete	DELETE	`/user/0`	删单个

记忆：GET=看，POST=增，PUT=改，DELETE=删

设计规则：

URL 用名词（/user），不用动词（/getUser）
用 HTTP 方法区分操作，而不是路径里写动词
同一个 URL，不同方法 = 不同操作

完整 CRUD 实战

四个 Handler 的套路

不管你写哪个 handler，步骤都是：

检查 HTTP 方法对不对
从 URL 拿 id（列表操作跳过）
检查越界（同上）
业务逻辑（创建/返回/替换/删除）
序列化返回（JSON → 设 Header → 写响应）

区别只在第 4 步：

Create：从请求体解析 → append 到 users
Read：从 users 里取 → 序列化返回
Update：从请求体解析 → 替换 users[id]
Delete：从 users 删掉 → 返回文字消息

结构体与全局变量

type User struct {
 Name string `json:"name"`
 Age int `json:"age"`
}

// 模拟数据库，服务器重启就清空
var users = []User{}

从 URL 提取 id

客户端访问 GET /user/0，服务器用 TrimPrefix 切掉前缀，再转数字：

func getUserHandler(w http.ResponseWriter, r *http.Request) {
 if r.Method != "GET" {
 http.Error(w, "只支持 GET 方法", 405)
 return
 }

 // /user/0 → "0"
 idStr := strings.TrimPrefix(r.URL.Path, "/user/")

 // "0" → 0
 id, err := strconv.Atoi(idStr)
 if err != nil {
 http.Error(w, "无效的 id", 400)
 return
 }

 // 越界检查
 if id < 0 || id >= len(users) {
 http.Error(w, "越界", 404)
 return
 }

 user := users[id]
 jsonData, _ := json.Marshal(user)
 w.Header().Set("Content-Type", "application/json")
 w.Write(jsonData)
}

越界用 >= 不是 >：长度 2 的列表，有效下标是 0、1，id=2 要拦截。

Update Handler（PUT）

套路：检查方法 → 拿 id → 越界检查 → 解析请求体新数据 → 替换 users[id] → 序列化返回。

func updateUserHandler(w http.ResponseWriter, r *http.Request) {
 if r.Method != "PUT" {
 http.Error(w, "只支持 PUT 方法", 405)
 return
 }

 idStr := strings.TrimPrefix(r.URL.Path, "/user/")
 id, err := strconv.Atoi(idStr)
 if err != nil {
 http.Error(w, "无效的 id", 400)
 return
 }
 if id < 0 || id >= len(users) {
 http.Error(w, "越界", 404)
 return
 }

 var user User
 err = json.NewDecoder(r.Body).Decode(&user)
 if err != nil {
 http.Error(w, "解析失败", 400)
 return
 }

 users[id] = user

 jsonData, _ := json.Marshal(user)
 w.Header().Set("Content-Type", "application/json")
 w.Write(jsonData)
}

Delete Handler（DELETE）

套路：检查方法 → 拿 id → 越界检查 → 从 slice 删元素 → 返回消息。

func deleteUserHandler(w http.ResponseWriter, r *http.Request) {
 if r.Method != "DELETE" {
 http.Error(w, "方法错误", 405)
 return
 }

 idStr := strings.TrimPrefix(r.URL.Path, "/user/")
 id, err := strconv.Atoi(idStr)
 if err != nil {
 http.Error(w, "无效的 id", 400)
 return
 }
 if id < 0 || id >= len(users) {
 http.Error(w, "越界", 404)
 return
 }

 // 删 slice 元素
 users = append(users[:id], users[id+1:]...)
 fmt.Fprintf(w, "用户 %d 已删除\n", id)
}

Slice 删除元素的原理

users = append(users[:id], users[id+1:]...)

把 id 前面的人和 id 后面的人拼到一起，跳过 id 本身。假设 users = [张三, 李四, 王五]，删 id=1（李四）：

users[:1] → [张三]
users[2:] → [王五]
append 拼起来 → [张三, 王五]

注意：删除后 users 长度变了，后面的 id 会前移。

路由分发（switch 重构）

当一个 URL 要根据 HTTP 方法分发到不同 handler 时：

func main() {
 http.HandleFunc("/user/", func(w http.ResponseWriter, r *http.Request) {
 path := r.URL.Path

 if path == "/user" || path == "/user/" {
 // 列表和创建
 switch r.Method {
 case "GET":
 listUsersHandler(w, r)
 case "POST":
 createUserHandler(w, r)
 default:
 http.Error(w, "方法不支持", 405)
 }
 } else if strings.HasPrefix(path, "/user/") {
 // 单个用户操作
 switch r.Method {
 case "GET":
 getUserHandler(w, r)
 case "PUT":
 updateUserHandler(w, r)
 case "DELETE":
 deleteUserHandler(w, r)
 default:
 http.Error(w, "方法不支持", 405)
 }
 }
 })

 fmt.Println("Server starting on http://localhost:8080 ...")
 err := http.ListenAndServe(":8080", nil)
 if err != nil {
 fmt.Println("Server error:", err)
 }
}

测试

# 查列表（空的）
$ curl http://localhost:8080/user/
[]

# 创建两个用户
$ curl -X POST http://localhost:8080/user/ -d '{"name":"Jerry","age":25}'
{"name":"Jerry","age":25}

$ curl -X POST http://localhost:8080/user/ -d '{"name":"Tom","age":30}'
{"name":"Tom","age":30}

# 再查列表
$ curl http://localhost:8080/user/
[{"name":"Jerry","age":25},{"name":"Tom","age":30}]

# 查单个
$ curl http://localhost:8080/user/0
{"name":"Jerry","age":25}

ServeMux 的斜杠重定向坑

注册 /user/ 这种子树路由后，Go 默认路由器会把 /user 自动重定向到 /user/（301 Moved Permanently）。一些客户端跟随 301 重定向时会把 POST 改成 GET，导致请求体丢失；另一些客户端不会自动跟随重定向。

解决：访问列表/创建接口时直接使用带斜杠的 /user/，或者同时显式注册 /user 与 /user/ 并自行处理。

Middleware 中间件

一句话理解

在请求到达 handler 之前（或之后）执行的通用逻辑。

比喻：快递站的安检机——每个包裹都要过一遍，但安检机不是最终处理包裹的地方，安检完再交给真正处理的人。

实际用途：

日志记录：每个请求都打印一下
认证检查：检查有没有登录
请求计时：每个请求花了多少时间

核心代码

func loggingMiddleware(next http.HandlerFunc) http.HandlerFunc {
 return func(w http.ResponseWriter, r *http.Request) {
 // 前置：请求进来时
 log.Println("收到请求:", r.URL.Path)

 // 调用真正的 handler
 next(w, r)

 // 后置：响应返回后
 log.Println("处理完成")
 }
}

使用方式

// 原来
http.HandleFunc("/user", createUserHandler)

// 包一层中间件
http.HandleFunc("/user", loggingMiddleware(createUserHandler))

理解方式：

loggingMiddleware(createUserHandler)
 ↑ ↑
 前台（先接客） 厨师（真正干活）

流程：请求进来 → 前台登记 → 转给厨师 → 做完 → 前台记录

多个中间件叠加

http.HandleFunc("/user", authMiddleware(loggingMiddleware(createUserHandler)))
// 请求进来 → auth → logging → createUserHandler

本质：函数当参数传 + 函数当返回值。不用完全理解原理，记住套路就行，写多了自然就懂。

Gin 框架

Gin 是什么

Go 最流行的 Web 框架，帮你省掉 net/http 的重复代码。

go get github.com/gin-gonic/gin

创建服务器

import "github.com/gin-gonic/gin"

r := gin.Default() // 创建路由器，自带 Logger 中间件
r.Run(":8080") // 启动服务器

Gin vs net/http 对比

net/http	Gin
`w http.ResponseWriter, r *http.Request`	`c *gin.Context`
`if r.Method != "GET" ...`	不用写（`r.GET` 自动限定）
`json.NewDecoder(r.Body).Decode()`	`c.ShouldBindJSON(&user)`
`json.Marshal` + `w.Header` + `w.Write`	`c.JSON(200, data)`
`strings.TrimPrefix` + `Atoi`	`c.Param("id")`
`http.HandleFunc` + if/switch	`r.GET/POST/PUT/DELETE` 分开注册
`http.ListenAndServe(":8080", nil)`	`r.Run(":8080")`

路由注册

r.GET("/user", listUsers) // GET /user → listUsers
r.POST("/user", createUser) // POST /user → createUser
r.GET("/user/:id", getUser) // GET /user/0 → getUser
r.PUT("/user/:id", updateUser) // PUT /user/0 → updateUser
r.DELETE("/user/:id", deleteUser) // DELETE /user/0 → deleteUser

:id 是路由参数，/user/0 里的 0 会被捕获。

Handler 签名

func handler(c *gin.Context) {
 // c 把 w 和 r 合到一起了，用 c 就能完成所有事情
}

获取路由参数与查询参数

// 路由参数
id := c.Param("id") // /user/0 → "0"

// 查询参数
name := c.Query("name") // /user?name=张三 → "张三"
page := c.DefaultQuery("page", "1") // 没传就用默认值 "1"

解析请求体 JSON

var user User
if err := c.ShouldBindJSON(&user); err != nil {
 c.JSON(400, gin.H{"error": err.Error()})
 return
}
// 解析成功，user 里有数据了

ShouldBindJSON 一行代替 net/http 的三行（NewDecoder + Decode + 检查 err）。

返回 JSON 响应

c.JSON(200, user) // 返回单个对象
c.JSON(200, users) // 返回列表
c.JSON(400, gin.H{"error": "解析失败"}) // 返回错误信息

gin.H 是 map[string]interface{} 的简写。c.JSON 自动帮你做：序列化 + 设 Content-Type + 写响应。

参数校验

在 struct tag 里加 binding 规则，Gin 自动校验：

type User struct {
 Name string `json:"name" binding:"required,min=2,max=50"`
 Age int `json:"age" binding:"required,gt=0"`
}

常用规则：

required → 必填
min=N / max=N → 最小/最大长度（字符串）或值（数字）
gt=N / gte=N → 大于 / 大于等于
email → 必须是邮箱格式

校验在 c.ShouldBindJSON 时自动执行，不需要额外代码。

Gin 中间件

func Logger() gin.HandlerFunc {
 return func(c *gin.Context) {
 start := time.Now()

 log.Printf(">>> %s %s", c.Request.Method, c.Request.URL.Path)
 c.Next() // 放行
 cost := time.Since(start)
 log.Printf("<<< 耗时: %v", cost)
 }
}

核心两个函数：

c.Next() → 放行，让请求继续走到 handler
c.Abort() → 拦截，不让请求继续走

认证中间件

func AuthRequired() gin.HandlerFunc {
 return func(c *gin.Context) {
 token := c.GetHeader("Authorization")
 if token == "" {
 c.JSON(401, gin.H{"error": "未登录"})
 c.Abort() // 拦截
 return
 }
 c.Next() // 放行
 }
}

路由分组

用法1：单个路由加中间件

r.GET("/user", Logger(), listUsers)
r.GET("/user/:id", Logger(), AuthRequired(), getUser)

用法2：路由分组（推荐）

authorized := r.Group("/user", AuthRequired())
{
 authorized.GET("/:id", Logger(), getUser)
 authorized.PUT("/:id", Logger(), updateUser)
 authorized.DELETE("/:id", Logger(), deleteUser)
}

分组的好处：AuthRequired 写一次，这组路由全部生效。

完整示例（带中间件）

func main() {
 r := gin.Default()

 // 不需要登录的接口
 r.GET("/user", listUsers)
 r.POST("/user", createUser)

 // 需要登录的接口
 auth := r.Group("/user", AuthRequired())
 {
 auth.GET("/:id", getUser)
 auth.PUT("/:id", updateUser)
 auth.DELETE("/:id", deleteUser)
 }

 r.Run(":8080")
}

常用函数速查

函数	作用
`gin.Default()`	创建路由器（自带 Logger）
`r.GET/POST/PUT/DELETE(path, fn)`	注册路由
`r.Group(path, middleware...)`	路由分组
`c.Param("id")`	获取路由参数
`c.Query("key")`	获取查询参数
`c.DefaultQuery("key", "default")`	获取查询参数（带默认值）
`c.GetHeader("key")`	获取请求头
`c.ShouldBindJSON(&data)`	解析请求体 JSON（含校验）
`c.JSON(status, data)`	返回 JSON 响应
`c.Next()`	放行
`c.Abort()`	拦截
`gin.H{...}`	`map[string]interface{}` 简写

踩坑汇总

中文输入法逗号："错误"，405 → 要用英文逗号 "错误", 405
:= vs =：全局变量用 = 赋值，用 := 会创建局部变量
fmt.Fprinf → fmt.Fprintf（p 和 r 反了）
json.Decode 拼写：Docode → Decode
application 拼写：spplication → application
c.Abort 漏括号 → c.Abort() 才是调用
Gin 里用 net/http 的写法：json.NewDecoder(r.Body) 是 net/http 的，Gin 里用 c.ShouldBindJSON
net/http 中 POST /user 不带斜杠：注册的是 /user/ 时会被重定向，测试时直接用 /user/

参考源

raw/GoWeb 后端开发.md

Gin on JasperSao的博客

Go 项目反推：Feed 流系统实战——认证体系

一、jwt.go 文件结构

二、密钥与 Claims

jwtSecret()：获取密钥

Claims：Token 里存什么

三、生成 Token

GenerateToken()：生成 accessToken

GenerateRefreshToken()：生成 refreshToken

双 Token 时间设定

四、验证 Token

ParseToken()：验证 Token

五、Refresh 流程

六、Token 撤销

七、JWTAuth 中间件

check()：为什么同时查询 Redis 和 MySQL

八、两种鉴权

九、面试要点

Go 项目反推：Feed 流系统实战——请求生命周期

路由基础

router.go 是什么

路由组

路由注册

函数引用 vs 函数调用

三层架构

结构创建

Handler 结构体

分层的意义

文件目录结构

Handler 层：Login 函数

ShouldBindJSON

Service 层：Login 函数

ctx（context）

bcrypt 校验密码

双 Token（JWT）

为什么有 ID 又有用户名

Repo 层：Login 函数

Redis 缓存

中间件

怎么执行的

为什么是两层函数

gin.Context 的数据传递

错误到 HTTP 状态码的映射

Login 请求完整调用链

Go 项目反推：Feed 流系统实战——从 Docker 到开源贡献

项目概览

Docker Compose：启动基础设施

镜像 vs 容器

端口映射

启动 Go 后端

日志解读

为什么不把 Go 也放进 Docker？

日志不是中间件

核心概念：缓存与消息队列

Redis 缓存

RabbitMQ 消息队列

前后端分离架构

Worker 进程模式

为什么要分开？

分开的好处

开源贡献实战：修复 JWT 密钥缓存 Bug

问题复现

根因定位

修复方案

走通开源贡献流程

面试话术

Go Web 开发：从 net-http 到 Gin

Handler：处理请求的函数

路由注册与启动服务器

ListenAndServe 的含义

HTTP 方法与 curl

返回 JSON 响应

struct 的 json tag

响应头是什么

读取客户端 JSON

序列化 vs 反序列化

REST API 设计风格

完整 CRUD 实战

四个 Handler 的套路

结构体与全局变量

`ListenAndServe` 的含义