527 lines
19 KiB
Markdown
527 lines
19 KiB
Markdown
---
|
||
tags: [Go, 后端开发, 武科大, Week03, 错题精讲]
|
||
create time: 2026-05-02 14:30
|
||
---
|
||
|
||
# 金山考试 - 武科大服务端 - 第三次课 · 错题精讲
|
||
|
||
## 概述
|
||
|
||
本次测试涵盖 **HTTP 协议基础、Gin 框架核心机制、CORS 跨域、JWT 认证、Nginx 反向代理** 五大模块，共 30 道单选题。其中 **26 道答对，4 道错题**，集中在 HTTP 基础认知、Gin 中间件执行控制、以及 JWT 解析流程三个知识面上。本笔记逐一拆解错误原因，给出正解辨析和代码验证。
|
||
|
||
> [!tip] 使用建议
|
||
> 先看错题本身的「为什么错 → 为什么对」，再做对照表的自测检查，最后用「高频考点速览」串联记忆薄弱点。
|
||
|
||
---
|
||
|
||
## 一、HTTP 协议基础：GET/POST 与默认端口
|
||
|
||
### 单1：GET 和 POST 的主要区别
|
||
|
||
| 项目 | 内容 |
|
||
|------|------|
|
||
| ❌ 你的答案 | A（GET 请求数据，POST 只提交数据） |
|
||
| ✅ 正确答案 | **B（GET 数据附加在 URL 之后，POST 数据放在请求体内）** |
|
||
|
||
> [!error] 你的误区根源
|
||
> 你选了 **A**，描述的是一个"规范层面"的说法——从 RESTful 最佳实践来说 GET 应该用于获取资源、POST 用于创建资源。但题目问的是**主要区别**，而两者最根本的、决定性的差异在于**数据传输位置**。
|
||
|
||
#### 为什么 B 才是本质区别
|
||
|
||
```go
|
||
// GET — 参数拼在 URL 后面 ?key=value&name=xxx
|
||
GET /api/users?page=1&limit=10 HTTP/1.1
|
||
Host: example.com
|
||
// Body 为空
|
||
|
||
// POST — 参数放在 Body 中
|
||
POST /api/users HTTP/1.1
|
||
Host: example.com
|
||
Content-Type: application/x-www-form-urlencoded
|
||
|
||
page=1&limit=10
|
||
```
|
||
|
||
| 维度 | GET | POST |
|
||
|------|-----|------|
|
||
| 数据位置 | URL 查询字符串（`?key=value`） | 请求体（Body） |
|
||
| 数据长度 | 受 URL 长度限制（通常 ~2KB） | 理论上无限制 |
|
||
| 缓存行为 | 可被浏览器缓存、收藏 | 不被缓存 |
|
||
| 幂等性 | ✅ 幂等（多次请求结果一致） | ❌ 非幂等（可能重复创建资源） |
|
||
|
||
> [!warning] ⭐ A 选项为什么不选
|
||
> "GET 只获取、POST 只提交"是 RESTful **设计规范**，不是 HTTP 协议的硬性约束。实际上你可以 POST 一个纯查询接口，也可以用 GET 传大数据（虽然不规范）。考试中考查的是协议层的事实差异，而非设计哲学。
|
||
|
||
#### 延伸对比
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
subgraph GET["GET 请求结构"]
|
||
G1["Method: GET"] --> G2["URL: /api?q=hello"]
|
||
G2 --> G3["Header: ..."]
|
||
G3 --> G4["Body: (empty)"]
|
||
end
|
||
|
||
subgraph POST["POST 请求结构"]
|
||
P1["Method: POST"] --> P2["URL: /api"]
|
||
P2 --> P3["Header: Content-Type"]
|
||
P3 --> P4["Body: key=value&foo=bar"]
|
||
end
|
||
|
||
style G4 fill:#f99
|
||
style P4 fill:#9f9
|
||
```
|
||
|
||
### 单5：HTTP 默认端口号
|
||
|
||
| 项目 | 内容 |
|
||
|------|------|
|
||
| ❌ 你的答案 | D（8080） |
|
||
| ✅ 正确答案 | **B（80）** |
|
||
|
||
> [!memory] 常用端口速记表
|
||
|
||
| 端口 | 协议 | 说明 |
|
||
|------|------|------|
|
||
| **80** | HTTP | 超文本传输协议标准端口 ✅ |
|
||
| **443** | HTTPS | HTTP over TLS/SSL |
|
||
| **21** | FTP | 文件传输协议 |
|
||
| **22** | SSH | 安全远程登录 |
|
||
| **3306** | MySQL | 数据库 |
|
||
| **5432** | PostgreSQL | 数据库 |
|
||
| **8080** | HTTP(替代) | 开发/代理常用端口，非标准 |
|
||
| **8443** | HTTPS(替代) | HTTPS 的常见替代端口 |
|
||
|
||
> [!question] 💡 思考
|
||
> 如果 Go 程序监听 80 端口报错 `permission denied`，怎么办？
|
||
>
|
||
> Linux/macOS 下 1024 以下的端口需要 root 权限。解决方法：① 用 `sudo` 运行；② 将 Nginx 设为反向代理转发到 8080；③ 使用 `authbind` 或 `setcap` 授予特定端口权限。这也是生产环境推荐 Nginx 前置的原因之一。
|
||
|
||
---
|
||
|
||
## 二、Gin 中间件核心机制
|
||
|
||
### 单13：Gin 中间件中继续执行后续逻辑的方法
|
||
|
||
| 项目 | 内容 |
|
||
|------|------|
|
||
| ❌ 你的答案 | B（`c.Abort()`） |
|
||
| ✅ 正确答案 | **A（`c.Next()`）** |
|
||
|
||
> [!error] 核心混淆点
|
||
> 你把 `c.Next()` 和 `c.Abort()` 的作用搞反了。这是 Gin 中间件最关键的两个方法，作用完全相反：
|
||
|
||
```go
|
||
// ✅ c.Next() — 暂停当前中间件，去执行后续所有中间件 + handler
|
||
// 执行完后回来继续运行 Next() 之后的代码
|
||
func loggingMiddleware(c *gin.Context) {
|
||
start := time.Now() // ① 前置：记录开始时间
|
||
c.Next() // ② 去执行后面的中间件和 handler...
|
||
// ③ 执行完回到这里
|
||
fmt.Println(time.Since(start)) // ④ 后置：输出耗时
|
||
}
|
||
|
||
// ❌ c.Abort() — 立即终止整个中间件链，后续的 middleware + handler 全都不执行
|
||
func authMiddleware(c *gin.Context) {
|
||
token := c.GetHeader("Authorization")
|
||
if token == "" {
|
||
c.Abort() // ← 后面的所有内容都不再执行
|
||
return // ⚠️ Abort() 后建议紧跟 return
|
||
}
|
||
c.Next() // 认证通过，才放行
|
||
}
|
||
```
|
||
|
||
> [!summary] c.Next() vs c.Abort() 对比
|
||
|
||
| 方法 | 行为 | 类比 |
|
||
|------|------|------|
|
||
| `c.Next()` | 把请求交给下一个 handler，执行完回来继续 | **"过安检，过了继续走"** |
|
||
| `c.Abort()` | 直接拦截，不再往下传递 | **"拦下来，不能进"** |
|
||
| `c.AbortWithStatus(401)` | 终止 + 返回指定状态码 | **"不让你进，还给你个理由"** |
|
||
| `c.AbortWithError(500, err)` | 终止 + 返回状态码 + 附带错误信息 | **"不让你进，还告诉你出了什么错"** |
|
||
|
||
> [!abstract] c.Next() 底层实现
|
||
>
|
||
> ```go
|
||
> // gin/context.go 简化版
|
||
> func (c *Context) Next() {
|
||
> c.index++ // 移动到下一个 handler
|
||
> for ; c.index < int8(len(c.handlers)); c.index++ {
|
||
> if c.IsAborted() { // 如果前面有调用 Abort()
|
||
> return // 循环终止
|
||
> }
|
||
> c.handlers[c.index](c) // 执行当前 handler
|
||
> }
|
||
> }
|
||
> ```
|
||
>
|
||
> `c.Abort()` 只是设置了一个内部标志位 `isAborted = true`，当 `Next()` 检测到这个标志就停止遍历。
|
||
|
||
<details>
|
||
<summary>💡 深入理解：中间件的"洋葱模型"</summary>
|
||
|
||
Gin 中间件执行可以用经典的"洋葱模型"来理解：
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
A["M1 前置处理"] --> B["M1.Next()"]
|
||
B --> C["M2 前置处理"]
|
||
C --> D["M2.Next()"]
|
||
D --> E["Handler 执行"]
|
||
E --> F["M2 后置处理"]
|
||
F --> G["M1 后置处理"]
|
||
|
||
style E fill:#FFD700
|
||
style A fill:#90EE90
|
||
style B fill:#90EE90
|
||
style C fill:#90EE90
|
||
style D fill:#90EE90
|
||
style F fill:#FFB6C1
|
||
style G fill:#FFB6C1
|
||
```
|
||
|
||
- **进入时**：M1 → M2 → Handler（按注册顺序）
|
||
- **退出时**：Handler → M2 → M1（按逆序，栈的行为）
|
||
- 这就是为什么日志中间件既能记录请求开始时间，也能记录响应耗时。
|
||
|
||
</details>
|
||
|
||
### 单12 & 单17：Gin 全局中间件注册与上下文共享
|
||
|
||
> [!note] 这两题你答对了 ✅，放在一起巩固：
|
||
|
||
**单12：全局注册中间件**
|
||
- 正确写法：`router.Use(middleware)`
|
||
- Gin 没有 `RegisterMiddleware`、`AttachMiddleware`、`Middleware` 这些方法
|
||
|
||
**单17：中间件之间共享数据**
|
||
- 正确方式：`c.Set(key, val)` / `c.Get(key)` 存入 Context 的 `Keys` map
|
||
- 绝对不要用全局变量！每个请求的 Context 是隔离的
|
||
|
||
```go
|
||
// 中间件1：设置用户信息
|
||
func authMiddleware(c *gin.Context) {
|
||
userID := parseToken(c.GetHeader("Authorization"))
|
||
c.Set("userID", userID) // 存入 Context
|
||
c.Set("role", getRole(userID))
|
||
c.Next()
|
||
}
|
||
|
||
// 中间件2/Handler：读取用户信息
|
||
func listUsers(c *gin.Context) {
|
||
userID := c.GetString("userID") // 安全获取
|
||
role := c.MustGet("role").(string) // 断言获取（确保 key 存在）
|
||
_ = role
|
||
}
|
||
```
|
||
|
||
### 单14 & 单15 & 单27 & 单28：Gin 参数解析与绑定
|
||
|
||
> [!note] 这四题你全部答对了 ✅，汇总关键 API：
|
||
|
||
| 场景 | Gin API | 示例 |
|
||
|------|---------|------|
|
||
| JSON body → Struct | `c.ShouldBindJSON(&obj)` | `POST /api/user` 接收 JSON |
|
||
| 路径参数 `:id` | `c.Param("id")` | `GET /user/:id` → `id="123"` |
|
||
| 查询参数 `?key=` | `c.Query("key")` | `GET /search?q=hello` |
|
||
| Form 表单 | `c.PostForm("field")` | `POST` x-www-form-urlencoded |
|
||
| 动态路由定义 | `router.GET("/user/:id", h)` | Gin 用 `:` 前缀，不是 `{}` |
|
||
| JSON 响应 | `c.JSON(200, gin.H{...})` | 返回标准 JSON |
|
||
| 未认证状态码 | 401 Unauthorized | 400 是请求格式错，401 是未认证 |
|
||
|
||
---
|
||
|
||
## 三、JWT 认证：解析步骤与上下文传递
|
||
|
||
### 单19：Golang 中解析 JWT 的正确步骤
|
||
|
||
| 项目 | 内容 |
|
||
|------|------|
|
||
| ❌ 你的答案 | C |
|
||
| ✅ 正确答案 | **A（解码 → 验证签名 → 检查声明）** |
|
||
|
||
> [!error] 你的误区
|
||
> 你可能凭直觉先"检查声明"（比如看看过期时间），但这样做是有安全隐患的：**在没有验证签名的前提下检查声明，等于信任了可能被篡改的数据。**
|
||
|
||
#### 正确的 JWT 解析三步法
|
||
|
||
```go
|
||
import (
|
||
"github.com/golang-jwt/jwt/v5"
|
||
)
|
||
|
||
func parseJWT(tokenString string) (*jwt.Claims, error) {
|
||
// Step 1: 解码（Decoding）— 把 Base64Url 编码的三个部分拆出来
|
||
// 不验签名，只看格式是否合法
|
||
token, _, err := new(jwt.Parser).ParseUnverified(tokenString, jwt.MapClaims{})
|
||
if err != nil {
|
||
return nil, fmt.Errorf("token format invalid: %w", err)
|
||
}
|
||
|
||
// Step 2: 验证签名（Signature Verification）— 用密钥重新计算 HMAC SHA256
|
||
// 确保 token 没有被第三方篡改
|
||
token, err = jwt.Parse(tokenString, func(token *jwt.Token) (interface{}, error) {
|
||
return []byte("your-secret-key"), nil // 必须用同一个密钥
|
||
})
|
||
if err != nil || !token.Valid {
|
||
return nil, fmt.Errorf("signature invalid: %w", err)
|
||
}
|
||
|
||
// Step 3: 检查声明（Claims Validation）— 此时才能相信数据
|
||
claims, ok := token.Claims.(jwt.MapClaims)
|
||
if !ok {
|
||
return nil, fmt.Errorf("invalid claims type")
|
||
}
|
||
|
||
// 检查过期时间
|
||
if time.Unix(int64(claims["exp"].(float64)), 0).Before(time.Now()) {
|
||
return nil, fmt.Errorf("token expired")
|
||
}
|
||
|
||
return &claims, nil
|
||
}
|
||
```
|
||
|
||
> [!warning] ⭐ 高频考点：为什么顺序不能乱？
|
||
>
|
||
> ```
|
||
> 错误的做法：先读 exp → 发现过期 → 告诉客户端"过期了"
|
||
> ↑ 黑客可以伪造 exp = 未来时间来绕过检查
|
||
>
|
||
> 正确的做法：先验签名 → 确认数据未被篡改 → 再读 exp → 确实是 2024-01-01
|
||
> ```
|
||
>
|
||
> 签名验证是**信任锚**——只有签名正确，里面的所有声明才可信。
|
||
|
||
#### JWT 结构速记
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
A["JWT Token"] --> B["Header<br/>Base64Url(JSON)"]
|
||
A --> C["Payload / Claims<br/>Base64Url(JSON)"]
|
||
A --> D["Signature<br/>HMACSHA256<br/>base64UrlHeader.payload + secret"]
|
||
|
||
B -->|"alg + typ"| C
|
||
C -->|"签名算法对<br/>Header+Payload<br/>加上 Secret"| D
|
||
|
||
style D fill:#9f9
|
||
```
|
||
|
||
三部分用 `.` 连接：`xxxxx.yyyyy.zzzzz`
|
||
|
||
> [!memory] JWT 解析三步口诀
|
||
> **"先拆开看格式 → 再验身保真 → 最后读内容"**
|
||
>
|
||
> 解码 → 验签名 → 查声明
|
||
|
||
### 单10 & 单11：JWT 解决的核心痛点与最佳实践
|
||
|
||
> [!note] 这两题你答对了 ✅，补充完整理解：
|
||
|
||
**单10：JWT 解决的核心痛点**
|
||
- 传统 Session：服务器内存/Redis 存储会话，集群环境下需要同步共享
|
||
- JWT：**无状态**，服务端无需存储会话记录即可验证有效性
|
||
- 注意：JWT 并没有加密用户密码，字符串也比 SessionID **更长**（多了 Header + Payload）
|
||
|
||
**单11：JWT 验证后的最佳实践**
|
||
- 中间件就像"查票员"，查验通过后通过 `c.Set()` 把用户信息存入当前请求的 Context
|
||
- 这样后续 Handler 能安全、隔离地拿到用户信息，不会互相干扰
|
||
|
||
```go
|
||
func JWTAuthMiddleware() gin.HandlerFunc {
|
||
return func(c *gin.Context) {
|
||
tokenString := c.GetHeader("Authorization")
|
||
if tokenString == "" {
|
||
c.AbortWithStatusJSON(401, gin.H{"error": "missing token"})
|
||
return
|
||
}
|
||
|
||
claims, err := parseJWT(tokenString)
|
||
if err != nil {
|
||
c.AbortWithStatusJSON(401, gin.H{"error": "invalid token"})
|
||
return
|
||
}
|
||
|
||
// ✅ 最佳实践：存入 Context，供下游使用
|
||
c.Set("userID", claims.UserID)
|
||
c.Set("username", claims.Username)
|
||
c.Next()
|
||
}
|
||
}
|
||
```
|
||
|
||
---
|
||
|
||
## 四、Cookie 安全与 Session 管理
|
||
|
||
### 单7：防止 XSS 攻击的 Cookie 防护
|
||
|
||
| 项目 | 内容 |
|
||
|------|------|
|
||
| ✅ 正确答案 | **C（httpOnly 设置为 true）** |
|
||
|
||
> [!note] 此题你答对了 ✅，巩固关键知识点：
|
||
|
||
```go
|
||
// Set-Cookie 的关键属性
|
||
http.SetCookie(w, &http.Cookie{
|
||
Name: "session_id",
|
||
Value: sessionValue,
|
||
Path: "/",
|
||
MaxAge: 3600, // 有效期（秒），0 表示浏览器关闭即失效
|
||
HttpOnly: true, // ✅ 防 XSS —— JS 无法 document.cookie 读取
|
||
Secure: true, // ✅ 防窃听 —— 仅 HTTPS 传输
|
||
SameSite: http.SameSiteStrictMode, // ✅ 防 CSRF —— 严格同源策略
|
||
})
|
||
```
|
||
|
||
| 属性 | 作用 | 防御目标 |
|
||
|------|------|---------|
|
||
| `HttpOnly` | 禁止 JavaScript 读取 | XSS 窃取 Cookie |
|
||
| `Secure` | 仅 HTTPS 传输 | 中间人窃听 |
|
||
| `SameSite` | 限制跨站携带 Cookie | CSRF 攻击 |
|
||
| `Max-Age` | 控制有效期 | 延长攻击窗口 |
|
||
|
||
### 单9：Gin 与 Session
|
||
|
||
| 项目 | 内容 |
|
||
|------|------|
|
||
| ✅ 正确答案 | **C（Session 本质是后端存状态，前端只保存 SessionID）** |
|
||
|
||
> [!note] 此题你答对了 ✅。核心要点：
|
||
> - Gin 官方库**不自带** Session，需第三方中间件（如 `gorilla/sessions`）
|
||
> - Session **数据在服务端**，不在客户端（那是 Cookie 的做法）
|
||
> - 关闭浏览器不等于删除服务端 Session（取决于 `Max-Age` 或服务端清理策略）
|
||
|
||
### 单21：Session ID 的存储方式
|
||
|
||
| 项目 | 内容 |
|
||
|------|------|
|
||
| ✅ 正确答案 | **B（Set-Cookie）** |
|
||
|
||
> [!note] 此题你答对了 ✅。首次访问时服务端在 HTTP 响应的 Headers 里写入 `Set-Cookie: session_id=abc123`，浏览器自动保存，后续请求自动带上。
|
||
|
||
---
|
||
|
||
## 五、CORS 跨域问题专题
|
||
|
||
### 单22 ~ 单26：跨域全链路
|
||
|
||
> [!note] 这 5 道题你全部答对了 ✅，涵盖完整的跨域知识体系。整理如下：
|
||
|
||
**单22：生产环境跨域的标准解决方案**
|
||
- Nginx 反向代理统一域名 / CORS 中间件精确配置
|
||
|
||
**单23：为什么要用 Nginx 做反向代理**
|
||
- 静态文件分发、隐藏后端 IP、负载均衡、限流
|
||
|
||
**单24：OPTIONS 预检请求的本质**
|
||
- CORS Preflight：复杂请求前先问后端"我的自定义头你能接受吗？"
|
||
|
||
**单25：Vite Proxy 的开发阶段原理**
|
||
- 前端请求发给 Node.js 开发服务器 → 服务器转发给真实后端 → 原样返回
|
||
|
||
**单26：CORS 报错的根本原因**
|
||
- 浏览器的同源策略（Same-Origin Policy）：防止恶意网站窃取敏感数据
|
||
|
||
> [!abstract] 同源策略判定
|
||
|
||
```
|
||
同源 = 协议相同 && 域名相同 && 端口相同
|
||
|
||
http://localhost:3000 → http://localhost:8080 ❌ 端口不同，跨域！
|
||
https://app.example.com → https://api.example.com ❌ 域名不同，跨域！
|
||
```
|
||
|
||
详见 `[[DEV/跨域问题调试]]` 的详细排查流程。
|
||
|
||
---
|
||
|
||
## 六、HTTP 状态码与语义
|
||
|
||
### 单3、单6、单29：HTTP 基础概念
|
||
|
||
| 题号 | 考查点 | ✅ 答案 | 解析 |
|
||
|------|--------|---------|------|
|
||
| 单3 | "未修改"状态码 | **304** | 浏览器发 `If-Modified-Since` / `If-None-Match`，服务端返回 304 让浏览器用本地缓存 |
|
||
| 单6 | 资源未被修改的状态码 | **304** | 和单3 考同一个知识点，换了一种问法 |
|
||
| 单29 | HTTP "无状态"的含义 | **每次请求独立，服务器不记住之前请求** | 这意味着需要 Cookie/Session/JWT 来维护用户状态 |
|
||
|
||
> [!memory] 与缓存相关的状态码
|
||
|
||
| 状态码 | 含义 | 触发条件 |
|
||
|--------|------|---------|
|
||
| **200** | 正常成功 | 首次请求 / 缓存失效 |
|
||
| **304** | 未修改 | 缓存命中，服务端通知浏览器直接用本地副本 |
|
||
| **206** | 部分内容 | Range 请求（视频断点续传等场景） |
|
||
|
||
---
|
||
|
||
## 七、其他知识点
|
||
|
||
### 单30：Git 临时保存工作进度
|
||
|
||
| 项目 | 内容 |
|
||
|------|------|
|
||
| ✅ 正确答案 | **C（git stash）** |
|
||
|
||
> [!note] 此题你答对了 ✅。
|
||
|
||
```bash
|
||
git stash # 保存当前工作区为"栈顶"
|
||
git stash pop # 恢复最近一次 stash（同时删除它）
|
||
git stash list # 查看所有 stash
|
||
git stash apply # 恢复但不删除（留在栈里）
|
||
```
|
||
|
||
---
|
||
|
||
## 错题自测表
|
||
|
||
> [!summary] 遮住右侧，自己检验是否真正理解了
|
||
|
||
| 题目 | 考查点 | ❌ 你的原答案 | ✅ 正确答案 | 关键概念 |
|
||
|------|--------|-------------|------------|---------|
|
||
| 单1 | GET vs POST 的本质区别 | A | **B** | URL 参数 vs Body，是事实差异而非设计规范 |
|
||
| 单5 | HTTP 默认端口 | D (8080) | **B (80)** | 80 是标准端口，8080 是常见替代 |
|
||
| 单13 | Gin 中间件继续执行的方法 | B (Abort) | **A (Next)** | Next() 继续执行，Abort() 中断链 |
|
||
| 单19 | JWT 解析正确顺序 | C | **A** | 解码 → 验签名 → 查声明（签名是信任锚） |
|
||
|
||
---
|
||
|
||
## 高频考点速览
|
||
|
||
> [!tip] 考前快速过一遍
|
||
|
||
| 类别 | 考点 | 一句话口诀 |
|
||
|------|------|-----------|
|
||
| GET vs POST | 数据位置不同（URL vs Body） | **"GET 挂在 URL 上，POST 装在 Body 里"** |
|
||
| HTTP 默认端口 | 80 | **"HTTP=80，HTTPS=443"** |
|
||
| HTTP 无状态 | 每次请求独立 | **"喝醉就忘，下次重来"** |
|
||
| 304 状态码 | 资源未修改，走缓存 | **"没变就用老的"** |
|
||
| Gin c.Next() | 继续执行后续中间件 + handler | **"过桥费，交了才能走"** |
|
||
| Gin c.Abort() | 中断中间件链 | **"栏杆放下，不让过"** |
|
||
| Gin 全局中间件 | router.Use(middleware) | Use，不是 Register / Attach |
|
||
| Gin 共享数据 | c.Set() / c.Get() | Context 里存取，别用全局变量 |
|
||
| Gin 路径参数 | `/user/:id` | Gin 用 `:` 而不是 `{}` |
|
||
| Gin JSON 绑定 | c.ShouldBindJSON(&obj) | 从请求体映射到 Struct |
|
||
| 401 状态码 | 未认证/缺少凭证 | **"401 = 你是谁？"** |
|
||
| Cookie httpOnly | 防 XSS 读取 | **"JS 看不见，只有浏览器带"** |
|
||
| Session 本质 | 后端存状态，前端拿 SessionID | **"服务器记账，前端拿号码牌"** |
|
||
| JWT 解析三步 | 解码 → 验签名 → 查声明 | **"先看皮相，再验身份证，最后读内容"** |
|
||
| CORS 根因 | 浏览器同源策略 | **"不同源的请求，浏览器不放心"** |
|
||
| OPTIONS 预检 | 复杂请求前的"询问" | **"我先问问你能不能干"** |
|
||
| Git stash | 临时保存工作进度 | **"先收起来，干完别的再放回"** |
|
||
| Nginx 前置 | 反向代理隐藏后端、负载均衡 | **"Nginx 挡在前面，后端躲在后面"** |
|
||
|
||
---
|
||
|
||
## 关联笔记
|
||
|
||
- [[hzh/EXAM]]
|
||
- [[GIN/3-middleware]] — 中间件完整机制（含 c.Next() / c.Abort() 详解）
|
||
- [[GIN/4-context-lifecycle]] — Context 生命周期与方法速查
|
||
- [[GIN/3-middleware/jwt-auth-qa]] — JWT 中间件安全性
|
||
- [[DEV/跨域问题调试]] — 跨域排查全流程
|