vault backup: 2026-05-15 16:26:14
This commit is contained in:
@@ -0,0 +1,678 @@
|
||||
---
|
||||
tags: [Go, 考试, Week01, 武科大服务端]
|
||||
create time: 2026-05-14 12:00
|
||||
---
|
||||
|
||||
# 金山考试 - 武科大服务端-第一次课
|
||||
|
||||
## 概述
|
||||
|
||||
本次考试覆盖 Go 语言基础核心知识点，包括 Git 版本控制基础、字符编码、变量声明、流程控制（`if` / `for` / `switch`）、函数与 `defer`、`panic` / `recover` 错误处理、字符串不可变性等。适合用于检验 Go 入门学习成果。
|
||||
|
||||
**知识点地图：**
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
A[Go 语言基础] --> B[Git 基础]
|
||||
A --> C[字符编码 Unicode / UTF-8]
|
||||
A --> D[变量与类型 rune / string]
|
||||
A --> E[流程控制 if for switch]
|
||||
A --> F[函数 init / defer]
|
||||
A --> G[错误处理 panic recover]
|
||||
A --> H[包管理 go mod]
|
||||
```
|
||||
|
||||
## 正文
|
||||
|
||||
### 一、单选题
|
||||
|
||||
#### 1. Git 查看状态命令
|
||||
|
||||
【单选题】在 Git 中，如何查看当前状态的最简命令是什么？（5分）
|
||||
|
||||
A. `git log`
|
||||
B. `git status`
|
||||
C. `git diff`
|
||||
D. `git commit`
|
||||
|
||||
**正确答案：**B
|
||||
**作答答案：**B
|
||||
|
||||
---
|
||||
|
||||
#### 2. Go 注释方式
|
||||
|
||||
【单选题】在Go语言中,以下哪种注释方式是正确的?（5分）
|
||||
|
||||
Go 语言支持 `//` 形式的单行注释和 `/* */` 形式的多行注释。
|
||||
|
||||
A. `// 这是单行注释`
|
||||
B. `/* 这是多行注释 */`
|
||||
C. `# 这是单行注释`
|
||||
D. A和B都正确
|
||||
|
||||
**正确答案：**D
|
||||
**作答答案：**D
|
||||
|
||||
> [!tip] 注意
|
||||
> Go 不像 Python 或 Shell 脚本使用 `#` 做注释。这是很多初学者容易混淆的地方。
|
||||
|
||||
---
|
||||
|
||||
#### 3. 函数可见性（Export）
|
||||
|
||||
【单选题】在Go语言中，如果一个函数需要被外部包访问，函数名应该如何书写？（5分）
|
||||
|
||||
A. 首字母小写并使用 public 关键字
|
||||
B. 首字母大写
|
||||
C. 完全小写
|
||||
D. 使用 func 关键字作为前缀
|
||||
|
||||
**正确答案：**B
|
||||
**作答答案：**B
|
||||
|
||||
> [!info] Go 没有 public / private 关键字
|
||||
> Go 的包可见性遵循简单规则：**首字母大写 = 导出(公共)，首字母小写 = 不导出(私有)**。同样适用于变量、常量、类型等。
|
||||
|
||||
---
|
||||
|
||||
#### 4. UTF-8 英文字符字节数
|
||||
|
||||
【单选题】在UTF-8编码中，一个英文字符通常占用多少字节？（5分）
|
||||
|
||||
A. 1字节
|
||||
B. 2字节
|
||||
C. 3字节
|
||||
D. 4字节
|
||||
|
||||
**正确答案：**A
|
||||
**作答答案：**A
|
||||
|
||||
---
|
||||
|
||||
#### 5. Unicode 与 UTF-8 的关系
|
||||
|
||||
【单选题】Unicode和UTF-8之间的关系是什么？（5分）
|
||||
|
||||
A. Unicode是一种字符集，UTF-8是Unicode的一种编码方式
|
||||
B. Unicode和UTF-8都是编程语言
|
||||
C. UTF-8是一种字符集，Unicode是UTF-8的一种编码方式
|
||||
D. 没有任何关系
|
||||
|
||||
**正确答案：**A
|
||||
**作答答案：**C
|
||||
|
||||
> [!warning] 易错题 — Unicode vs UTF-8
|
||||
> - **Unicode**：字符集（Character Set），为每个字符分配唯一编号（码点 Code Point），如 `U+0041` → 'A'
|
||||
> - **UTF-8**：编码方案（Encoding Scheme），将码点转换成字节序列存储
|
||||
> - 三者常见关系：Unicode（字符集）→ UTF-8 / UTF-16 / UTF-32（编码方式）
|
||||
|
||||
**对比表：**
|
||||
|
||||
| 概念 | 类比 | 作用 |
|
||||
|------|------|------|
|
||||
| Unicode | 电报码本 | 给每个字符编号 |
|
||||
| UTF-8 | 传输协议 | 把编号变成可传输的字节 |
|
||||
|
||||
---
|
||||
|
||||
#### 6. rune 类型用途
|
||||
|
||||
【单选题】在Go语言中，rune类型通常用于处理什么?（5分）
|
||||
|
||||
A. 整型数据
|
||||
B. 浮点数数据
|
||||
C. Unicode字符
|
||||
D. 布尔型数据
|
||||
|
||||
**正确答案：**C
|
||||
**作答答案：**C
|
||||
|
||||
> [!info] rune 的本质
|
||||
> `rune` 就是 `int32` 的别名，专门用于表示 Unicode 码点（字符）。在 Go 中遍历字符串时，用 `range` 循环得到的就是 `rune` 类型的单个字符。
|
||||
|
||||
---
|
||||
|
||||
#### 7. defer 与命名返回值
|
||||
|
||||
【单选题】下面代码能编译通过吗？可以的话，输出什么？（5分）
|
||||
|
||||
```go
|
||||
func DeferTest2(i int) (r int) {
|
||||
defer func() {
|
||||
r += i
|
||||
}()
|
||||
return 2
|
||||
}
|
||||
|
||||
func main() {
|
||||
fmt.Println(DeferTest2(1))
|
||||
}
|
||||
```
|
||||
|
||||
A. 1
|
||||
B. 2
|
||||
C. 3
|
||||
D. 以上都不是
|
||||
|
||||
**正确答案：**C
|
||||
**作答答案：**C
|
||||
|
||||
> [!important] defer + 命名返回值陷阱
|
||||
> `defer` 闭包捕获的是**命名返回值的引用**。执行流程：
|
||||
> 1. `return 2` 先将 `r` 赋值为 `2`
|
||||
> 2. `defer` 函数执行，`r += 1` → `r` 变为 `3`
|
||||
> 3. 函数返回 `r = 3`
|
||||
>
|
||||
> **关键记忆：有命名返回值时，defer 修改它会影响最终返回值。**
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Main as main
|
||||
participant Func as DeferTest2(1)
|
||||
participant Defer as defer closure
|
||||
Main->>Func: 调用 DeferTest2(1)
|
||||
Func->>Func: return 2 → r = 2
|
||||
Func->>Defer: 执行 defer: r += 1
|
||||
Defer-->>Func: r = 3
|
||||
Func-->>Main: 返回 3
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### 8. fallthrough 语义
|
||||
|
||||
【单选题】下面代码输出什么？（5分）
|
||||
|
||||
```go
|
||||
func main() {
|
||||
isMatch := func(i int) bool {
|
||||
switch(i) {
|
||||
case 1:
|
||||
fallthrough
|
||||
case 2:
|
||||
return true
|
||||
}
|
||||
return false
|
||||
}
|
||||
fmt.Println(isMatch(1))
|
||||
fmt.Println(isMatch(2))
|
||||
}
|
||||
```
|
||||
|
||||
A. `false true`
|
||||
B. `true true`
|
||||
C. `false false`
|
||||
D. `true false`
|
||||
|
||||
**正确答案：**B
|
||||
**作答答案：**B
|
||||
|
||||
> [!tip] fallthrough 的执行逻辑
|
||||
> - `case 1:` 后跟 `fallthrough` → 跳过 case 1 剩余代码，直接进入 case 2 并执行
|
||||
> - case 2 中有 `return true` → 所以传入 1 也返回 true
|
||||
> - 传入 2 → 直接命中 case 2 → 返回 true
|
||||
> - 因此两次输出均为 `true`
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
i[输入值 i] --> check1{i == 1?}
|
||||
check1 -->|是| fall[falsthrough<br/>进入 case 2]
|
||||
check1 -->|否| check2{i == 2?}
|
||||
check2 -->|是| retTrue[return true]
|
||||
fall --> retTrue
|
||||
check2 -->|否| retFalse[return false]
|
||||
retTrue --> OUT1[输出: true]
|
||||
retFalse --> OUT2[输出: false]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### 9. 字符串不可变性
|
||||
|
||||
【单选题】下面代码输出什么？（5分）
|
||||
|
||||
```go
|
||||
func main() {
|
||||
str := "hello"
|
||||
str[0] = 'x'
|
||||
fmt.Println(str)
|
||||
}
|
||||
```
|
||||
|
||||
A. hello
|
||||
B. xello
|
||||
C. compilation error
|
||||
D. 其他
|
||||
|
||||
**正确答案：**C
|
||||
**作答答案：**C
|
||||
|
||||
> [!warning] Go 字符串是只读的！
|
||||
> Go 中的 `string` 是不可变的（immutable），不能像切片那样通过索引赋值修改。如果需要修改字符串，应转为 `[]byte` 或 `[]rune`：
|
||||
>
|
||||
> ```go
|
||||
> b := []byte("hello")
|
||||
> b[0] = 'x'
|
||||
> fmt.Println(string(b)) // 输出: xello
|
||||
> ```
|
||||
|
||||
---
|
||||
|
||||
#### 10. Go 包管理工具
|
||||
|
||||
【单选题】Go语言包管理工具是哪个？（5分）
|
||||
|
||||
A. dep
|
||||
B. go mod
|
||||
C. glide
|
||||
D. gopkg
|
||||
|
||||
**正确答案：**B
|
||||
**作答答案：**B
|
||||
|
||||
> [!info] Go 包管理演进
|
||||
> - **dep**：早期官方实验性工具（已废弃）
|
||||
> - **glide**：社区流行但不再维护
|
||||
> - **go mod**：Go 1.11+ 引入，Go 1.16+ 成为默认标准
|
||||
> - **gopkg.in**：第三方包分发服务，非官方工具
|
||||
|
||||
---
|
||||
|
||||
#### 11. break 跳出循环
|
||||
|
||||
【单选题】在 Go 语言中，以下哪个关键字用于跳出当前的 for 循环？（ ）（5分）
|
||||
|
||||
A. `break`
|
||||
B. `continue`
|
||||
C. `return`
|
||||
D. `goto`
|
||||
|
||||
**正确答案：**A
|
||||
**作答答案：**A
|
||||
|
||||
---
|
||||
|
||||
#### 12. 创建 Go Module
|
||||
|
||||
【单选题】在Go语言中，如何创建一个新的module？（5分）
|
||||
|
||||
A. 使用 `go create` 命令
|
||||
B. 使用 `go mod init` 命令
|
||||
C. 使用 `go new` 命令
|
||||
D. 直接创建一个新文件夹
|
||||
|
||||
**正确答案：**B
|
||||
**作答答案：**B
|
||||
|
||||
---
|
||||
|
||||
#### 13. 全局变量声明
|
||||
|
||||
【单选题】在Go中全局声明和初始化一个名为"counter"的整型变量正确的方式是？（5分）
|
||||
|
||||
A. `var counter = int(0)`
|
||||
B. `var counter int = 0`
|
||||
C. `int counter = 0`
|
||||
D. `counter := 0`
|
||||
|
||||
**正确答案：**B
|
||||
**作答答案：**B
|
||||
|
||||
> [!info] var 声明 vs 短变量声明
|
||||
> - 选项 D `counter := 0` 是短变量声明，只能在**函数内部**使用，不能在包级别（全局）使用
|
||||
> - 选项 B `var counter int = 0` 在全局和局部均可使用
|
||||
> - 实际开发中常用简化写法：`var counter = 0`（省略类型，自动推断）
|
||||
|
||||
---
|
||||
|
||||
#### 14. 短变量声明
|
||||
|
||||
【单选题】以下哪种是 Go 语言的短变量声明方式？（5分）
|
||||
|
||||
A. `var x = 5`
|
||||
B. `x := 5`
|
||||
C. `x int = 5`
|
||||
D. `let x = 5`
|
||||
|
||||
**正确答案：**B
|
||||
**作答答案：**B
|
||||
|
||||
---
|
||||
|
||||
#### 15. init 函数参数
|
||||
|
||||
【单选题】Go语言中的init函数可以接受参数吗？（5分）
|
||||
|
||||
A. 可以，可以接受任意类型的参数
|
||||
B. 可以，但只能接受同一个包内的类型为参数
|
||||
C. 不可以，init函数不能有参数，也不能定义返回值
|
||||
D. 可以，但只能接受基本类型的参数
|
||||
|
||||
**正确答案：**C
|
||||
**作答答案：**C
|
||||
|
||||
---
|
||||
|
||||
#### 16. 下划线 _ 的作用
|
||||
|
||||
【单选题】在 Go 语言中，以下关于下划线的作用描述正确的是？（ ）（5分）
|
||||
|
||||
A. 作为变量名，用于存储无用的值
|
||||
B. 表示私有变量
|
||||
C. 用于注释
|
||||
D. 以上都不对
|
||||
|
||||
**正确答案：**A
|
||||
**作答答案：**A
|
||||
|
||||
> [!info] 下划线 _ 的多重用途
|
||||
> 1. **忽略值**：`_, err := os.Open("file")` — 不需要 err
|
||||
> 2. **导入包副作用**：`import _ "image/png"` — 仅注册，不使用
|
||||
> 3. **空标识符**：用作占位符，避免编译器报错
|
||||
|
||||
---
|
||||
|
||||
#### 17. 转义符号
|
||||
|
||||
【单选题】在 Go 语言中，字符串转义使用的符号是？（5分）
|
||||
|
||||
A. @
|
||||
B. `\`
|
||||
C. `/`
|
||||
D. #
|
||||
|
||||
**正确答案：**B
|
||||
**作答答案：**B
|
||||
|
||||
---
|
||||
|
||||
#### 18. defer + recover 处理 panic
|
||||
|
||||
【单选题】如何在Go中用`defer`和`recover`处理panic?（5分）
|
||||
|
||||
A. 在defer函数中使用panic
|
||||
B. 在defer函数中调用recover进行错误恢复
|
||||
C. 使用defer来抛出错误
|
||||
D. defer和recover无法一起使用
|
||||
|
||||
**正确答案：**B
|
||||
**作答答案：**B
|
||||
|
||||
> [!info] defer 与 recover 配合模式
|
||||
> ```go
|
||||
> defer func() {
|
||||
> if r := recover(); r != nil {
|
||||
> fmt.Println("Recovered from:", r)
|
||||
> }
|
||||
> }()
|
||||
> ```
|
||||
> - `recover()` 必须放在 `defer` 中才能捕获 panic
|
||||
> - 若未发生 panic，`recover()` 返回 `nil`
|
||||
|
||||
---
|
||||
|
||||
#### 19. 引发异常的关键字
|
||||
|
||||
【单选题】在Go程序中，使用哪个关键字可以引发一个异常？（5分）
|
||||
|
||||
A. throw
|
||||
B. error
|
||||
C. exception
|
||||
D. panic
|
||||
|
||||
**正确答案：**D
|
||||
**作答答案：**D
|
||||
|
||||
---
|
||||
|
||||
#### 20. defer 执行顺序
|
||||
|
||||
【单选题】下面的Go代码块中，使用defer关键字的输出顺序是什么？（5分）
|
||||
|
||||
```go
|
||||
package main
|
||||
import "fmt"
|
||||
func main() {
|
||||
defer fmt.Println("First")
|
||||
defer fmt.Println("Second")
|
||||
defer fmt.Println("Third")
|
||||
fmt.Println("Done")
|
||||
}
|
||||
```
|
||||
|
||||
A. `First Second Third Done`
|
||||
B. `Done Third Second First`
|
||||
C. `Third Second First Done`
|
||||
D. `Done First Second Third`
|
||||
|
||||
**正确答案：**B
|
||||
**作答答案：**B
|
||||
|
||||
> [!important] defer 是 LIFO（后进先出）栈
|
||||
> defer 语句按照声明的**逆序**执行，类似栈的 push/pop：
|
||||
> - 先 defer `First` → 最后执行 `First`
|
||||
> - 再 defer `Second` → 倒数执行 `Second`
|
||||
> - 最后 defer `Third` → 最先执行 `Third`
|
||||
> - 正常 `fmt.Println("Done")` → 最先执行
|
||||
|
||||
```mermaid
|
||||
stateDiagram-v2
|
||||
[*] --> MainCode
|
||||
MainCode --> Deferred_Fist : defer Println("First")
|
||||
Deferred_Fist --> Deferred_Second : defer Println("Second")
|
||||
Deferred_Second --> Deferred_Third : defer Println("Third")
|
||||
Deferred_Third --> Normal_Println : Println("Done")
|
||||
Normal_Println --> Third_Exec : defer 开始执行
|
||||
Third_Exec --> Second_Exec : Println("Third")
|
||||
Second_Exec --> First_Exec : Println("Second")
|
||||
First_Exec --> Exit : Println("First")
|
||||
Exit --> [*]
|
||||
|
||||
note right of Normal_Println
|
||||
<b>输出: Done Third Second First</b>
|
||||
defer 按声明逆序执行
|
||||
end note
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 二、多选题
|
||||
|
||||
#### 1. main() 函数特性
|
||||
|
||||
【多选题】关于 main() 函数，下面说法正确的是？（5分）
|
||||
|
||||
A. 不能带参数；
|
||||
B. 不能定义返回值；
|
||||
C. 所在的包必须为 main 包；
|
||||
D. 可以使用 flag 包来获取和解析命令行参数；
|
||||
|
||||
**正确答案：**ABCD
|
||||
**作答答案：**ABCD
|
||||
|
||||
---
|
||||
|
||||
#### 2. switch 语句特性（一）
|
||||
|
||||
【多选题】关于 switch 语句，下面说法正确的是？（5分）
|
||||
|
||||
A. 单个 case 中，可以出现多个结果选项；
|
||||
B. 需要使用 break 来明确退出一个 case;
|
||||
C. 只有在 case 中明确添加 fallthrough 关键字，才会继续执行紧跟的下一个 case;
|
||||
D. 条件表达式必须为常量或者整数；
|
||||
|
||||
**正确答案：**AC
|
||||
**作答答案：**AC
|
||||
|
||||
> [!tip] Go switch 与 C/C++ switch 的区别
|
||||
> - Go 的 case 后**隐式自带 break**，不需要手动写
|
||||
> - 要穿透需显式使用 `fallthrough`
|
||||
> - 条件表达式可以是任意类型（不限于整数）
|
||||
|
||||
---
|
||||
|
||||
#### 3. defer 的实际应用
|
||||
|
||||
【多选题】Go语言defer的实际应用场景（5分）
|
||||
|
||||
A. 在打开文件后立即使用defer来安排文件的关闭
|
||||
B. 在数据库连接成功后使用defer来安排断开连接
|
||||
C. 仅在程序的主函数中使用defer来进行错误处理
|
||||
D. 使用defer来执行重要的日志记录
|
||||
|
||||
**正确答案：**ABD
|
||||
**作答答案：**ABD
|
||||
|
||||
---
|
||||
|
||||
#### 4. bool 变量 if 判断规范
|
||||
|
||||
【多选题】flag 是 bool 型变量，下面 if 表达式符合编码规范的是？（5分）
|
||||
|
||||
A. `if flag == 1`
|
||||
B. `if flag`
|
||||
C. `if flag == false`
|
||||
D. `if !flag`
|
||||
|
||||
**正确答案：**BCD
|
||||
**作答答案：**C
|
||||
|
||||
> [!warning] 易错题
|
||||
> - Go 不支持将整数隐式转为 bool，A 选项 `flag == 1` 语法上就不通（除非 flag 定义为 int）
|
||||
> - Go Code Review Comments 推荐：`if condition` 而非 `if condition == true`
|
||||
> - 作答选 C 可能是因为理解偏差——实际上 B 和 D 是最符合 Go 惯用法的选择
|
||||
|
||||
---
|
||||
|
||||
#### 5. 函数声明语法
|
||||
|
||||
【多选题】关于函数声明，下面语法正确的是？（5分）
|
||||
|
||||
A. `func f(a, b int) (value int, err error)`
|
||||
B. `func f(a int, b int) (value int, err error)`
|
||||
C. `func f(a, b int) (value int, error)`
|
||||
D. `func f(a int, b int) (int, int, error)`
|
||||
|
||||
**正确答案：**ABD
|
||||
**作答答案：**AB
|
||||
|
||||
> [!info] 要点解析
|
||||
> - A ✅：合并相同类型的参数 `a, b int` 是合法的
|
||||
> - B ✅：逐个写类型也是合法的
|
||||
> - C ❌：混合了命名和无命名返回值，`error` 缺少类型名（应为 `e error`）
|
||||
> - D ✅：匿名返回值是完全合法的写法
|
||||
|
||||
---
|
||||
|
||||
#### 6. 变量的自增和自减
|
||||
|
||||
【多选题】关于变量的自增和自减操作，下面语句正确的是？（5分）
|
||||
|
||||
A. `i := 1; i++`
|
||||
B. `i := 1; j = i++`
|
||||
C. `i := 1; ++i`
|
||||
D. `i := 1; i--`
|
||||
|
||||
**正确答案：**AD
|
||||
**作答答案：**ABD
|
||||
|
||||
> [!warning] Go 的独特限制
|
||||
> - Go **只有** `++` 和 `--` 两个复合运算符，且它们是**语句**，不是表达式
|
||||
> - 不能出现在赋值右侧：❌ `j = i++`（选项 B 错误）
|
||||
> - 不支持前置形式：❌ `++i`、`--i`（选项 C 错误）
|
||||
> - 只能单独使用：✅ `i++`、`i--`
|
||||
|
||||
---
|
||||
|
||||
#### 7. bool 变量赋值错误用法
|
||||
|
||||
【多选题】关于 bool 变量 b 的赋值，下面错误的用法是？（5分）
|
||||
|
||||
A. `b = true`
|
||||
B. `b = 1`
|
||||
C. `b = bool(1)`
|
||||
D. `b = (1 == 2)`
|
||||
|
||||
**正确答案：**BC
|
||||
**作答答案：**BC
|
||||
|
||||
> [!info] Go 强类型约束
|
||||
> - Go 不允许整数到 bool 的隐式转换，也不允许 `bool(1)` 这种强制转换
|
||||
> - `1 == 2` 本身就是 bool 类型，赋值合法（选项 D 是正确的写法）
|
||||
|
||||
---
|
||||
|
||||
#### 8. switch 语句特性（二）
|
||||
|
||||
【多选题】关于switch语句，下面说法正确的有?（5分）
|
||||
|
||||
A. 条件表达式必须为常量或者整数；
|
||||
B. 单个case中，可以出现多个结果选项；
|
||||
C. 需要用break来明确退出一个case；
|
||||
D. 只有在case中明确添加fallthrough关键字，才会继续执行紧跟的下一个case；
|
||||
|
||||
**正确答案：**BD
|
||||
**作答答案：**BD
|
||||
|
||||
> [!note] 对比第 2 题
|
||||
> - 本题第 D 项和第 2 题第 C 项表述略有不同——注意区分"单个 case 中多个结果选项"（`case 1, 2, 3:`）和 fallthrough 穿透是两个不同机制
|
||||
> - Go switch 的 case 可以是任意类型，不限于整数
|
||||
|
||||
---
|
||||
|
||||
#### 9. 循环语句特性
|
||||
|
||||
【多选题】关于循环语句，下面说法正确的有（5分）
|
||||
|
||||
A. 循环语句既支持 for 关键字，也支持 while 和 do-while；
|
||||
B. 关键字 for 的基本使用方法与 C/C++ 中没有任何差异；
|
||||
C. for 循环支持 continue 和 break 来控制循环，但是它提供了一个更高级的 break，可以选择中断哪一个循环；
|
||||
D. for 循环不支持以逗号为间隔的多个赋值语句，必须使用平行赋值的方式来初始化多个变量；
|
||||
|
||||
**正确答案：**CD
|
||||
**作答答案：**ACD
|
||||
|
||||
> [!info] Go 只有 for 一种循环
|
||||
> ```go
|
||||
> // 经典三要素
|
||||
> for i := 0; i < 10; i++ {}
|
||||
> // while 风格
|
||||
> for condition {}
|
||||
> // 无限循环
|
||||
> for {}
|
||||
> ```
|
||||
> - Go **没有** while 和 do-while（选项 A 错）
|
||||
> - Go 的 for 比 C/C++ 简化了许多场景（选项 B 错）
|
||||
> - 多变量需平行赋值：`for i, j := 0, len(s)-1; i < j; i, j = i+1, j-1 {}`（选项 D 对）
|
||||
|
||||
---
|
||||
|
||||
#### 10. 全局字符串变量声明
|
||||
|
||||
【多选题】定义一个包内全局字符串变量，下面语法正确的是（）（5分）
|
||||
|
||||
A. `var str string`
|
||||
B. `str:=""`
|
||||
C. `str=""`
|
||||
D. `var str=""`
|
||||
|
||||
**正确答案：**AD
|
||||
**作答答案：**AD
|
||||
|
||||
> [!info] 全局 vs 局部
|
||||
> - A ✅：`var str string` — 包级别变量声明，零值为 `""`
|
||||
> - B ❌：`:=` 只在函数体内可用
|
||||
> - C ❌：包级别不能用简单赋值
|
||||
> - D ✅：`var str = ""` — 包级别变量声明，带初始值
|
||||
|
||||
---
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[hhs/EXAM/Week05]]
|
||||
- [[hhs/EXAM/Week06]]
|
||||
- [[Go/基础语法/变量与类型]]
|
||||
- [[Go/基础语法/流程控制]]
|
||||
- [[Go/基础语法/函数]]
|
||||
- [[Go/进阶/defer与panic]]
|
||||
@@ -0,0 +1,539 @@
|
||||
---
|
||||
tags: [Go, 考试, Week02, 武科大服务端]
|
||||
create time: 2026-05-14 12:00
|
||||
---
|
||||
|
||||
# 金山考试 - 武科大服务端-第二次课
|
||||
|
||||
## 概述
|
||||
|
||||
本次考试覆盖 Go 语言进阶核心知识点，包括切片（slice）、数组与切片的底层关系、Map 操作、结构体与方法、接口实现、标准库（JSON / 文件 / 时间）、指针与内存分配、并发编程（channel / select / sync）等。适合用于检验 Go 入门阶段学习成果。
|
||||
|
||||
**知识点地图：**
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
A[Go 进阶基础] --> B[切片 slice]
|
||||
A --> C[映射 map]
|
||||
A --> D[结构体 struct]
|
||||
A --> E[方法 method]
|
||||
A --> F[接口 interface]
|
||||
A --> G[标准库 JSON/文件/时间]
|
||||
A --> H[指针 new &]
|
||||
A --> I[并发 channel select sync]
|
||||
B --> B1[底层引用共享]
|
||||
B --> B2[make vs new]
|
||||
D --> D1[字段访问 .]
|
||||
E --> E1[值接收者 vs 指针接收者]
|
||||
I --> I1[无缓冲 Channel 同步语义]
|
||||
I --> I2[select 多路复用]
|
||||
I --> I3[WaitGroup / Mutex / RWMutex]
|
||||
```
|
||||
|
||||
## 正文
|
||||
|
||||
### 一、单选题
|
||||
|
||||
#### 1. 错误的切片声明方式
|
||||
|
||||
【单选题】下列关于 Go 语言的切片声明，哪个是错误的？（5分）
|
||||
|
||||
A. `var slice1 []int`
|
||||
B. `slice2 := []int{}`
|
||||
C. `slice3 := make([]int, 0)`
|
||||
D. `slice4 := new([]int)`
|
||||
|
||||
**正确答案：**D
|
||||
**作答答案：**D
|
||||
|
||||
> [!warning] new vs make
|
||||
> - `make(T, args)`：仅用于 **slice、map、channel**，返回类型 T 本身并初始化
|
||||
> - `new(T)`：返回指向类型 T 的零值指针 `*T`，不初始化内部结构
|
||||
> - `new([]int)` 返回的是 `*[]int`，虽然能编译但不能直接当作切片使用
|
||||
|
||||
---
|
||||
|
||||
#### 2. 创建长度 0 容量 10 的切片
|
||||
|
||||
【单选题】要创建一个初始长度为 0，容量为 10 的整数切片，应该使用（5分）
|
||||
|
||||
A. `new([]int)`
|
||||
B. `make([]int, 0, 10)`
|
||||
C. `new([10]int)`
|
||||
D. `make([10]int)`
|
||||
|
||||
**正确答案：**B
|
||||
**作答答案：**B
|
||||
|
||||
> [!info] make 的参数含义
|
||||
> `make([]int, len, cap)` — len 和 cap 均可选：
|
||||
> - `make([]int, 0, 10)` → 长度 0、容量 10
|
||||
> - `make([]int, 10)` → 长度 10、容量 10（cap 省略时等于 len）
|
||||
> - 数组用 `[N]T` 语法声明，不需要 make
|
||||
|
||||
---
|
||||
|
||||
#### 3. 数组 vs 切片的长度特性
|
||||
|
||||
【单选题】以下关于数组和切片的说法，正确的是（5分）
|
||||
|
||||
A. 数组的长度可以动态改变，切片不行
|
||||
B. 切片的长度可以动态改变，数组不行
|
||||
C. 数组和切片的长度都可以动态改变
|
||||
D. 数组和切片的长度都不能动态改变
|
||||
|
||||
**正确答案：**B
|
||||
**作答答案：**B
|
||||
|
||||
> [!tip] 核心区别一句话
|
||||
> 数组长度是**类型的一部分**（`[5]int` 和 `[10]int` 是不同的类型），不可变；切片是对数组的**轻量描述符**（ptr + len + cap），长度可以通过 append/slice 操作动态变化。
|
||||
|
||||
---
|
||||
|
||||
#### 4. 切片修改对底层数组的影响
|
||||
|
||||
【单选题】给定以下 Go 代码，运行后输出结果是什么？（5分）
|
||||
|
||||
```go
|
||||
package main
|
||||
|
||||
import "fmt"
|
||||
|
||||
func main() {
|
||||
arr := [5]int{1, 2, 3, 4, 5}
|
||||
slice := arr[1:4] // 引用 arr[1]=2, arr[2]=3, arr[3]=4
|
||||
slice[0] = 10 // 等价于 arr[1] = 10
|
||||
fmt.Println(arr)
|
||||
}
|
||||
```
|
||||
|
||||
A. `[1 2 3 4 5]`
|
||||
B. `[1 10 3 4 5]`
|
||||
C. `[10 2 3 4 5]`
|
||||
D. 编译错误
|
||||
|
||||
**正确答案：**B
|
||||
**作答答案：**B
|
||||
|
||||
> [!important] 切片共享底层数组
|
||||
> 切片是对底层数组的**引用**。`arr[1:4]` 创建的切片其索引 0 对应 `arr[1]`，因此 `slice[0] = 10` 会直接修改 `arr[1]`。这是理解 Go 切片性能优势的关键——零拷贝传递数据。
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant Arr as arr = [1,2,3,4,5]
|
||||
participant Slc as slice = arr[1:4]
|
||||
participant Set as slice[0] = 10
|
||||
Arr->>Slc: 创建引用（ptr→arr[1], len=3, cap=4）
|
||||
Slc->>Set: 写 slice[0]（即 arr[1]）
|
||||
Set-->>Arr: arr[1] 被改为 10
|
||||
Arr-->>Arr: arr = [1,10,3,4,5]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
#### 5. Map 的 delete 操作
|
||||
|
||||
【单选题】观察下面的 Go 代码，判断运行结果是什么？（5分）
|
||||
|
||||
```go
|
||||
package main
|
||||
|
||||
import "fmt"
|
||||
|
||||
func main() {
|
||||
m := map[string]int{"a": 1, "b": 2, "c": 3}
|
||||
delete(m, "b")
|
||||
fmt.Println(m)
|
||||
}
|
||||
```
|
||||
|
||||
A. `map[a:1 b:2 c:3]`
|
||||
B. `map[a:1 b:0 c:3]`
|
||||
C. `map[a:1 c:3]`
|
||||
D. `map[a:1]`
|
||||
|
||||
**正确答案：**C
|
||||
**作答答案：**C
|
||||
|
||||
> [!info] delete 的语义
|
||||
> `delete(map, key)` 直接删除键值对，key 不存在时也是安全的（noop，不 panic）。打印时只保留剩余元素。
|
||||
|
||||
---
|
||||
|
||||
#### 6. map 的 json.Unmarshal
|
||||
|
||||
【单选题】关于 map，下面说法正确的是？（5分）
|
||||
|
||||
A. `json.Unmarshal()` 的入参必须为 map 的地址
|
||||
B. 在函数调用中传递 map，则子函数中对 map 元素的增加不会导致父函数中 map 的修改
|
||||
C. 不能使用内置函数 `delete()` 删除 map 的元素
|
||||
D. 以上都不对
|
||||
|
||||
**正确答案：**A
|
||||
**作答答案：**A
|
||||
|
||||
> [!info] 为什么必须是地址？
|
||||
> `json.Unmarshal(data, &m)` 需要指针才能修改原 map。而 `json.Marshal(data, m)` 不需要地址（值即可读取）。
|
||||
>
|
||||
> **补充：map 作为参数传递**——Go 中 map 是引用类型（内部是指针结构体），所以子函数通过同一底层数据结构增删元素，父函数可见。选项 B 说反了。
|
||||
|
||||
---
|
||||
|
||||
#### 7. 结构体字段访问
|
||||
|
||||
【单选题】在 Go 语言中，如果你有一个结构体实例 `myStruct`，你如何访问其字段 `field1` 的值？（5分）
|
||||
|
||||
A. `myStruct[field1]`
|
||||
B. `myStruct->field1`
|
||||
C. `myStruct.field1`
|
||||
D. `*myStruct.field1`
|
||||
|
||||
**正确答案：**C
|
||||
**作答答案：**C
|
||||
|
||||
> [!note] Go 没有箭头运算符
|
||||
> Go 不使用 `->`（C/C++ 风格），也不使用 `[key]`（像 map 那样）。统一用点号 `.` 访问字段。当持有指针 `p` 时，也只需 `p.Field`，编译器自动解引用。
|
||||
|
||||
---
|
||||
|
||||
#### 8. 结构体方法的错误认知
|
||||
|
||||
【单选题】以下关于结构体方法的说法，错误的是（5分）
|
||||
|
||||
A. 值接收者方法不能修改结构体的字段值
|
||||
B. 指针接收者方法可以修改结构体的字段值
|
||||
C. 值接收者方法在传递参数时效率更高
|
||||
D. 指针接收者方法在结构体较大时更节省内存
|
||||
|
||||
**正确答案：**C
|
||||
**作答答案：**C
|
||||
|
||||
> [!warning] 值接收者的陷阱
|
||||
> - A ✅：值接收者是副本，修改不影响原对象
|
||||
> - B ✅：指针接收者直接操作原对象
|
||||
> - C ❌：**这是本题答案**。值接收者在传参时需要复制整个结构体，当结构体较大时反而更慢
|
||||
> - D ✅：指针只传 8 字节（ptr），避免完整复制
|
||||
|
||||
---
|
||||
|
||||
#### 9. 接口实现的完整性
|
||||
|
||||
【单选题】Go 中如何正确实现一个接口？（5分）
|
||||
|
||||
A. 只需要声明接口中的所有方法
|
||||
B. 只需要部分实现接口中的方法
|
||||
C. 需要声明并实现接口中的所有方法
|
||||
D. 接口不能被实现，只能被继承
|
||||
|
||||
**正确答案：**C
|
||||
**作答答案：**C
|
||||
|
||||
> [!info] Go 接口是隐式实现
|
||||
> Go 没有 `implements` 关键字。只要一个类型的**所有方法签名**与接口一致，就自动实现了该接口。缺少任一方法都会编译报错。
|
||||
|
||||
---
|
||||
|
||||
#### 10. JSON 处理的标准库
|
||||
|
||||
【单选题】在 Go 中处理 JSON 数据的推荐方法是？（5分）
|
||||
|
||||
A. 使用 `encoding/json` 标准库
|
||||
B. 使用外部包如 `jsoniter`
|
||||
C. 手动解析字符串
|
||||
D. 使用 `bufio` 读取器
|
||||
|
||||
**正确答案：**A
|
||||
**作答答案：**A
|
||||
|
||||
> [!info] encoding/json
|
||||
> Go 标准库 `encoding/json` 提供 `Marshal` / `Unmarshal` 两个核心函数，通过结构体 tag（`` `json:"name"` ``）控制序列化行为，满足绝大多数场景需求。
|
||||
|
||||
---
|
||||
|
||||
#### 11. 格式化输出的函数选择
|
||||
|
||||
【单选题】在 Go 中，如何通过 fmt 包输出格式化的字符串？（5分）
|
||||
|
||||
A. `fmt.Print()`
|
||||
B. `fmt.Println()`
|
||||
C. `fmt.Printf()`
|
||||
D. `fmt.Format()`
|
||||
|
||||
**正确答案：**C
|
||||
**作答答案：**C
|
||||
|
||||
> [!tip] fmt 包常用函数速记
|
||||
> - `Print`：无换行，无格式
|
||||
> - `Println`：自动追加换行
|
||||
> - `Printf`：**支持占位符格式化**，如 `%d`、`%s`、`%v`
|
||||
|
||||
---
|
||||
|
||||
#### 12. 读取文件的便捷方式
|
||||
|
||||
【单选题】选择 Go 语言中正确的方式来读取文件。（5分）
|
||||
|
||||
A. `os.ReadFile()`
|
||||
B. `os.OpenFile()`
|
||||
C. `ioutil.ReadAll()`
|
||||
D. `file.Read()`
|
||||
|
||||
**正确答案：**A
|
||||
**作答答案：**A
|
||||
|
||||
> [!note] ioutil 已废弃
|
||||
> `ioutil.ReadAll` 和 `ioutil.ReadFile` 在 Go 1.16+ 中被迁移到 `io` 和 `os` 包中。推荐写法：`os.ReadFile("path")` 一次性读取全部文件内容到 `[]byte`。
|
||||
|
||||
---
|
||||
|
||||
#### 13. 时间日期的标准库
|
||||
|
||||
【单选题】在 Go 中，用于处理时间和日期的标准库是哪一个？（5分）
|
||||
|
||||
A. `time`
|
||||
B. `date`
|
||||
C. `timer`
|
||||
D. `clock`
|
||||
|
||||
**正确答案：**A
|
||||
**作答答案：**A
|
||||
|
||||
> [!info] time 包核心用法
|
||||
> ```go
|
||||
> now := time.Now() // 当前时间
|
||||
> time.Sleep(1 * time.Second) // 休眠
|
||||
> t.Format("2006-01-02 15:04:05") // 格式化（记忆：参考时间 2006-01-02）
|
||||
> ```
|
||||
|
||||
---
|
||||
|
||||
#### 14. new 的正确使用场景
|
||||
|
||||
【单选题】以下哪种情况应该使用 `new` 来分配内存？（5分）
|
||||
|
||||
A. 创建一个切片
|
||||
B. 创建一个映射
|
||||
C. 创建一个结构体指针
|
||||
D. 扩展一个切片的容量
|
||||
|
||||
**正确答案：**C
|
||||
**作答答案：**C
|
||||
|
||||
> [!info] new vs make 对比
|
||||
> | 用途 | new(T) | make(T, ...)|
|
||||
> |------|--------|-------------|
|
||||
> | 返回类型 | `*T`（指针） | T 本身 |
|
||||
> | 适用于 | 所有类型 | slice, map, channel |
|
||||
> | 初始化 | 零值 | 完整初始化 |
|
||||
> | 典型场景 | `new(Person)` | `make([]int, 10)` |
|
||||
|
||||
---
|
||||
|
||||
#### 15. 无缓冲 channel 的同步语义
|
||||
|
||||
【单选题】无缓冲 channel 的特点是什么？（5分）
|
||||
|
||||
A. 发送操作永远不会阻塞
|
||||
B. 接收操作永远不会阻塞
|
||||
C. 发送和接收操作必须同时发生
|
||||
D. 可以存储无限数量的值
|
||||
|
||||
**正确答案：**C
|
||||
**作答答案：**C
|
||||
|
||||
> [!important] 无缓冲 Channel = 同步通道
|
||||
> - 容量为 0，send 和 receive **必须同时就绪**才能完成
|
||||
> - 生产者 send 后阻塞直到有消费者 receive
|
||||
> - 消费者 receive 后阻塞直到有生产者 send
|
||||
> - 这是 goroutine 间最原子的同步机制
|
||||
|
||||
---
|
||||
|
||||
#### 16. Select 语句的作用
|
||||
|
||||
【单选题】Go 语言中的 `select` 语句用于什么目的？（5分）
|
||||
|
||||
A. 声明变量
|
||||
B. 捕获异常
|
||||
C. 监听多个 Channel 操作
|
||||
D. 同步 Goroutine
|
||||
|
||||
**正确答案：**C
|
||||
**作答答案：**C
|
||||
|
||||
> [!info] select 的行为规则
|
||||
> - 每个 case 必须是 channel 的 send 或 receive 操作
|
||||
> - 所有 case 求值后，随机选择一个可用的执行
|
||||
> - 若无可用 case 且有 `default`，立即执行 default
|
||||
> - 若无可用 case 且无 default，阻塞直到某个 case 就绪
|
||||
|
||||
---
|
||||
|
||||
#### 17. Goroutine 同步的原语选择
|
||||
|
||||
【单选题】在 Go 语言中，哪个 sync 原语可以用于确保多个 Goroutine 的同步执行？（5分）
|
||||
|
||||
A. `WaitGroup`
|
||||
B. `Mutex`
|
||||
C. `Atomic`
|
||||
D. `Context`
|
||||
|
||||
**正确答案：**A
|
||||
**作答答案：**A
|
||||
|
||||
> [!info] 各 sync 原语分工
|
||||
> - `sync.WaitGroup`：**等待一组 goroutine 完成**（Add / Done / Wait）
|
||||
> - `sync.Mutex`：互斥锁，保护临界区
|
||||
> - `sync/atomic`：原子操作，无锁并发
|
||||
> - `context.Context`：取消信号与超时控制
|
||||
|
||||
---
|
||||
|
||||
#### 18. 取地址运算符
|
||||
|
||||
【单选题】在 Go 中获取变量的内存地址应使用什么运算符？（5分）
|
||||
|
||||
A. `*`
|
||||
B. `&`
|
||||
C. `#`
|
||||
D. `@`
|
||||
|
||||
**正确答案：**B
|
||||
**作答答案：**B
|
||||
|
||||
> [!tip] 指针运算口诀
|
||||
> - `&x`：取 x 的地址
|
||||
> - `*p`：解除 p 指向，访问目标值
|
||||
> - 二者互为逆运算：`*&x == x`，`&*p == p`
|
||||
|
||||
---
|
||||
|
||||
#### 19. RWMutex vs Mutex
|
||||
|
||||
【单选题】在 Go 中，`sync.RWMutex` 与 `sync.Mutex` 的主要区别是？（5分）
|
||||
|
||||
A. Mutex 只支持读操作
|
||||
B. RWMutex 允许多个读锁或一个写锁，Mutex 仅支持互斥访问
|
||||
C. 两者没有区别
|
||||
D. RWMutex 不能与 channel 同时使用
|
||||
|
||||
**正确答案：**B
|
||||
**作答答案：**B
|
||||
|
||||
> [!info] 读写锁的性能意义
|
||||
> 当读多写少时，`RWMutex` 显著优于 `Mutex`：多个 goroutine 可同时持有多把读锁 (`RLock`)，只有写操作 (`Lock`) 时才互斥。这是典型的「读并发、写串行」优化手段。
|
||||
|
||||
---
|
||||
|
||||
#### 20. 使用指针接收者的原因
|
||||
|
||||
【单选题】以下结构体方法定义中，使用指针接收者的原因通常是（5分）
|
||||
|
||||
A. 方法内部需要修改结构体的字段值
|
||||
B. 为了提高性能（避免大结构体拷贝）
|
||||
C. 为了遵循代码规范
|
||||
D. 以上都是
|
||||
|
||||
**正确答案：**D
|
||||
**作答答案：**D
|
||||
|
||||
> [!info] 何时用指针接收者？
|
||||
> 1. 需要**修改**原对象状态
|
||||
> 2. 结构体**较大**，减少拷贝开销
|
||||
> 3. 需要保证**一致性**（同一个对象的方法要么全用指针，要么全用值接收者）
|
||||
|
||||
---
|
||||
|
||||
#### 21. 值接收者方法不会修改原对象
|
||||
|
||||
【单选题】对于以下结构体和方法定义，调用 ChangeName 方法后，原始的 Person 结构体实例的 Name 字段会改变吗？（5分）
|
||||
|
||||
```language
|
||||
type Person struct {
|
||||
Name string
|
||||
Age int
|
||||
}
|
||||
|
||||
func (p Person) ChangeName(newName string) {
|
||||
p.Name = newName
|
||||
}
|
||||
```
|
||||
|
||||
A. 会
|
||||
B. 不会
|
||||
C. 不确定
|
||||
D. 以上都不对
|
||||
|
||||
**正确答案：**B
|
||||
**作答答案：**B
|
||||
|
||||
> [!warning] 经典面试题
|
||||
> `ChangeName` 使用**值接收者**，这意味着 `p` 是原对象的**副本**。方法内修改 `p.Name` 只会影响副本，原对象不受影响。若希望修改生效，应将接收者改为指针 `(p *Person)`。
|
||||
|
||||
---
|
||||
|
||||
### 二、多选题
|
||||
|
||||
#### 1. 指针访问成员变量的方式
|
||||
|
||||
【多选题】通过指针变量 p 访问其成员变量 name，有哪几种方式？（5分）
|
||||
|
||||
A. `p.name`
|
||||
B. `(&p).name`
|
||||
C. `(*p).name`
|
||||
D. `p->name`
|
||||
|
||||
**正确答案：**AC
|
||||
**作答答案：**AC
|
||||
|
||||
> [!info] 指针访问字段两种方式
|
||||
> - `p.name` ✅：Go 语法糖，编译器自动解引用，推荐写法
|
||||
> - `(*p).name` ✅：先解引用再 `.name`，等价但稍显繁琐
|
||||
> - `(&p).name` ❌：`&p` 是指针的地址（双重指针 `**P`），不符合题意
|
||||
> - `p->name` ❌：Go 没有 `->` 运算符
|
||||
|
||||
---
|
||||
|
||||
#### 2. panic 和 recover 的使用
|
||||
|
||||
【多选题】关于 Go 语言中 panic 和 recover 的使用，以下正确的是？（5分）
|
||||
|
||||
A. panic 可以在任何地方引发，但 recover 只有在 defer 调用的函数中有效
|
||||
B. recover 用于终止 panic 的异常传递过程
|
||||
C. panic 无法被捕获，会直接导致程序崩溃
|
||||
D. 使用 panic 和 recover 可以替代传统的错误处理方式
|
||||
|
||||
**正确答案：**AB
|
||||
**作答答案：**ABC
|
||||
|
||||
> [!warning] 易错辨析
|
||||
> - A ✅：recover 放在 defer 中能捕获当前 goroutine 的 panic，阻止程序崩溃
|
||||
> - B ✅：recover 被调用后，panic 链中断，程序恢复正常运行
|
||||
> - C ❌：panic **可以**被 recover 捕获，并非一定会导致程序崩溃
|
||||
> - D ❌：Go 设计哲学中，panic 用于**真正的异常情况**（如编程错误、初始化失败），业务错误应用 error 返回
|
||||
|
||||
---
|
||||
|
||||
#### 3. 数组和切片的综合理解
|
||||
|
||||
【多选题】在 Go 语言中，关于数组（array）和切片（slice），以下说法正确的是？（5分）
|
||||
|
||||
A. 数组定义时必须指定长度，且长度是数组类型的一部分
|
||||
B. 切片定义时不需要指定长度，其长度可以在运行时动态变化
|
||||
C. 数组作为函数参数传递时，传递的是数组的副本，函数内对数组的修改不会影响原始数组
|
||||
D. 切片作为函数参数传递时，传递的是切片结构体的副本，函数内对切片的修改会反映到原始切片上
|
||||
|
||||
**正确答案：**ABCD
|
||||
**作答答案：**ABCD
|
||||
|
||||
> [!important] 四个选项全对的原因
|
||||
> - A ✅：`[3]int` 和 `[5]int` 是不同长度决定类型
|
||||
> - B ✅：slice 本质是「指针+长度+容量」描述符
|
||||
> - C ✅：数组传值是**深拷贝**整个数组内容
|
||||
> - D ✅：slice 内部含底层数组指针，虽然 slice 自身是副本（ptr/len/cap 三件套被拷贝），但对 `slice[i] = x` 等元素级修改通过 ptr 反映到底层数组，因此源数据可见
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[hhs/EXAM/Week01]]
|
||||
- [[hhs/EXAM/Week05]]
|
||||
- [[hhs/EXAM/Week06]]
|
||||
@@ -0,0 +1,811 @@
|
||||
---
|
||||
tags: [exam, gin, go, http, jwt, cors, middleware, session, cookie, web]
|
||||
create time: 2026-05-14 18:30
|
||||
---
|
||||
|
||||
# 金山考试 - 武科大服务端 - 第三次课
|
||||
|
||||
## 概述
|
||||
|
||||
武科大服务端第三次课的考试错题整理与知识点拓展。共 30 道单选题，满分 150 分，涉及 HTTP 协议基础、Gin 框架中间件、Cookie/Session/JWT 认证、CORS 跨域、Nginx 反向代理等核心后端开发知识。
|
||||
|
||||
**得分：145/150（仅第 12 题出错）**
|
||||
|
||||
---
|
||||
|
||||
## 我的错题
|
||||
|
||||
### 第 12 题 — Gin 全局注册中间件
|
||||
|
||||
**你的作答：** D · **正确答案：** A
|
||||
|
||||
```go
|
||||
// 错误答案 ❌
|
||||
router.Middleware(middleware)
|
||||
|
||||
// 正确答案 ✔
|
||||
router.Use(middleware)
|
||||
```
|
||||
|
||||
> [!tip] 考点解析
|
||||
>
|
||||
> Gin 使用 `Use()` 方法注册**全局中间件**，参数接受一个或多个 `HandlerFunc`：
|
||||
>
|
||||
> ```go
|
||||
> router := gin.Default()
|
||||
> // 全局注册：所有路由都会经过此中间件
|
||||
> router.Use(GinLogger())
|
||||
> router.Use(GinRecovery())
|
||||
>
|
||||
> // 组级注册：只对 /v1 组生效
|
||||
> v1 := router.Group("/v1")
|
||||
> v1.Use(AuthMiddleware())
|
||||
> {
|
||||
> v1.GET("/user", getUserHandler)
|
||||
> }
|
||||
> ```
|
||||
>
|
||||
> **记忆要点：** `Use` 是链式的，中间件按注册顺序执行。
|
||||
>
|
||||
> | 方法 | 作用范围 | 说明 |
|
||||
> |------|---------|------|
|
||||
> | `router.Use()` | 全局中间件 | 所有路由生效 |
|
||||
> | `group.Use()` | 组中间件 | 仅该 Group 下路由生效 |
|
||||
|
||||
---
|
||||
|
||||
## 正文
|
||||
|
||||
### 一、HTTP 协议基础
|
||||
|
||||
> [!abstract] 本节覆盖：第 1、5、29 题
|
||||
>
|
||||
> HTTP 是 Web 的基石。理解它的无状态特性、方法语义和端口规范，是后续学习所有后端技术的前提。
|
||||
|
||||
#### 第 1 题
|
||||
|
||||
【单选题】HTTP请求中的 GET 和 POST 有什么主要区别？（5分）
|
||||
|
||||
A. GET请求通常用于请求数据，POST请求只用于提交数据。
|
||||
|
||||
B. GET请求的数据会附加在URL之后，POST请求的数据放在请求体内。
|
||||
|
||||
C. GET请求可以获取新的资源，POST请求无法获取资源。
|
||||
|
||||
D. GET请求不安全，POST请求比GET请求安全。
|
||||
|
||||
**正确答案：** B
|
||||
|
||||
**作答答案：** B
|
||||
|
||||
> [!tip] 深度理解
|
||||
>
|
||||
> - **URL vs Body**：GET 的参数拼在 URL 后（如 `/api/user?id=1`），受长度限制且会出现在浏览器历史记录中；POST 的数据放在 Request Body 中，没有长度限制。
|
||||
> - **幂等性**：GET 应该是幂等的（多次请求结果一致），POST 不是。
|
||||
> - **安全性误区**：POST != 安全！两者都是明文传输（除非配合 HTTPS）。敏感数据应该用 HTTPS，而非依赖 POST。
|
||||
|
||||
#### 第 5 题
|
||||
|
||||
【单选题】下列哪一项是 HTTP 的默认端口号?（5分）
|
||||
|
||||
A. 21
|
||||
|
||||
B. 80
|
||||
|
||||
C. 443
|
||||
|
||||
D. 8080
|
||||
|
||||
**正确答案：** B
|
||||
|
||||
**作答答案：** B
|
||||
|
||||
> [!note] 常见端口速查
|
||||
>
|
||||
> | 端口 | 协议 | 用途 |
|
||||
> |------|------|------|
|
||||
> | 80 | HTTP | 标准 Web 服务 |
|
||||
> | 443 | HTTPS | 加密 Web 服务 |
|
||||
> | 21 | FTP | 文件传输 |
|
||||
> | 3306 | MySQL | 数据库 |
|
||||
> | 8080 | HTTP | 常用开发/替代端口 |
|
||||
|
||||
#### 第 29 题
|
||||
|
||||
【单选题】HTTP协议被称为"无状态 (Stateless)"协议，这到底意味着什么？（5分）
|
||||
|
||||
A. 服务器无法一次性处理多个状态的请求
|
||||
|
||||
B. 每次请求都是独立的，服务器默认不会记住之前的请求信息
|
||||
|
||||
C. 数据在传输过程中没有加密状态
|
||||
|
||||
D. 客户端不需要等待服务器的响应即可发送下一个请求
|
||||
|
||||
**正确答案：** B
|
||||
|
||||
**作答答案：** B
|
||||
|
||||
> [!example] 为什么需要 Cookie/Session/JWT？
|
||||
>
|
||||
> 因为 HTTP 是无状态的——每次请求都是一次"失忆"的新对话。为了维持用户登录态，我们需要额外的机制来"记住"用户是谁：
|
||||
>
|
||||
> ```mermaid
|
||||
> sequenceDiagram
|
||||
> participant Browser as 浏览器
|
||||
> participant Server as 服务端
|
||||
> Browser->>Server: 1. POST /login (账号密码)
|
||||
> Server->>Browser: 2. Set-Cookie: sessionId=abc123
|
||||
> Browser->>Server: 3. GET /profile (携带 Cookie)
|
||||
> Server->>Server: 4. 根据 sessionId 查 Session 数据
|
||||
> Server->>Browser: 5. 返回用户个人信息
|
||||
> ```
|
||||
|
||||
---
|
||||
|
||||
### 二、缓存控制
|
||||
|
||||
> [!abstract] 本节覆盖：第 2、3、6 题
|
||||
>
|
||||
> 缓存是 Web 性能优化的核心手段。理解 Cache-Control 和 304 状态码，能让你的应用快得多。
|
||||
|
||||
#### 第 2 题
|
||||
|
||||
【单选题】以下哪个 HTTP 头字段可以用于管理缓存的过期时间？（5分）
|
||||
|
||||
A. Content-Type
|
||||
|
||||
B. Cache-Control
|
||||
|
||||
C. Authorization
|
||||
|
||||
D. Location
|
||||
|
||||
**正确答案：** B
|
||||
|
||||
**作答答案：** B
|
||||
|
||||
#### 第 3 题
|
||||
|
||||
【单选题】哪种 HTTP 状态码代表"未修改"？（5分）
|
||||
|
||||
A. 200 OK
|
||||
|
||||
B. 304 Not Modified
|
||||
|
||||
C. 404 Not Found
|
||||
|
||||
D. 500 Internal Server Error
|
||||
|
||||
**正确答案：** B
|
||||
|
||||
**作答答案：** B
|
||||
|
||||
#### 第 6 题
|
||||
|
||||
【单选题】HTTP协议中哪个状态码表示请求的资源未被修改？（5分）
|
||||
|
||||
A. 200
|
||||
|
||||
B. 403
|
||||
|
||||
C. 304
|
||||
|
||||
D. 500
|
||||
|
||||
**正确答案：** C
|
||||
|
||||
**作答答案：** C
|
||||
|
||||
> [!tip] Cache-Control + 304 组合拳
|
||||
>
|
||||
> 两种缓存策略各有分工：
|
||||
>
|
||||
> | 策略 | 原理 | 关键头 |
|
||||
> |------|------|--------|
|
||||
> | **强缓存** | 不发起请求，直接读本地缓存 | `Cache-Control: max-age=3600` |
|
||||
> | **协商缓存** | 发请求问服务端"我缓存过期的没" | `ETag` + `If-None-Match` |
|
||||
>
|
||||
> **完整流程：**
|
||||
>
|
||||
> ```mermaid
|
||||
> sequenceDiagram
|
||||
> participant 浏览器
|
||||
> participant 服务端
|
||||
> 浏览器->>服务端: GET /data (带 If-None-Match: "abc123")
|
||||
> 服务端->>服务端: 检查资源是否变化
|
||||
> alt 资源未变化
|
||||
> 服务端-->>浏览器: 304 Not Modified
|
||||
> 浏览器->>浏览器: 使用本地缓存
|
||||
> else 资源已变化
|
||||
> 服务端-->>浏览器: 200 + 新内容 + 新 ETag
|
||||
> end
|
||||
> ```
|
||||
>
|
||||
> **两个关键头**：
|
||||
> - **ETag**：服务器生成的资源指纹（哈希值），如 `"abc123"`
|
||||
> - **If-None-Match**：浏览器下次请求时把上次的 ETag 传回来让服务端比对
|
||||
|
||||
---
|
||||
|
||||
### 三、Gin 框架核心
|
||||
|
||||
> [!abstract] 本节覆盖：第 8、13~18、20、27 题
|
||||
>
|
||||
> Gin 是 Go 生态最流行的 Web 框架。掌握 Context、路由、绑定和中间件，你就掌握了 Gin 的命脉。
|
||||
|
||||
#### 第 8 题
|
||||
|
||||
【单选题】在Go language HTTP server中，如何从HTTP请求中解析查询参数？（5分）
|
||||
|
||||
A. 使用req.URL.Query()方法
|
||||
|
||||
B. 调用req.ParseForm()然后使用req.Form
|
||||
|
||||
C. 使用req.GetHeader('Query')方法
|
||||
|
||||
D. 手动解析req.Body流中的内容
|
||||
|
||||
**正确答案：** A
|
||||
|
||||
**作答答案：** A
|
||||
|
||||
> [!code Go] 查询参数解析对比
|
||||
>
|
||||
> ```go
|
||||
> // 方式1：net/http 原生
|
||||
> values := req.URL.Query() // map[string][]string
|
||||
> id := values.Get("id") // string
|
||||
>
|
||||
> // 方式2：Gin 封装（更简洁）
|
||||
> id := c.Query("id") // string（单值）
|
||||
> ids := c.QueryArray("id") // []string（多值）
|
||||
> fid := c.DefaultQuery("id", "1") // 带默认值
|
||||
> ```
|
||||
|
||||
#### 第 13 题
|
||||
|
||||
【单选题】编写一个Gin中间件（比如计算请求耗时）时，哪个方法用于暂停当前中间件的执行，先去执行后续的业务逻辑(Handler)，等业务执行完再回来继续执行中间件剩余的代码？（5分）
|
||||
|
||||
A. c.Next()
|
||||
|
||||
B. c.Abort()
|
||||
|
||||
C. c.Stop()
|
||||
|
||||
D. c.Return()
|
||||
|
||||
**正确答案：** A
|
||||
|
||||
**作答答案：** A
|
||||
|
||||
> [!important] Next() vs Abort() — 中间件的双向控制
|
||||
>
|
||||
> ```go
|
||||
> func Logger() gin.HandlerFunc {
|
||||
> start := time.Now() // 记录开始时间
|
||||
> c.Next() // ▶ 放行给后续中间件/handler
|
||||
> // ◀ 这里会继续执行（像洋葱剥开又合上）
|
||||
> log.Printf("%s %s %v", c.Writer.Status(), c.Request.URL.Path, time.Since(start))
|
||||
> }
|
||||
>
|
||||
> func Auth() gin.HandlerFunc {
|
||||
> token := c.GetHeader("Authorization")
|
||||
> if token == "" {
|
||||
> c.Abort() // 中断链条，不再执行后续中间件
|
||||
> c.JSON(401, gin.H{"error": "缺少认证"})
|
||||
> return
|
||||
> }
|
||||
> c.Next() // 验证通过，放行
|
||||
> }
|
||||
> ```
|
||||
|
||||
#### 第 14 题
|
||||
|
||||
【单选题】当前端发送了一段JSON数据，后端想将其解析并映射到Go的一个结构体(Struct)上，推荐使用哪个方法？（5分）
|
||||
|
||||
A. c.Query()
|
||||
|
||||
B. c.PostForm()
|
||||
|
||||
C. c.ShouldBindJSON()
|
||||
|
||||
D. c.GetString()
|
||||
|
||||
**正确答案：** C
|
||||
|
||||
**作答答案：** C
|
||||
|
||||
> [!code Go] Gin 常用绑定方法
|
||||
>
|
||||
> ```go
|
||||
> type User struct {
|
||||
> Name string `json:"name" binding:"required"`
|
||||
> Age int `json:"age" binding:"gte=0,lte=150"`
|
||||
> }
|
||||
>
|
||||
> func handler(c *gin.Context) {
|
||||
> var u User
|
||||
> _ = c.ShouldBindJSON(&u) // 绑定 JSON body
|
||||
> // 其他绑定方式：
|
||||
> c.ShouldBindQuery(&u) // 绑定 ?name=x&age=18
|
||||
> c.ShouldBindUri(&u) // 绑定 /users/123
|
||||
> c.ShouldBind(&u) // 自动识别 content-type
|
||||
> }
|
||||
> ```
|
||||
|
||||
#### 第 15 题
|
||||
|
||||
【单选题】在Gin中，你想设计一个路由来获取特定ID的用户信息（例如从 /user/123 中提取出 123），正确的动态路由定义方式是什么？（5分）
|
||||
|
||||
A. router.GET("/user/?id", handler)
|
||||
|
||||
B. router.GET("/user/:id", handler)
|
||||
|
||||
C. router.GET("/user/*id", handler)
|
||||
|
||||
D. router.GET("/user/{id}", handler)
|
||||
|
||||
**正确答案：** B
|
||||
|
||||
**作答答案：** B
|
||||
|
||||
> [!note] Gin 路由语法速记
|
||||
>
|
||||
> | 模式 | 含义 | 示例 |
|
||||
> |------|------|------|
|
||||
> | `/user/:id` | 单变量 | `/user/123` → id="123" |
|
||||
> | `/user/*path` | 通配符 | `/user/a/b/c` → path="/a/b/c" |
|
||||
> | `/user/search` | 固定路径 | 精确匹配 |
|
||||
|
||||
#### 第 16 题
|
||||
|
||||
【单选题】在Gin框架中，中间件的用途是什么？（5分）
|
||||
|
||||
A. 在处理请求和发送响应之间执行额外的逻辑。
|
||||
|
||||
B. 生成项目的文档。
|
||||
|
||||
C. 处理数据库连接。
|
||||
|
||||
D. 定义项目配置。
|
||||
|
||||
**正确答案：** A
|
||||
|
||||
**作答答案：** A
|
||||
|
||||
#### 第 17 题
|
||||
|
||||
【单选题】在Gin框架中，若需要在中间件之间共享数据，应使用哪种方式?（5分）
|
||||
|
||||
A. 利用c.Set存储数据，并在另一个中间件中通过c.Get获取。
|
||||
|
||||
B. 直接将数据作为参数传递至下一个中间件。
|
||||
|
||||
C. 使用全局变量来存储和共享数据。
|
||||
|
||||
D. 创建一个新的结构体来在中间件之间传递数据。
|
||||
|
||||
**正确答案：** A
|
||||
|
||||
**作答答案：** A
|
||||
|
||||
> [!code Go] c.Set / c.Get 在中间间共享数据
|
||||
>
|
||||
> ```go
|
||||
> func UserInfoExtractor() gin.HandlerFunc {
|
||||
> user := fetchUserFromToken(c.GetHeader("Authorization"))
|
||||
> c.Set("userID", user.ID) // 存入上下文
|
||||
> c.Set("username", user.Name)
|
||||
> c.Next()
|
||||
> }
|
||||
>
|
||||
> func GetProfile(c *gin.Context) {
|
||||
> // 直接从上下文中取，无需层层传参
|
||||
> id, _ := c.Get("userID")
|
||||
> name, _ := c.Get("username")
|
||||
> c.JSON(200, gin.H{"id": id, "name": name})
|
||||
> }
|
||||
> ```
|
||||
|
||||
#### 第 18 题
|
||||
|
||||
【单选题】在Gin框架中，如何使用JWT验证中间件?（5分）
|
||||
|
||||
A. 通过router组添加中间件进行验证
|
||||
|
||||
B. 使用静态文件服务
|
||||
|
||||
C. 直接在handler函数中编写JWT验证代码
|
||||
|
||||
D. 使用外部服务进行验证
|
||||
|
||||
**正确答案：** A
|
||||
|
||||
**作答答案：** A
|
||||
|
||||
> [!code Go] JWT 中间件实战模板
|
||||
>
|
||||
> ```go
|
||||
> func JWTAuth() gin.HandlerFunc {
|
||||
> return func(c *gin.Context) {
|
||||
> tokenStr := c.GetHeader("Authorization")
|
||||
> claims, err := parseJWT(tokenStr)
|
||||
> if err != nil {
|
||||
> c.AbortWithStatusJSON(401, gin.H{"error": "无效令牌"})
|
||||
> return
|
||||
> }
|
||||
> c.Set("userID", claims.UserID) // 存入上下文供后续使用
|
||||
> c.Next()
|
||||
> }
|
||||
> }
|
||||
>
|
||||
> // 使用：只对需要认证的路由组生效
|
||||
> admin := r.Group("/admin")
|
||||
> admin.Use(JWTAuth())
|
||||
> {
|
||||
> admin.GET("/users", listUsers)
|
||||
> }
|
||||
> ```
|
||||
|
||||
#### 第 20 题
|
||||
|
||||
【单选题】在Gin框架中，gin.Context 是出现频率最高的参数。它的核心作用是什么？（5分）
|
||||
|
||||
A. 仅仅用于连接数据库的上下文
|
||||
|
||||
B. 专门用来渲染HTML模板的对象
|
||||
|
||||
C. 封装了HTTP的请求(Request)和响应(ResponseWriter)，并在中间件之间传递数据
|
||||
|
||||
D. 用于启动Gin的底层HTTP服务器
|
||||
|
||||
**正确答案：** C
|
||||
|
||||
**作答答案：** C
|
||||
|
||||
> [!note] gin.Context 一图看懂
|
||||
>
|
||||
> ```mermaid
|
||||
> graph TD
|
||||
> A["gin.Context"] --> B["Request 读取<br/>Query/Header/Body"]
|
||||
> A --> C["Response 写入<br/>JSON/String/File"]
|
||||
> A --> D["中间件通信<br/>c.Set / c.Get / c.Next"]
|
||||
> A --> E["生命周期管理<br/>Abort / Deadline"]
|
||||
> ```
|
||||
>
|
||||
> Context 贯穿整个请求生命周期——从接收到响应，它是最核心的桥梁。
|
||||
|
||||
#### 第 27 题
|
||||
|
||||
【单选题】后端处理完逻辑后，想给前端返回一个标准的JSON格式响应（包含状态码200），以下哪句代码是正确的？（5分）
|
||||
|
||||
A. c.String(200, "{\"status\": \"success\"}")
|
||||
|
||||
B. c.JSON(http.StatusOK, gin.H{"message": "success", "data": myData})
|
||||
|
||||
C. c.XML(200, myData)
|
||||
|
||||
D. c.HTML(http.StatusOK, "index.html", nil)
|
||||
|
||||
**正确答案：** B
|
||||
|
||||
**作答答案：** B
|
||||
|
||||
> [!code Go] Gin 响应方法一览
|
||||
>
|
||||
> | 方法 | 适用场景 | Content-Type |
|
||||
> |------|---------|-------------|
|
||||
> | `c.JSON()` | JSON 响应 | application/json |
|
||||
> | `c.String()` | 纯文本 | text/plain |
|
||||
> | `c.XML()` | XML 响应 | application/xml |
|
||||
> | `c.Data()` | 自定义类型 | 可指定任意类型 |
|
||||
> | `c.File()` | 下载文件 | 自动推断 |
|
||||
|
||||
---
|
||||
|
||||
### 四、Cookie、Session 与 JWT 认证
|
||||
|
||||
> [!abstract] 本节覆盖：第 7、9、10、11、21 题
|
||||
>
|
||||
> 这三种方案解决了同一个问题——在**无状态**的 HTTP 上建立**有状态**的会话。各有优劣，适用于不同场景。
|
||||
|
||||
#### 第 7 题
|
||||
|
||||
【单选题】在使用 Gin 设置 Cookie 时，为了防止前端恶意脚本通过 JavaScript 读取到包含用户登录凭证的敏感 Cookie，你应该将哪个参数设置为什么值？（5分）
|
||||
|
||||
httpOnly 是防御 XSS 攻击的利器。当它设为 true 时，浏览器会把这个 Cookie 藏好，只有在向后端发送 HTTP 请求时才会默默带上，前端的任何 JS 代码都无权读取。顺便提一下，secure 也很重要，它表示该 Cookie 只能在 HTTPS 加密连接下传输，用来防止网络中间人窃听。
|
||||
|
||||
A. maxAge 设置为 0
|
||||
|
||||
B. secure 设置为 true
|
||||
|
||||
C. httpOnly 设置为 true
|
||||
|
||||
D. domain 设置为 "localhost"
|
||||
|
||||
**正确答案：** C
|
||||
|
||||
**作答答案：** C
|
||||
|
||||
> [!tip] Cookie 安全属性对照表
|
||||
>
|
||||
> | 属性 | 作用 | 推荐生产环境值 |
|
||||
> |------|------|---------------|
|
||||
> | `HttpOnly` | JS 无法读取，防 XSS | `true` |
|
||||
> | `Secure` | 仅 HTTPS 传输，防抓包 | `true` |
|
||||
> | `SameSite` | 防 CSRF，限制第三方携带 | `Strict` 或 `Lax` |
|
||||
> | `Max-Age` | 有效期（秒），0=删除 | 按需设置 |
|
||||
|
||||
#### 第 9 题
|
||||
|
||||
【单选题】关于 Gin 框架中 Session 的运用，以下说法正确的是？（5分）
|
||||
|
||||
Session 的本质是服务器在后端存储了用户状态，只把一个无意义的、随机的 SessionID 通过 Cookie 发给前端保存。Gin 核心库为了保持轻量，并没有内置 Session，推荐使用第三方中间件。
|
||||
|
||||
A. Gin 官方核心库自带了完善的 Session 管理器，无需引入第三方包。
|
||||
|
||||
B. Session 数据默认以明文形式保存在客户端的浏览器中。
|
||||
|
||||
C. Session 的本质是服务器在后端存储用户状态，只把 SessionID 发给前端。
|
||||
|
||||
D. 只要用户关闭浏览器页面，服务器端的 Session 数据就会被自动删除。
|
||||
|
||||
**正确答案：** C
|
||||
|
||||
**作答答案：** C
|
||||
|
||||
#### 第 10 题
|
||||
|
||||
【单选题】JWT 解决了传统 Session 架构的什么核心痛点？（5分）
|
||||
|
||||
JWT 是"无状态"的，服务端不需要存储会话记录就能验证其有效性，从而解决了传统 Session 在服务器集群环境下的共享与同步问题。
|
||||
|
||||
A. JWT 对用户密码进行了极强的加密，即便被黑客拦截也绝对安全。
|
||||
|
||||
B. 传统 Session 强依赖于服务端内存或集中存储，JWT 是"无状态"的。
|
||||
|
||||
C. JWT 生成的字符串非常短，比传统的 SessionID 更省网络带宽。
|
||||
|
||||
D. JWT 只能在 Go 语言和前端之间解析，跨语言安全性极高。
|
||||
|
||||
**正确答案：** B
|
||||
|
||||
**作答答案：** B
|
||||
|
||||
#### 第 11 题
|
||||
|
||||
【单选题】当中间件成功解析并验证了前端请求头中的 JWT 令牌后，最佳的代码实践是？（5分）
|
||||
|
||||
中间件是查票员，查验完 JWT 后，通过 c.Set() 把乘客信息存储在当前 HTTP 请求的生命周期上下文中，后续函数可以安全、隔离地拿到用户信息。
|
||||
|
||||
A. 将解析出的用户 ID 保存到全局变量中。
|
||||
|
||||
B. 使用 c.Redirect 将请求重定向，并在 URL 参数里带上用户 ID。
|
||||
|
||||
C. 使用 c.Set("userID", id) 将用户信息存储在上下文中。
|
||||
|
||||
D. 将用户信息打包成 JSON 写回到响应体中，结束请求。
|
||||
|
||||
**正确答案：** C
|
||||
|
||||
**作答答案：** C
|
||||
|
||||
#### 第 21 题
|
||||
|
||||
【单选题】当用户首次访问网站时，服务器通常会在HTTP响应中使用哪个字段来向客户端存储session ID？（5分）
|
||||
|
||||
A. Cache-Control
|
||||
|
||||
B. Set-Cookie
|
||||
|
||||
C. Content-Length
|
||||
|
||||
D. User-Agent
|
||||
|
||||
**正确答案：** B
|
||||
|
||||
**作答答案：** B
|
||||
|
||||
> [!summary] 认证方案横向对比
|
||||
>
|
||||
> | 维度 | Session (Cookie) | JWT |
|
||||
> |------|-----------------|-----|
|
||||
> | 存储位置 | 服务端（内存/Redis） | 客户端（自行保管） |
|
||||
> | 服务端压力 | 需维护会话，集群需共享 | 无状态，天然分布式友好 |
|
||||
> | 主动注销 | 可从服务端删除 ✅ | 需黑名单/缩短有效期 ⚠️ |
|
||||
> | token 大小 | Cookie 仅传 SessionID（很小） | JWT 本身较长（含 payload） |
|
||||
> | 适用场景 | 后台管理系统、需要频繁踢人 | 移动端 API、微服务、SSO |
|
||||
|
||||
---
|
||||
|
||||
### 五、CORS 跨域
|
||||
|
||||
> [!abstract] 本节覆盖：第 22~26 题
|
||||
>
|
||||
> 跨域是现代全栈开发的"必修课"。理解同源策略、预检请求和各类解决方案，才能游刃有余地应对生产环境。
|
||||
|
||||
#### 第 22 题
|
||||
|
||||
【单选题】当你的项目正式上线：前端部署在 www.myweb.com，Go 后端 API 部署在 api.myweb.com，此时前端又碰到了跨域问题。生产环境下，业界最标准、最推荐的解决方式是什么？（5分）
|
||||
|
||||
A. 在 Nginx 配置中开启反向代理，让前端和后端走同一个域名，彻底消灭跨域。或者在 Go 后端通过代码严格配置 CORS 中间件，允许指定域名的访问。
|
||||
|
||||
B. 要求所有用户在浏览器中安装一个允许跨域的插件。
|
||||
|
||||
C. 把 Vue/React 前端代码编译进 Go 语言的二进制文件里，打包成一个单体服务，从而避免跨域。
|
||||
|
||||
D. 在前端代码中使用 JSONP 的方式来绕过浏览器的同源策略。
|
||||
|
||||
**正确答案：** A
|
||||
|
||||
**作答答案：** A
|
||||
|
||||
#### 第 23 题
|
||||
|
||||
【单选题】当我们的全栈项目要部署到生产环境时，通常会在最外层挡一个 Nginx，并将外部请求"反向代理"给内部的 Go 应用程序。为什么要多此一举，而不是直接让 Go 监听 80/443 端口对外提供服务？（5分）
|
||||
|
||||
A. 因为 Go 语言标准库的 net/http 性能太差，无法承受高并发，必须靠 Nginx 提速。
|
||||
|
||||
B. 因为 Go 程序无法处理 HTTPS 证书的加密解密。
|
||||
|
||||
C. Nginx 专精于静态文件的高效分发，并且能够作为统一入口隐藏后端真实 IP，还能轻松实现请求路由分发、负载均衡和限流，极大提升了整体架构的健壮性和安全性。
|
||||
|
||||
D. 这是操作系统的强制要求，所有的 Web 流量必须先经过 Nginx 才能到达用户态程序。
|
||||
|
||||
**正确答案：** C
|
||||
|
||||
**作答答案：** C
|
||||
|
||||
#### 第 24 题
|
||||
|
||||
【单选题】当你在前端用 axios 发送一个携带了自定义请求头的 POST 请求时，浏览器实际上发了两次请求。这个 OPTIONS 请求是做什么的？（5分）
|
||||
|
||||
A. 它是用来试探后端服务器是否死机的心跳检测。
|
||||
|
||||
B. 这是浏览器的 CORS"预检请求 (Preflight)"。因为带有自定义头或非普通类型的请求属于"复杂请求"，浏览器必须先发个 OPTIONS 问问后端："我带了特殊的头，你可以接受吗？"
|
||||
|
||||
C. 这是 axios 库本身的 bug 导致的重复请求。
|
||||
|
||||
D. 它是用来提前把数据进行加密的握手请求。
|
||||
|
||||
**正确答案：** B
|
||||
|
||||
**作答答案：** B
|
||||
|
||||
#### 第 25 题
|
||||
|
||||
【单选题】在前端开发阶段，我们通常会在 vite.config.js 或 vue.config.js 中配置 proxy 代理来解决跨域问题。这个 Proxy 底层的运作逻辑是什么？（5分）
|
||||
|
||||
A. 它修改了浏览器的安全设置，让浏览器临时关闭了同源策略。
|
||||
|
||||
B. 它修改了前端发出的 HTTP 请求的 Origin，伪装成和后端同源。
|
||||
|
||||
C. 前端代码实际上把请求发给了 Vite 自带的本地 Node.js 开发服务器，开发服务器再把请求转发给真正的 Go 后端，最后把结果原样返回给前端。
|
||||
|
||||
D. 它自动为后端的 Go 代码注入了处理跨域的中间件。
|
||||
|
||||
**正确答案：** C
|
||||
|
||||
**作答答案：** C
|
||||
|
||||
#### 第 26 题
|
||||
|
||||
【单选题】前后端分离开发时，前端调用后端经常会遇到可怕的 CORS 报错。导致跨域报错的根本原因是什么？它为了解决什么痛点而存在？（5分）
|
||||
|
||||
A. 因为 HTTP 协议不允许不同端口之间通信，这是底层网络协议的限制。
|
||||
|
||||
B. 因为后端的 Go 代码默认开启了防火墙，拦截了来自其他端口的请求。
|
||||
|
||||
C. 这是浏览器的"同源策略 (Same-Origin Policy)"导致的，为了防止恶意网站窃取用户的敏感数据（如 Cookie），浏览器强制拦截了跨域的响应。
|
||||
|
||||
D. 因为前端框架（如 Vue/React）的安全机制，阻止了发起非同源的请求。
|
||||
|
||||
**正确答案：** C
|
||||
|
||||
**作答答案：** C
|
||||
|
||||
> [!tip] 跨域三大解决方案全景图
|
||||
>
|
||||
> ```mermaid
|
||||
> graph LR
|
||||
> A["跨域问题"] --> B["开发环境"]
|
||||
> A --> C["生产环境"]
|
||||
> B --> B1["Vite Proxy<br/>Node 中转"]
|
||||
> C --> C1["Nginx 反向代理<br/>同域名免跨域"]
|
||||
> C --> C2["CORS 中间件<br/>服务端放白名单"]
|
||||
> ```
|
||||
>
|
||||
> **Go 后端 CORS 中间件示例：**
|
||||
>
|
||||
> ```go
|
||||
> import "github.com/gin-contrib/cors"
|
||||
>
|
||||
> r := gin.New()
|
||||
> r.Use(cors.New(cors.Config{
|
||||
> AllowOrigins: []string{"https://www.myweb.com"},
|
||||
> AllowMethods: []string{"GET", "POST", "PUT", "DELETE", "OPTIONS"},
|
||||
> AllowHeaders: []string{"Origin", "Content-Type", "Authorization"},
|
||||
> AllowCredentials: true,
|
||||
> MaxAge: 12 * time.Hour,
|
||||
> }))
|
||||
> ```
|
||||
|
||||
---
|
||||
|
||||
### 六、响应与状态码
|
||||
|
||||
> [!abstract] 本节覆盖：第 28、29 题（续）
|
||||
>
|
||||
> 正确使用 HTTP 状态码是专业后端的基本素养。
|
||||
|
||||
#### 第 28 题
|
||||
|
||||
【单选题】前端向你的Go后端发送了一个请求，但忘了带上认证Token。作为标准化的后端，你应该返回哪个状态码来明确告知他"你没有权限/未认证"？（5分）
|
||||
|
||||
A. 400 Bad Request
|
||||
|
||||
B. 401 Unauthorized
|
||||
|
||||
C. 404 Not Found
|
||||
|
||||
D. 500 Internal Server Error
|
||||
|
||||
**正确答案：** B
|
||||
|
||||
**作答答案：** B
|
||||
|
||||
> [!note] 常用 HTTP 状态码速查
|
||||
>
|
||||
> | 状态码 | 含义 | 何时使用 |
|
||||
> |--------|------|---------|
|
||||
> | **200** | OK | 请求成功 |
|
||||
> | **201** | Created | 资源创建成功 |
|
||||
> | **301** | Moved Permanently | 永久重定向 |
|
||||
> | **304** | Not Modified | 资源未变化（缓存） |
|
||||
> | **400** | Bad Request | 请求参数错误 |
|
||||
> | **401** | Unauthorized | 未认证/Token失效 |
|
||||
> | **403** | Forbidden | 已认证但无权限 |
|
||||
> | **404** | Not Found | 资源不存在 |
|
||||
> | **429** | Too Many Requests | 触发限流 |
|
||||
> | **500** | Internal Server Error | 服务端内部错误 |
|
||||
|
||||
---
|
||||
|
||||
### 七、Git 版本控制
|
||||
|
||||
#### 第 30 题
|
||||
|
||||
【单选题】在Git中，如何临时保存当前工作进度以便切换到其他分支进行工作？（5分）
|
||||
|
||||
A. 使用 git stash apply 命令
|
||||
|
||||
B. 使用 git commit 命令
|
||||
|
||||
C. 使用 git stash 命令
|
||||
|
||||
D. 使用 git merge 命令
|
||||
|
||||
**正确答案：** C
|
||||
|
||||
**作答答案：** C
|
||||
|
||||
> [!code Bash] git stash 常用命令
|
||||
>
|
||||
> ```bash
|
||||
> git stash save "WIP: 修复bug" # 保存当前改动
|
||||
> git stash list # 查看保存列表
|
||||
> git stash pop stash@{0} # 恢复并删除栈顶记录
|
||||
> git stash apply stash@{0} # 恢复但不删除（保留记录）
|
||||
> git stash drop stash@{0} # 删除指定记录
|
||||
> git stash drop # 删除最近一条（快捷写法）
|
||||
> ```
|
||||
|
||||
---
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[hhs/EXAM/]]
|
||||
- [[Go/Gin框架/中间件]]
|
||||
- [[Web/CORS跨域]]
|
||||
- [[Web/JWT认证]]
|
||||
@@ -0,0 +1,804 @@
|
||||
---
|
||||
tags: []
|
||||
create time: 2026-05-14 10:30
|
||||
---
|
||||
|
||||
# 金山考试 - 武科大 - 第四次课（React 核心）
|
||||
|
||||
## 概述
|
||||
|
||||
本次考试围绕 **React 核心概念与性能优化**，涵盖以下知识点：
|
||||
|
||||
- useState / useEffect / useMemo / useCallback 等 Hooks 的使用与陷阱
|
||||
- React.memo 与组件渲染行为控制
|
||||
- 单向数据流与组件通信模式（父子/兄弟/跨级）
|
||||
- Context API 的作用域与注意事项
|
||||
- React Router 路由机制（ BrowserRouter、Route、动态参数）
|
||||
- Redux 状态管理（Action、Reducer、中间件）
|
||||
- Axios 拦截器封装最佳实践
|
||||
- 大列表渲染与 Vite 打包性能优化
|
||||
- 前端监控埋点方案对比（GIF vs AJAX）
|
||||
|
||||
## 我的错题
|
||||
|
||||
> [!FAIL] ❌ 错题记录
|
||||
> 以下题目作答错误，标注解题思路与关键误区。
|
||||
|
||||
### Q14 — 兄弟组件通信
|
||||
|
||||
| 项目 | 内容 |
|
||||
|------|------|
|
||||
| 官方答案 | C（Context） |
|
||||
| 你的答案 | D（Redux） |
|
||||
|
||||
> [!NOTE] 💡 为什么选 Context？
|
||||
> Redux 属于**全局状态管理库**，适用于跨多个不相关组件共享复杂状态的**大型项目**。而本题限定为「**兄弟组件之间的简单通信**」，使用 Context 更轻量、更符合场景定位——通过一个公共父组件创建 Context，两个兄弟组件分别消费即可，无需引入额外依赖。
|
||||
|
||||
### Q29 — React.memo + 对象 prop
|
||||
|
||||
| 项目 | 内容 |
|
||||
|------|------|
|
||||
| 官方答案 | D（父组件每次创建新对象引用） |
|
||||
| 你的答案 | （正确 ✅） |
|
||||
|
||||
> [!NOTE] ℹ️ 标记已纠正
|
||||
> 此题已掌握，保留备忘。React.memo 基于**浅比较**（shallow equal），只要 prop 引用地址变了就会重新渲染。**每次渲染都 new 一个对象**会导致引用始终不同，`useMemo` 可以缓存引用解决这个问题。
|
||||
|
||||
---
|
||||
|
||||
## 武科大 - 第四次课
|
||||
|
||||
### 一、单选题
|
||||
|
||||
#### 1. useState 闭包陷阱
|
||||
|
||||
【单选题】点击按钮后，以下 React 代码，console 的输出和按钮中的展示分别是什么？（2分）
|
||||
|
||||
```js
|
||||
function Counter() {
|
||||
const [count, setCount] useState(0);
|
||||
|
||||
const handleClick = () => {
|
||||
setCount(count + 1);
|
||||
setCount(count + 1);
|
||||
setCount(count + 1);
|
||||
console.log(count);
|
||||
};
|
||||
|
||||
return <button onClick={handleClick}>{count}</button>;
|
||||
}
|
||||
```
|
||||
|
||||
A. 3, 3
|
||||
B. 0, 1
|
||||
C. 0, 3
|
||||
D. 3, 1
|
||||
|
||||
**正确答案：** B
|
||||
**作答答案：** C
|
||||
|
||||
> [!TIP] 🔑 核心考点
|
||||
> `setCount(count + 1)` 三次调用中，`count` 是**同一闭包快照值 0**，所以实际等价于 `setCount(1)` 执行三次。但 React 会**批量合并**同一次事件中的状态更新，最终只渲染一次 → count = 1。
|
||||
>
|
||||
> ⚠️ 若用函数式更新 `setCount(prev => prev + 1)` 三次，则结果为 3。
|
||||
|
||||
---
|
||||
|
||||
#### 2. React.memo + 对象 prop
|
||||
|
||||
【单选题】考虑一个使用 `React.memo` 包装的 `Child` 组件。如果父组件传递一个对象 `prop`，以下哪种方法可以确保 `Child` 组件在父组件重新渲染时不会不必要地重新渲染？
|
||||
|
||||
A. 将 `Child` 组件从 `React.memo` 中移除
|
||||
B. 在 `Child` 组件内部使用 `useEffect` 来比较 `prop`
|
||||
C. 将对象 `prop` 传递给 `useMemo`，并将其作为 `Child` 的 `prop`
|
||||
D. 将对象 `prop` 的所有属性分别作为独立的 `prop` 传递给 `Child`
|
||||
|
||||
**正确答案：** C
|
||||
**作答答案：** C ✅
|
||||
|
||||
---
|
||||
|
||||
#### 3. 父组件状态更新 → 子组件渲染
|
||||
|
||||
【单选题】在 React 中，当父组件状态更新时子组件的渲染行为是怎样的？（2分）
|
||||
|
||||
A. 子组件不会重新渲染，除非子组件自身的状态或属性变化
|
||||
B. 子组件会随父组件的重新渲染而无条件重新渲染
|
||||
C. 子组件仅在其接收的 props 发生变化时重新渲染
|
||||
D. 父组件的渲染不影响子组件
|
||||
|
||||
**正确答案：** B
|
||||
**作答答案：** B ✅
|
||||
|
||||
> [!NOTE] ℹ️ 深入理解
|
||||
> 父组件 re-render 会**默认触发所有子组件** re-render，无论 props 是否改变。如需跳过，可使用 `React.memo`、`useMemo`、`useCallback` 等手段进行优化。
|
||||
|
||||
---
|
||||
|
||||
#### 4. useMemo vs useCallback
|
||||
|
||||
【单选题】React 中 useMemo 和 useCallback 的主要区别是什么？（2分）
|
||||
|
||||
A. useMemo 返回一个 memoized 值，useCallback 返回一个 memoized 函数
|
||||
B. useMemo 和 useCallback 效果完全一样
|
||||
C. useCallback 可以依赖多个变量，而 useMemo 只能依赖一个变量
|
||||
D. 没有区别，两者在 React 中可以互换使用
|
||||
|
||||
**正确答案：** A
|
||||
**作答答案：** A ✅
|
||||
|
||||
---
|
||||
|
||||
#### 5. useCallback 的主要用途
|
||||
|
||||
【单选题】在 React 中 useCallback 的主要用途是什么？（2分）
|
||||
|
||||
A. 用于在组件之间传递状态
|
||||
B. 用于避免组件中的函数在每次渲染时都重新创建
|
||||
C. 用于直接修改组件的 state
|
||||
D. 用于数据的结构化管理
|
||||
|
||||
**正确答案：** B
|
||||
**作答答案：** B ✅
|
||||
|
||||
---
|
||||
|
||||
#### 6. React 性能优化手段
|
||||
|
||||
【单选题】下面哪些是 React 性能优化的手段？（2分）
|
||||
|
||||
```js
|
||||
// 方案1 — useMemo 缓存计算结果
|
||||
const memoizedValue = useMemo(() => computeValue(a), [a]);
|
||||
|
||||
// 方案2 — useCallback 缓存函数引用
|
||||
const handleClick = () => { /*...*/ };
|
||||
const memoizedHandle = useCallback(handleClick, []);
|
||||
```
|
||||
|
||||
A. 仅方案1
|
||||
B. 仅方案2
|
||||
C. 两者都需要
|
||||
D. 都不需要
|
||||
|
||||
**正确答案：** C
|
||||
**作答答案：** C ✅
|
||||
|
||||
> [!TIP] 🔑 何时使用？
|
||||
> - `useMemo`：适合**昂贵计算**的结果缓存
|
||||
> - `useCallback`：适合**传给子组件作为 prop 的函数**，配合 `React.memo` 防止子组件无谓重渲染
|
||||
|
||||
---
|
||||
|
||||
#### 7. 单项数据流
|
||||
|
||||
【单选题】在 React 中，以下关于单项数据流的描述，哪个是正确的？（3分）
|
||||
|
||||
A. 数据可以在组件间随意双向流动
|
||||
B. 数据只能从父组件流向子组件，子组件不能直接修改父组件的数据
|
||||
C. 数据从子组件流向父组件，父组件接收数据后再分发给其他子组件
|
||||
D. 数据在同级组件间可以自由流动
|
||||
|
||||
**正确答案：** B
|
||||
**作答答案：** B ✅
|
||||
|
||||
---
|
||||
|
||||
#### 8. React Router 核心原理
|
||||
|
||||
【单选题】React Router 的核心原理是基于以下哪种机制来实现路由匹配和渲染的？（2分）
|
||||
|
||||
A. 事件监听
|
||||
B. 虚拟 DOM 比对
|
||||
C. URL 变化监听和组件映射
|
||||
D. 状态管理
|
||||
|
||||
**正确答案：** C
|
||||
**作答答案：** C ✅
|
||||
|
||||
---
|
||||
|
||||
#### 9. 路由根组件
|
||||
|
||||
【单选题】在 React 中使用路由时，用于包裹整个应用路由组件的根组件是？（3分）
|
||||
|
||||
A. Route
|
||||
B. BrowserRouter
|
||||
C. Switch
|
||||
D. Link
|
||||
|
||||
**正确答案：** B
|
||||
**作答答案：** B ✅
|
||||
|
||||
> [!NOTE] ℹ️ 注意版本差异
|
||||
> React Router v5 用 `BrowserRouter` + `Switch`；v6 改用 `BrowserRouter` + `<Routes>` + `<Route>`。Switch 在 v6 已被废弃。
|
||||
|
||||
---
|
||||
|
||||
#### 10. React Context 错误说法
|
||||
|
||||
【单选题】关于 React Context 的说法，错误的是？（3分）
|
||||
|
||||
A. 适合跨层级传递 props（避免 props drilling）
|
||||
B. 每次 Context 值变化时，所有消费组件都会重渲染
|
||||
C. 可以通过 useContext Hook 或 Consumer 组件使用
|
||||
D. 不能与类组件一起使用
|
||||
|
||||
**正确答案：** D
|
||||
**作答答案：** D ✅
|
||||
|
||||
> [!TIP] 🔑 Context 常见误区
|
||||
> Context 本身**不优化性能**——值变化时所有 consumer 都会重渲染。应结合 `useMemo` 分割 context 或将消费逻辑抽取到自定义 Hook 中以缩小更新范围。
|
||||
|
||||
---
|
||||
|
||||
#### 11. Fragment 主要作用
|
||||
|
||||
【单选题】在 React 中，Fragment 的主要作用是？（3分）
|
||||
|
||||
A. 为组件添加额外的 DOM 节点
|
||||
B. 替代 div 减少冗余 DOM 层级
|
||||
C. 优化组件的渲染性能
|
||||
D. 包裹多个子元素且不添加额外节点
|
||||
|
||||
**正确答案：** D
|
||||
**作答答案：** D ✅
|
||||
|
||||
> [!NOTE] ℹ️ 两种写法
|
||||
> - 完整语法：`<React.Fragment>` 或 `<Fragment>`
|
||||
> - 简写语法：`<>...</>` （不支持 key 属性）
|
||||
|
||||
---
|
||||
|
||||
#### 12. 按需加载
|
||||
|
||||
【单选题】React Router 中如何实现按需加载？（3分）
|
||||
|
||||
A. 使用 React.lazy 和 React.Suspense 实现
|
||||
B. 使用 webpack 的 Code Splitting 实现
|
||||
C. 使用 React Router 自带的按需加载功能实现
|
||||
D. 使用 ES6 的 import() 函数实现
|
||||
|
||||
**正确答案：** A
|
||||
**作答答案：** A ✅
|
||||
|
||||
---
|
||||
|
||||
#### 13. 父向子传数据
|
||||
|
||||
【单选题】在 React 中，如何实现父组件向子组件传递数据？（3分）
|
||||
|
||||
A. 使用 state 属性
|
||||
B. 使用 props 属性
|
||||
C. 使用 context 属性
|
||||
D. 使用 ref 属性
|
||||
|
||||
**正确答案：** B
|
||||
**作答答案：** B ✅
|
||||
|
||||
---
|
||||
|
||||
#### 14. 兄弟组件通信
|
||||
|
||||
【单选题】在 React 中，实现兄弟组件之间的通信，相对来说下面哪个比较合适？（3分）
|
||||
|
||||
A. 使用 props
|
||||
B. 使用 state
|
||||
C. 使用 context
|
||||
D. 使用 Redux
|
||||
|
||||
**正确答案：** C
|
||||
**作答答案：** D
|
||||
|
||||
---
|
||||
|
||||
#### 15. 子传父
|
||||
|
||||
【单选题】子传父在 React 中通常通过什么实现？（3分）
|
||||
|
||||
A. 回调函数
|
||||
B. 事件
|
||||
C. 状态提升
|
||||
D. 上升至共同的父组件
|
||||
|
||||
**正确答案：** A
|
||||
**作答答案：** A ✅
|
||||
|
||||
---
|
||||
|
||||
#### 16. React.createElement
|
||||
|
||||
【单选题】React.createElement 用于做什么？（3分）
|
||||
|
||||
A. 创建类组件实例
|
||||
B. 创建函数组件实例
|
||||
C. 创建 DOM 元素
|
||||
D. 创建 React 元素
|
||||
|
||||
**正确答案：** D
|
||||
**作答答案：** D ✅
|
||||
|
||||
---
|
||||
|
||||
#### 17. 获取 DOM 引用
|
||||
|
||||
【单选题】如果需要在 React 组件中保持对 DOM 元素的引用，应该使用哪个钩子？（3分）
|
||||
|
||||
A. useState
|
||||
B. useEffect
|
||||
C. useRef
|
||||
D. useReducer
|
||||
|
||||
**正确答案：** C
|
||||
**作答答案：** C ✅
|
||||
|
||||
---
|
||||
|
||||
#### 18. useState 返回值
|
||||
|
||||
【单选题】在 React 中，useState 钩子的返回值包含什么？（3分）
|
||||
|
||||
A. 一个包含状态和更新状态的函数
|
||||
B. 一个包含副作用和清理副作用的函数
|
||||
C. 一个包含 DOM 引用和更新 DOM 的方法
|
||||
D. 一个包含生命周期方法的对象
|
||||
|
||||
**正确答案：** A
|
||||
**作答答案：** A ✅
|
||||
|
||||
> [!NOTE] ℹ️ 解构方式
|
||||
> ```js
|
||||
> const [count, setCount] = useState(0);
|
||||
> // ↑ 更新函数（非 setter）
|
||||
> // ↑ 当前状态值
|
||||
> ```
|
||||
|
||||
---
|
||||
|
||||
#### 19. useEffect 清除副作用
|
||||
|
||||
【单选题】在 React 中，如何清除 useEffect 钩子中设置的副作用？（3分）
|
||||
|
||||
A. 返回一个函数
|
||||
B. 使用 useRef
|
||||
C. 使用 useState
|
||||
D. 使用 useMemo
|
||||
|
||||
**正确答案：** A
|
||||
**作答答案：** A ✅
|
||||
|
||||
---
|
||||
|
||||
#### 20. useEffect 主要用途
|
||||
|
||||
【单选题】在 React 中，useEffect 钩子的主要用途是什么？（3分）
|
||||
|
||||
A. 声明性地处理组件的副作用
|
||||
B. 声明性地处理组件的样式
|
||||
C. 声明性地处理组件的事件
|
||||
D. 声明性地处理组件的渲染
|
||||
|
||||
**正确答案：** A
|
||||
**作答答案：** A ✅
|
||||
|
||||
---
|
||||
|
||||
#### 21. 动态参数写法
|
||||
|
||||
【单选题】在路由路径中定义动态参数（如用户 ID）的正确写法是？（3分）
|
||||
|
||||
A. `/user?id=123`
|
||||
B. `/user/:id`
|
||||
C. `/user/{id}`
|
||||
D. `/user[id]`
|
||||
|
||||
**正确答案：** B
|
||||
**作答答案：** B ✅
|
||||
|
||||
---
|
||||
|
||||
#### 22. 路由匹配组件
|
||||
|
||||
【单选题】以下哪个组件用于定义路由匹配规则？（3分）
|
||||
|
||||
A. Link
|
||||
B. NavLink
|
||||
C. Route
|
||||
D. Switch
|
||||
|
||||
**正确答案：** C
|
||||
**作答答案：** C ✅
|
||||
|
||||
---
|
||||
|
||||
#### 23. 全局状态管理适用场景
|
||||
|
||||
【单选题】以下哪种场景最适合使用全局状态管理库（如 Redux）？（3分）
|
||||
|
||||
A. 多个不相关组件共享复杂状态
|
||||
B. 单一组件内部状态管理
|
||||
C. 兄弟组件简单数据传递
|
||||
D. 跨页面数据持久化
|
||||
|
||||
**正确答案：** A
|
||||
**作答答案：** A ✅
|
||||
|
||||
> [!TIP] 🔑 选型决策树
|
||||
>
|
||||
> ```mermaid
|
||||
> graph LR
|
||||
> A[需要共享状态?] -->|否| B[用 useState/useRef]
|
||||
> A -->|是| C{是否在同一个组件树中?}
|
||||
> C -->|是| D[父→子 props / 状态提升]
|
||||
> C -->|否| E{涉及组件数量?}
|
||||
> E -->|少且相邻| F[Context]
|
||||
> E -->|多且不相关| G[Redux/Zustand]
|
||||
> ```
|
||||
|
||||
---
|
||||
|
||||
#### 24. Redux reducer
|
||||
|
||||
【单选题】在 React-Redux 中，什么是 reducer？（3分）
|
||||
|
||||
以下哪个描述最准确地解释了 React-Redux 中的 reducer？
|
||||
|
||||
A. reducer 是一个纯函数，它接收一个先前的状态和一个 action，返回一个新的状态
|
||||
B. reducer 是一个对象，它定义了应用程序的状态和行为
|
||||
C. reducer 是一个数组，它包含了应用程序的所有状态
|
||||
D. reducer 是一个类，它封装了应用程序的所有逻辑
|
||||
|
||||
**正确答案：** A
|
||||
**作答答案：** A ✅
|
||||
|
||||
---
|
||||
|
||||
#### 25. Redux action
|
||||
|
||||
【单选题】在 React-Redux 中，什么是 action？（3分）
|
||||
|
||||
以下哪个描述最准确地解释了 React-Redux 中的 action？
|
||||
|
||||
A. action 是一个对象，它描述了发生了什么事件，它包含了 type 和 payload 属性
|
||||
B. action 是一个函数，它定义了应用程序的行为
|
||||
C. action 是一个数组，它包含了应用程序的所有状态
|
||||
D. action 是一个类，它封装了应用程序的所有逻辑
|
||||
|
||||
**正确答案：** A
|
||||
**作答答案：** A ✅
|
||||
|
||||
---
|
||||
|
||||
#### 26. Action 与 Reducer 关系
|
||||
|
||||
【单选题】Redux 中的 action 和 reducer 有什么关系？（3分）
|
||||
|
||||
在 Redux 中，action 和 reducer 是组成状态管理的两个重要概念。请问，action 和 reducer 之间的关系是什么？
|
||||
|
||||
A. action 用于描述应用状态的结构，reducer 用于修改状态
|
||||
B. action 用于存储应用状态的数据，reducer 用于获取状态
|
||||
C. action 用于触发状态修改，reducer 用于响应状态修改
|
||||
D. action 用于监听状态变化，reducer 用于修改状态
|
||||
|
||||
**正确答案：** C
|
||||
**作答答案：** C ✅
|
||||
|
||||
> [!NOTE] ℹ️ Redux 数据流全景
|
||||
>
|
||||
> ```mermaid
|
||||
> flowchart LR
|
||||
> UI["组件发起 dispatch"] -->|Action| STORE["Store"]
|
||||
> STORE -->|派发| REDUCER["Reducer 纯函数"]
|
||||
> REDUCER -->|new State| STORE
|
||||
> STORE -->|订阅更新| UI
|
||||
> ```
|
||||
|
||||
---
|
||||
|
||||
#### 27. Redux 异步操作
|
||||
|
||||
【单选题】在 Redux 中，有时需要进行异步操作，比如发送网络请求。请问，以下哪个中间件可以用来实现异步操作？（3分）
|
||||
|
||||
A. redux-thunk
|
||||
B. redux-saga
|
||||
C. redux-logger
|
||||
D. redux-observable
|
||||
|
||||
**正确答案：** A
|
||||
**作答答案：** A ✅
|
||||
|
||||
> [!TIP] 🔑 常用中间件对比
|
||||
>
|
||||
> | 中间件 | 特点 |
|
||||
> |--------|------|
|
||||
> | redux-thunk | 轻量，返回函数的 action creator，适合简单异步 |
|
||||
> | redux-saga | 基于 Generator，适合复杂异步流程控制 |
|
||||
> | redux-logger | 日志打印，不参与业务逻辑 |
|
||||
> | redux-observable | 基于 RxJS，响应式编程风格 |
|
||||
|
||||
---
|
||||
|
||||
#### 28. Axios 拦截器问题
|
||||
|
||||
【单选题】axios 封装请求拦截器时，以下代码有什么问题？（3分）
|
||||
|
||||
```js
|
||||
import axios from 'axios';
|
||||
|
||||
const instance = axios.create({
|
||||
baseURL: 'https://api.example.com',
|
||||
timeout: 5000
|
||||
});
|
||||
|
||||
// 请求拦截器
|
||||
instance.interceptors.request.use(
|
||||
config => {
|
||||
const token = localStorage.getItem('token');
|
||||
if (token) {
|
||||
config.headers.Authorization = `Bearer ${token}`;
|
||||
}
|
||||
return config;
|
||||
},
|
||||
error => Promise.reject(error)
|
||||
);
|
||||
|
||||
// 响应拦截器
|
||||
instance.interceptors.response.use(
|
||||
response => response.data,
|
||||
error => {
|
||||
if (error.response?.status === 401) {
|
||||
// token过期，跳转登录
|
||||
window.location.href = '/login';
|
||||
}
|
||||
return Promise.reject(error);
|
||||
}
|
||||
);
|
||||
|
||||
export default instance;
|
||||
```
|
||||
|
||||
A. 没有问题，这是标准的 axios 封装
|
||||
B. token 过期时应该先尝试刷新 token
|
||||
C. 直接操作 window.location 会导致 SPA 路由失效
|
||||
D. B 和 C 都对
|
||||
|
||||
**正确答案：** D
|
||||
**作答答案：** D ✅
|
||||
|
||||
> [!TIP] 🔑 最佳实践
|
||||
> - **刷新 Token**：使用 refresh_token 流程重试原请求，而非直接跳登录
|
||||
> - **SPA 导航**：使用 `router.push('/login')` 而非 `window.location.href`，避免整页刷新丢失状态
|
||||
|
||||
---
|
||||
|
||||
#### 29. React.memo + 新对象引用
|
||||
|
||||
【单选题】在使用 `React.memo` 时，如果父组件传递一个对象作为 `prop`，以下哪种情况可能导致子组件仍然不必要的重新渲染？（3分）
|
||||
|
||||
A. 父组件传递的是一个原始类型的值，例如数字
|
||||
B. 父组件传递的是一个使用 `useMemo` 缓存的对象
|
||||
C. 子组件内部的状态发生了变化
|
||||
D. 父组件每次渲染时都创建了一个新的对象
|
||||
|
||||
**正确答案：** D
|
||||
**作答答案：** D ✅
|
||||
|
||||
---
|
||||
|
||||
### 二、多选题
|
||||
|
||||
#### 1. 大数据渲染优化
|
||||
|
||||
【多选题】项目中遇到大量数据渲染导致页面卡顿，以下哪些优化方案有效？（4分）
|
||||
|
||||
```js
|
||||
// 方案A：虚拟滚动
|
||||
<virtual-list
|
||||
:data="list"
|
||||
:item-height="80"
|
||||
:buffer-scale="2"
|
||||
/>
|
||||
|
||||
// 方案B：分页加载
|
||||
const pageSize = 20;
|
||||
const currentPage = ref(1);
|
||||
const displayList = computed(() => {
|
||||
return list.slice(0, currentPage.value * pageSize);
|
||||
});
|
||||
|
||||
// 方案C：时间分片
|
||||
function renderWithTimeSlice(list) {
|
||||
let current = 0;
|
||||
const pageSize = 50;
|
||||
function render() {
|
||||
const fragment = document.createDocumentFragment();
|
||||
const end = Math.min(current + pageSize, list.length);
|
||||
for (let i = current; i < end; i++) {
|
||||
const item = createListItem(list[i]);
|
||||
fragment.appendChild(item);
|
||||
}
|
||||
container.appendChild(fragment);
|
||||
current = end;
|
||||
if (current < list.length) {
|
||||
requestAnimationFrame(render);
|
||||
}
|
||||
}
|
||||
render();
|
||||
}
|
||||
|
||||
// 方案D：Web Worker 处理数据
|
||||
const worker = new Worker('process-data.js');
|
||||
worker.postMessage(rawData);
|
||||
worker.onmessage = (e) => {
|
||||
renderList(e.data);
|
||||
};
|
||||
```
|
||||
|
||||
A. 只渲染可视区域
|
||||
B. 按需加载
|
||||
C. 避免长时间阻塞
|
||||
D. 数据处理放在 Worker
|
||||
|
||||
**正确答案：** ABCD
|
||||
**作答答案：** ABCD ✅
|
||||
|
||||
> [!NOTE] ℹ️ 各方案定位
|
||||
> - **虚拟滚动**：DOM 节点数固定，滚动时复用节点
|
||||
> - **分页加载**：减少一次性渲染量，配合无限滚动体验更佳
|
||||
> - **时间分片**：将任务拆入微任务队列，避免主线程长时间占用
|
||||
> - **Web Worker**：计算密集型任务放后台线程，主线程只管渲染
|
||||
|
||||
---
|
||||
|
||||
#### 2. Vite 打包优化
|
||||
|
||||
【多选题】Vite 项目打包优化时，以下哪些配置是有效的？（4分）
|
||||
|
||||
```js
|
||||
// vite.config.js
|
||||
export default {
|
||||
build: {
|
||||
rollupOptions: {
|
||||
output: {
|
||||
// 配置A：手动分包
|
||||
manualChunks: {
|
||||
'vendor': ['vue', 'vue-router', 'pinia'],
|
||||
'ui': ['element-plus']
|
||||
},
|
||||
// 配置B：第三方库按包名分组
|
||||
manualChunks(id) {
|
||||
if (id.includes('node_modules')) {
|
||||
return id.toString().split('node_modules/')[1].split('/')[0];
|
||||
}
|
||||
}
|
||||
}
|
||||
},
|
||||
// 配置C：启用压缩
|
||||
minify: 'terser',
|
||||
terserOptions: {
|
||||
compress: {
|
||||
drop_console: true,
|
||||
drop_debugger: true
|
||||
}
|
||||
},
|
||||
// 配置D：调整 chunk 大小警告阈值
|
||||
chunkSizeWarningLimit: 2000
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
A. 配置 A 可以有效减少首屏加载时间
|
||||
B. 配置 B 比 A 更灵活，能自动分离第三方库
|
||||
C. 配置 C 能减小包体积，但会增加构建时间
|
||||
D. 配置 D 只是隐藏警告，不能真正优化性能
|
||||
|
||||
**正确答案：** ABCD
|
||||
**作答答案：** ABC
|
||||
|
||||
> [!FAIL] 💔 漏选分析
|
||||
> **配置 D 虽不直接优化性能，但它影响开发体验**——合理设置可避免频繁干扰，让真正的警告突出显示。这是一项工程化最佳实践。建议全选。
|
||||
|
||||
---
|
||||
|
||||
#### 3. 大列表渲染最佳实践
|
||||
|
||||
【多选题】以下性能优化的最佳实践是什么？（4分）
|
||||
|
||||
```js
|
||||
// 场景：大列表渲染
|
||||
const List = ({ items }) => {
|
||||
return (
|
||||
<div>
|
||||
{items.map((item, index) => (
|
||||
<div key={index} onClick={() => handleClick(item)}>
|
||||
{item.name}
|
||||
</div>
|
||||
))}
|
||||
</div>
|
||||
);
|
||||
};
|
||||
```
|
||||
|
||||
A. 使用 item.id 作为 key 而非 index
|
||||
B. 使用虚拟滚动
|
||||
C. 使用 useMemo 包裹 items
|
||||
D. onClick 使用 useCallback
|
||||
|
||||
**正确答案：** ABD
|
||||
**作答答案：** ABD ✅
|
||||
|
||||
> [!TIP] 🔑 为什么不选 C？
|
||||
> `useMemo` 包裹 items 并不能直接优化列表渲染性能——items 来自 props，其变化由父组件决定。关键在于 **key 稳定性**（A）、**渲染策略**（B）和**事件处理器引用稳定**（D）。
|
||||
|
||||
---
|
||||
|
||||
#### 4. useEffect + 键盘事件监听
|
||||
|
||||
【多选题】关于下面代码说法正确的是？（4分）
|
||||
|
||||
```js
|
||||
useEffect(() => {
|
||||
const onKeyDown = (e) => {
|
||||
const userAgent = navigator.userAgent;
|
||||
const isMac = /Macintosh|MacIntel|MacPPC|Mac68K/.test(userAgent);
|
||||
if ((isMac && e.metaKey && e.key.toLowerCase() === 'k') ||
|
||||
(!isMac && e.ctrlKey && e.key.toLowerCase() === 'k')) {
|
||||
e.preventDefault();
|
||||
inputRef.current?.focus();
|
||||
}
|
||||
};
|
||||
window.addEventListener('keydown', onKeyDown);
|
||||
return () => window.removeEventListener('keydown', onKeyDown);
|
||||
}, []);
|
||||
```
|
||||
|
||||
A. 在 Mac 设备上按下 Command+K 键，或在非 Mac 设备上按下 Ctrl+K 键时，让 inputRef 对应的输入框获取焦点
|
||||
B. 该 useEffect 仅在组件挂载时执行一次，因为其依赖数组为空
|
||||
C. 清理函数会在组件卸载时执行，用于移除添加的 keydown 事件监听，避免内存泄漏
|
||||
D. 清理函数的主要作用是阻止键盘事件的默认行为
|
||||
|
||||
**正确答案：** ABC
|
||||
**作答答案：** ABCD
|
||||
|
||||
> [!FAIL] 💔 易错点
|
||||
> **D 是错误的**：`e.preventDefault()` 阻止的是浏览器默认行为（如 Cmd+K 的搜索框聚焦），而清理函数 `removeEventListener` 的作用是**移除事件监听器本身**，二者职责完全不同。
|
||||
|
||||
---
|
||||
|
||||
#### 5. GIF 埋点 vs AJAX
|
||||
|
||||
【多选题】相比较 AJAX，有些公司前端监控都喜欢用 GIF 做埋点上报，以下哪些是 GIF 的优势？（4分）
|
||||
|
||||
```js
|
||||
// GIF 方案
|
||||
const report = (data) => {
|
||||
const img = new Image();
|
||||
img.src = `https://log.example.com/track.gif?data=${encodeURIComponent(JSON.stringify(data))}`;
|
||||
};
|
||||
|
||||
// Ajax 方案
|
||||
const report = (data) => {
|
||||
fetch('https://log.example.com/track', {
|
||||
method: 'POST',
|
||||
body: JSON.stringify(data)
|
||||
});
|
||||
};
|
||||
```
|
||||
|
||||
A. GIF 请求不需要等待响应，发送即走
|
||||
B. GIF 可以跨域，不受 CORS 限制
|
||||
C. 页面卸载时 GIF 请求不会被取消
|
||||
D. GIF 体积最小（1x1 像素）
|
||||
|
||||
**正确答案：** ABD
|
||||
**作答答案：** ABD ✅
|
||||
|
||||
> [!NOTE] ℹ️ 为什么不用 C？
|
||||
> 页面卸载（unload）时，`navigator.sendBeacon()` 可以保证请求发送，但普通 `<img>` 请求**同样会被取消**，因为浏览器不再维护连接。GIF 的优势在于**零 CORS 限制**（资源加载不走 XHR 同源策略）和**极简体积**。
|
||||
|
||||
---
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[hhs/EXAM/Week03]]（推测：前三次课相关考题）
|
||||
- [[hhs/EXAM/README]]（考试文档索引）
|
||||
+1228
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,601 @@
|
||||
在分布式系统中，为了解决单点问题，通常会把redis服务部署到多个服务器上，满足故障恢复和[负载均衡](https://cloud.tencent.com/product/clb?from_column=20065&from=20065)等请求。
|
||||
|
||||
所谓的单点问题，就是某个服务器程序，只有一个节点（只有一个[物理服务器](https://cloud.tencent.com/product/cbm?from_column=20065&from=20065)，来部署这个服务器程序）。
|
||||
|
||||
存在的问题：
|
||||
|
||||
- 可用性问题：如果这个机器挂了，那么部署的redis服务就挂了，服务就中断了。
|
||||
- 性能/支持的并发量有限：毕竟一台主机的硬件资源（比如CPU，硬盘，网络带宽等等）是有限的，一个请求就要消耗一定量的硬件资源。一旦并发量太高，如果请求超过主机所能提供这些资源，那么可能就会出现异常，甚至主机直接宕机了。
|
||||
|
||||
在分布式系统中，往往希望有多个服务器来部署redis服务，从而构成一个redis集群，此时就可以让这个集群给分布式系统中的其他服务，提供更稳定/更高效的数据存储功能 。
|
||||
|
||||
主要存在以下几种部署方式：
|
||||
|
||||
- 主从模式
|
||||
- 主从+哨兵模式
|
||||
- 集群模式
|
||||
|
||||
### 一，主从复制
|
||||
|
||||
##### 1，配置主从复制
|
||||
|
||||
**主从模式，即在若干个redis节点中，有的是主节点，有的是从节点 。**
|
||||
|
||||
**redis主从模式中，从节点上的数据，不允许修改，只允许读取数据。要想修改数据，只能访问主节点。**
|
||||
|
||||
假设有三个物理服务器（三个节点），都部署了redis服务，此时就可以把其中一个看作是主节点，其余两个看作是从节点。从节点上的数据要跟随主节点的数据而变化，从节点的数据要和主节点保持一致。
|
||||
|
||||
本来，在主节点上保存了一堆数据，现在引入从节点，就是要把主节点上的数据复制出来，放到从节点中。后续，主节点这里对数据有任何修改，都会把这样的修改同步给从节点。
|
||||
|
||||
|
||||
|
||||
总结：主从模式，主要是针对读操作进行可用性和并发量的提高，而对于写操作来说，无论是可用性还是并发量，都很依赖与主节点，但是主节点又不能搞多个。
|
||||
|
||||
---
|
||||
|
||||
如何在一个云服务器上部署多个redis服务，按照主从模式，实现类似于分布系统的效果？（ubutun20.04）
|
||||
|
||||
我们可以在一个云服务器主机上，运行多个redis-server进程，我们只需保证这几个服务的端口号不同即可。本来redis-server的默认端口号是6379，此时新启动的redis-server端口号就不能是6379了。
|
||||
|
||||
在这里我们创建两个从节点，端口号是6380和6381，而主节点就是原先的redis-server，端口号为默认的6379。
|
||||
|
||||
可以通过修改配置文件来改变：
|
||||
|
||||
1，首先需要将配置文件拷贝两份
|
||||
|
||||
`cp /etc/redis/redis.conf slave1.conf`
|
||||
|
||||
`cp /etc/redis/redis.conf slave2.conf`
|
||||
|
||||
2，然后修改拷贝后的两个配置文件中的选项
|
||||
|
||||
修改端口号——`port 6380 port6381`
|
||||
|
||||
将该服务设置为后台进程——`daemonize yes`
|
||||
|
||||
只需修改这两个选项即可。
|
||||
|
||||
3，启动这两个redis-server（从节点）
|
||||
|
||||
`redis-server slave1.conf`
|
||||
|
||||
`redis-server slave2.conf`
|
||||
|
||||
4，现在我们只是有了多个redis-server，还没有构成主从结构。
|
||||
|
||||
要想配置成主从结构，就需要使用slaveof。有如下三个方法：
|
||||
|
||||
- 在配置文件中加入`slaveof{masterHost} {masterPort}`，之后随redis启动生效。
|
||||
- 在redis-server启动命令中加入--slaveof{masterHost}{masterPort}生效。
|
||||
- 直接使用redis命令：slaveof{masterHost}{masterPort}生效。
|
||||
|
||||
其中{masterHost}和{masterPort}分别指主节点的ip和端口。
|
||||
|
||||
5，在这里我们选择通过修改配置文件的方式来构成主从结构
|
||||
|
||||
在slave1.conf和slave2.conf配置文件中加上slaveof 127.0.0.1 6379即可，以6379的redis-server作为主节点。配置文件修改完毕之后，需要我们重新启动redis-server，配置文件才会生效，所以此时需要重启端口号为6380和6381的redis-server。
|
||||
|
||||
由于我们启动redis-server服务时，是使用`redis-server port`这样的方式启动的，所以在重启的时候，需要使用`kill -9`来杀掉该服务进程，然后再通过redis-server port重启即可。
|
||||
|
||||
而如果我们是使用`service redis-server start`来启动服务器，就需要使用`service redis-server stop`来终止程序。此时如果使用kill -9来终止服务进程，kill掉之后，这个redis-server进程能自动启动 。相当于有一个进程来专门监控指定服务器的运行状态，如果服务器挂了，会立即重新启动。
|
||||
|
||||
因此怎么启动的redis-server，就必须搭配对应的方式进行终止。
|
||||
|
||||
6，再次启动redis-server即可实现主从模式
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
##### 2，断开主从复制
|
||||
|
||||
使用命令slaveof no one可以断开主从关系，这只是暂时的，当redis-server重启之后，主从关系就会恢复，所以要想一直断开主从关系，还是需要修改配置文件。
|
||||
|
||||
##### 3，拓扑
|
||||
|
||||
我们的redis-server服务器可能有很多个节点，如何组织这些节点？
|
||||
|
||||
###### 一主一从结构
|
||||
|
||||
|
||||
|
||||
如果其他客户端想要读取数据，从主节点A或 从节点B读取都可以，两个服务器上的数据是一致的。
|
||||
|
||||
如果是写数据请求，那么只能由主节点A来完成。
|
||||
|
||||
如果此时写请求太多，也会给主节点造成 一定的压力。我们可以通过关闭主节点的AOF，毕竟写内存比写磁盘快，只打开从节点的AOF。但是这种设定，有一个严重缺陷，主节点一旦挂了，不能立即重启，因为主节点这边没有使用AOF保存数据，如果重启了，那么数据就会丢失，进一步的主从同步，也就使从节点上数据也丢失了。改进办法是，当主节点挂了，先从从节点那里获取AOF文件，再启动，这样就可以保证数据没有问题了。
|
||||
|
||||
###### 一主多从结构
|
||||
|
||||
|
||||
|
||||
同理，如果是读请求，可以访问主节点，也可以访问从节点。
|
||||
|
||||
如果是写请求 ，是能访问主节点，主节点上的数据发生变化，就会把改变的数据同步给其他从节点。
|
||||
|
||||
这个结构存在的问题：同步操作是需要消耗网络带宽的，如果子节点太多，就会大大消耗主节点主机的硬件资源。
|
||||
|
||||
###### 树形结构
|
||||
|
||||
|
||||
|
||||
主节点将数据同步给从节点B和从节点C，再由从节点B将数据同步给从节点D和从节点E。
|
||||
|
||||
此时主节点A就不需要太高的网络带宽，但此时数据同步的延时会更长。
|
||||
|
||||
##### 4，原理
|
||||
|
||||
|
||||
|
||||
同步数据的命令：**`PSYNC replicationid offset`**，这个命令是从节点执行的。
|
||||
|
||||
其中replicationid是复制id，是主节点生成的，主节点在启动的时候就会生成。
|
||||
|
||||
当从节点和主节点建立了复制关系，就会从主节点上 获取到这个id，这个id就表明了当前从节点是从哪个主节点上获取的数据。
|
||||
|
||||
在主节点和从节点上一般都有两个replicationid：replicationid和replicationid2。其中replicationid2其备份的作用，比如下面的例子。
|
||||
|
||||
> 现在有一个主节点A和一个从节点B，A在启动的时候会生成一个replicationid，之后B获取到A的replicationid。如果A和B通信过程中出现了一些网络抖动，B可能会认为A挂了，此时从节点B就会晋升为主节点，并给自己生成一个replicationid，此时B的replicationid2就保存了之前获取到的A的replicationid。等到网络稳定，B还可以根据这个replicationid2再次与节点A建立主从关系。（但是主从复制这种方法，当主节点挂了，一般从节点是不会晋升为主节点的） 这个再次建立主从关系的过程，一般是需要手动完成的。当然，在下面的哨兵机制部分，可以自动完成这个过程。
|
||||
|
||||
offset表示偏移量
|
||||
|
||||
主节点和从节点都会维护这个偏移量（一个整数）。
|
||||
|
||||
主节点的偏移量：主节点可能会收到很多的修改操作的命令，每个命令都选哟占据几个字节。主节点会把这些命令的字节数进行累加，这个数字就是主节点的偏移量。
|
||||
|
||||
从节点的偏移量：描述了当前数据同步的进度，从节点会每秒上报自身的偏移量给主节点。
|
||||
|
||||
如果从节点和主节点的偏移量一致，就表述数据 同步完成了。
|
||||
|
||||
**综上，replicationid描述了从哪个主节点同步数据，offset表示同步数据的进度。如果两个机器的replicationid和 offset一样，就表示这两个机器上的数据一致。**
|
||||
|
||||
**replicationid和offset就共同描述了一个"数据集合"。**
|
||||
|
||||
###### PSYNC工作流程
|
||||
|
||||
PSYNC可以从主节点获取全量数据，也可以获取部分数据。
|
||||
|
||||
主要看offset的值，如果设为-1，表示全量获取，如果设置为具体的整数，则表示从当前整数位置来进行获取。
|
||||
|
||||
当然，从节点想要全量的获取数据，还是增量的获取数据，同时也取决于主节点，主节点会自行判定，看当前是否方便给部分数据，如果不方便，会直接给 全量数据。
|
||||
|
||||
|
||||
|
||||
###### 全量复制的流程
|
||||
|
||||
在一个从节点与主节点第一次建立主从关系的时候，就会涉及到数据的同步，而此时一般就是进行全量复制。
|
||||
|
||||
|
||||
|
||||
在进行全量复制的时候，主节点要进行生成rdb文件的操作，然后再把该文件通过网络传输发送给从节点，从节点也是先将该rdb文件保存，然后读取该文件来获取数据。
|
||||
|
||||
而redis也支持"无硬盘模式"（diskless）：主节点生成的rdb的二进制数据，不直接保存到文件中，而是直接通过网络传输发送给从节点 ，省去了读写硬盘的操作，而从节点现在也可以省去这个操作了，直接将收到数据加载到内存中......
|
||||
|
||||
但是，即使引入了"无硬盘模式"，对全量复制的效率提升不是很大，因为全量复制整个操作是比较重量的，数据规模较大。相比于网络传输，读写硬盘操作算是快的了。所以减少了对硬盘的操作，但网络传输无法省去，意味着对整个操作的效率提升不大。
|
||||
|
||||
###### 部分复制流程
|
||||
|
||||
在主节点与从节点连接的过程中，可能由于网络抖动等原因，主从节点的连接断开，此时重新建立连接并进行数据同步的时候，使用的就是部分复制。
|
||||
|
||||
|
||||
|
||||
###### 实时复制
|
||||
|
||||
全量复制：主要适用于从节点刚连上主节点进行数据初始化的工作。
|
||||
|
||||
部分复制：是全量复制的一种特殊情况，属于全量复制的一种优化。
|
||||
|
||||
实时复制：在从节点与主节点建立好连接，并且完成数据同步之后，此时主节点可能会受到源源不断的请求，其中就会包含修改数据的请求，主节点的数据就会发生变化，此时就要把数据也同步给从节点。从节点和主节点之间建立有Tcp连接，当主节点收到修改数据的请求，就会通过该Tcp连接，将这个请求发送给从节点，从节点再根据这些请求修改数据即可。
|
||||
|
||||
所以在实时复制的时候，我们需要保证主节点与从节点的Tcp连接处于可用状态。在这里，使用**心跳包机制**来实现。
|
||||
|
||||
> **心跳包机制：** 主节点：默认每隔10s，向从节点发送一个ping命令，从节点收到后会返回一个"pong"。 从节点：默认每隔1s，向主节点发送一个特定的请求，告诉主节点当前的同步进度（offset），之后主节点也会给出一个响应。 如果，达到某个阈值，还没有收到响应，那么就认为这个主节点/从节点存在问题，判断下线了。
|
||||
|
||||
##### 5，总结
|
||||
|
||||
主从复制解决的问题：单点问题
|
||||
|
||||
单点问题：单个redis节点，可用性不高，性能有限。
|
||||
|
||||
主从复制的特点：
|
||||
|
||||
1，主节点可以用来读写，从节点只能用来读，可以减少主节点的访问压力。
|
||||
|
||||
2，主从复制存在多种拓扑结构：可以在适当的场景使用适当的拓扑结构，比如一主多从的结构，同步操作快，但是消耗的网络资源多，因为主节点要通过网络和所有从节点实现同步。而树形结构，主节点消耗的网络资源减少了，但是如果树的层级太高，会造成数据同步的延迟增长加。
|
||||
|
||||
3，复制分为全量复制，部分复制和实时复制。
|
||||
|
||||
4，通过心跳机制保证主节点和从节点的正常通信和数据一致。
|
||||
|
||||
主从复制的缺点：
|
||||
|
||||
1，从节点多了，数据复制的延时就会非常明显。
|
||||
|
||||
2，如果主节点挂了，从节点不会晋升为主节点，需要通过人工干预的方式恢复。
|
||||
|
||||
### 二，哨兵（Sentinel）
|
||||
|
||||
主从复制最大的问题，还是在主机点上，如果主节点挂了，从节点不会晋升为主节点，需要通过人工干预的方式恢复。
|
||||
|
||||
因此Redis哨兵机制，就是为了解决上述问题，自动的对挂了的主节点进行替换，也就是将上述手动的过程改成自动。
|
||||
|
||||
哨兵机制是通过启动一个不同的进程来体现的，它和redis-servver服务器进程不是 同一个进程 。
|
||||
|
||||
##### 1，相关名词解释
|
||||
|
||||
|名词|逻辑结构|物理结构|
|
||||
|---|---|---|
|
||||
|主节点|Redis服务|一个独立的redis-server进程|
|
||||
|从节点|Redis服务|一个独立的redis-server进程|
|
||||
|Redis数据节点|主从节点|主节点和从节点的进程能|
|
||||
|哨兵节点|监控Redis数据节点的节点|一个独立的redis-sentinel进程|
|
||||
|哨兵节点集合|若干哨兵节点构成的整体|若干redis-sentinel进程|
|
||||
|Redis哨兵(Sentinel)|Redis提供的高可用方案|哨兵节点集合和Redis主从节点|
|
||||
|应用方|一个或多个客户端|一个或多个连接Redis的进程|
|
||||
|
||||
##### 2，哨兵自动恢复主节点故障
|
||||
|
||||
|
||||
|
||||
如果一个哨兵节点发现主节点挂了，为了防止预判，还需多个哨兵节点共同认为这件事情。
|
||||
|
||||
如果主节点确实挂了，这些哨兵节点会选出一个作为leader，由这个哨兵节点负责从剩下的从节点中选一个出来，作为主节点。选出新的主节点之后，哨兵节点就会控制该节点执行slaveof no one，并且通知其他从节点，修改slaveof到新的主节点之上。哨兵节点会自动通知客户端程序，告知新的主节点是谁，并且此后客户端再进行写操作时，就会访问新的主节点了。
|
||||
|
||||
##### 3，哨兵机制的特点
|
||||
|
||||
监控：Sentinel节点会定期检查redis数据节点，使用心跳包机制。
|
||||
|
||||
故障转移：实现从节点晋升为主节点，并维护好正确的主从关系。
|
||||
|
||||
通知：Sentinel会将故障转移的结果通知给应用方。
|
||||
|
||||
##### 4，主从切换的具体流程
|
||||
|
||||
_**重点，面试题：**_
|
||||
|
||||
1，主观下线：哨兵节点通过心跳包进制，判读redis主节点服务器是否正常工作，如果没有沙鸥到响应，该哨兵节点就会认为该主节点下线了。
|
||||
|
||||
2，客观下线：当多个哨兵节点都认为主节点挂了之后，此时这个主节点就是主观下线了。
|
||||
|
||||
3，再从多个哨兵节点中，选举出一个leader节点，由这个leader节点负责从剩下的节点中选出一个作为主节点。
|
||||
|
||||
4，leader挑选完毕后，此时需要从剩下的从节点中选一个当作新的主节点。
|
||||
|
||||
- 首先会看这些从节点的优先级，每个 redis数据节点，都会有自己的配置文件，配置文件中就有一个优先级的设置。leader会选择优先级高的作为新的主节点。
|
||||
- 如果数据节点的优先级都一样，那么就比较这些数据节点的offset，offset表示从节点与原来主节点进行数据同步的进度，offset越大，说明这个节点与原来主节点的数据相似度最高，此时就会选择这个节点作为新的主节点。
|
||||
- 如果前面两个条件都一样，此时其实意味着从这些节点中任选一个都行。那么再看这些节点的runid（一串数字），每个redis数据节点启动时都会生成一个随机的runid，此时比较runid的大小。让runid更小的作为新的主节点。
|
||||
- 指定好新的主节点之后，此时leader就会控制这个主节点执行slaveof no one，让这个节点成为主节点（master）。再控制其他从节点，执行slaveof，让这些从节点，以新的mater作为主节点。
|
||||
|
||||
##### 5，总结
|
||||
|
||||
哨兵节点不能只有一个，因为哨兵节点挂了也会影响 系统的运作。
|
||||
|
||||
哨兵节点最好是奇数个，方便选举leader，得票数更容易超过一半。
|
||||
|
||||
哨兵+主从复制解决的问题是"提高可用性"，极端情况下写操作的数据丢失无法解决。
|
||||
|
||||
哨兵+主从复制不能提高数据的存储容量 ，当数据接近或者几乎超过机器的物理内存时，这样的结构就难以胜任了，**而接下来的redis集群，就是解决存储容量问题的有效方案。**
|
||||
|
||||
### 三，集群
|
||||
|
||||
**广义上的集群，是指多个机器，构成的分布式系统，就可以称为一个集群，所以前面的主从复制和哨兵模式也可以看作是一个集群。**
|
||||
|
||||
**而侠义上的集群，是redis提供的集群模式。这个集群模式之下，主要是解决存储空间不足的问题。**
|
||||
|
||||
在redis哨兵模式中，本质还是redis数据节点存储数据，其中就要求主节点/从节点来存储数据的全集。为了提高 数据存储的容量，这时就引入多台机器，每台机器只存储一部分数据。
|
||||
|
||||
> 假设有1TB的数据需要存储： 拿两台机器来存储 ，每台机器需要存储512GB。 拿三台机器来存储，每台机器需要存储300多GB。 拿四台机器来存储，每台机器需要存储 256GB......
|
||||
|
||||
但是还存在一个问题，如果使用三台机器来存储1TB的数据，如果某个机器挂了怎么办，所以我们还需要为每个机器 再分配几个从节点。
|
||||
|
||||
|
||||
|
||||
这三组机器的数据都是不同的，每个 slave都是mster的备份，当master挂了，slave就会晋升为master。
|
||||
|
||||
如上图所示，每个虚线框就可以看作是一个分片（Sharding）。
|
||||
|
||||
_**重点面试题：**_
|
||||
|
||||
三种主流的分片算法：哈希求余，一致性哈希算法，哈希槽分区算法。
|
||||
|
||||
##### 1，哈希求余
|
||||
|
||||
借助hash函数，把一个key映射成为 一个数字，在对数组长度（这里就是分片的个数）进行求余，就可以得到这个key是在哪个分片中。
|
||||
|
||||
比如现在有3个分片，编号为0，1，2
|
||||
|
||||
此时就可以针对要查询的数据（或插入的数据）计算hash值（比如可以使用md5算法），再把这个值余上分片的个数，此时就会得到一个数字，这个数字就表示这个数据在哪个分片中。
|
||||
|
||||
但是当总体的数据增长时，就需要扩容，引入更多的分片，此时分片的个数就变了。
|
||||
|
||||
如果发现某个数据在扩容之后，不该待在当前的分片中，那么就需要重新分配数据（数据搬运）。这里涉及到的数据搬运不仅仅是主节点进行，从节点也需要进行。
|
||||
|
||||
这种方式开销极大，往往不能再生产环境上操作的，搬运成本比较大。
|
||||
|
||||
**数据搬运成本大的原因：这种哈希求余的方式，导致数据是交替出现的，比如100出现在0号分片，101出现在1号分片，102出现在2号分片，103又是0号分片 。这就导致在扩容之后，分片个数增长，就会有 大量的数据需要进行搬运。**
|
||||
|
||||
##### 2，一致性哈希算法
|
||||
|
||||
这种方式可以降低上述的"搬运开销"。
|
||||
|
||||
key映射到分片序号的过程不再是简单的求余了，而是改成以下过程：
|
||||
|
||||
第一步：把0~2^32-1这个数据空间，映射到一个圆环上，按照顺时针方向增长。
|
||||
|
||||
|
||||
|
||||
第二步：假设分成3个分片，将分片放到对应的位置上
|
||||
|
||||
每个分片就会对应一个值，比如0号分片对应的值就是0
|
||||
|
||||
|
||||
|
||||
第三步：假定有一个key，计算得到的hash值为H，如何计算这个key是在哪个分区？此时H会在圆环上的某个位置，从这个位置开始，顺时针向下找，找到的第一个分片，就是这个key所属 的分片。
|
||||
|
||||
|
||||
|
||||
这就相当于，N个分片，把整个圆环分成N个区域，key的hash值落在哪个区域，它就属于哪个分片。
|
||||
|
||||
|
||||
|
||||
因此在 一致性哈希这样的设定下，把数据交替出现，改进成了连续出现。
|
||||
|
||||
在这种情况下，如何进行扩容，假设新增一个分片。
|
||||
|
||||
如下图所示，在圆环上找一个位置，设为3号分片的位置。该部分本来是0号分片上的，这样一来，只需将0号分片上的这段数据搬运到3号分片上即可，其他分片上的数据不需要搬运。
|
||||
|
||||
这种搬运的成本是有的，但是比之前哈希求余的方式低了不少。
|
||||
|
||||
|
||||
|
||||
这种方式，虽然搬运的成本降低了，但是也导致了各个分片上的数据量不均匀，称作数据倾斜。
|
||||
|
||||
##### 3，哈希槽分区算法
|
||||
|
||||
这是Redis真正采用的分片算法。
|
||||
|
||||
哈希槽计算公式：hsah_slot=hash(key）%16384，一共有16384个槽。
|
||||
|
||||
假设现在有3个分片，一种分配方式如下：
|
||||
|
||||
- 0号分片：[0,5461]，共5462个槽位。
|
||||
- 1号分片：[5462,10923]，共5462个槽位。
|
||||
- 2号分片：[5463,16384]，共5460个槽位。
|
||||
|
||||
这里只是分片的一种，分片可以很灵活。每个分片持有的槽位号：可以是连续的，也可以是不连续的。
|
||||
|
||||
此处 ，每个分片都会使用一个位图结构，来表示该分片有多少槽位号，16384个bit位，用每一位的0/1表示是否持有这个槽位。
|
||||
|
||||
现在假设要新增一个分片，那么此时可以从0号分片，1号分片，2号分片上分别截取一部分出来，放到新的分片上，这样就可以解决数据倾斜的问题。
|
||||
|
||||
##### 4，故障处理
|
||||
|
||||
如果某个主节点挂了，此时就会把该主节点旗下的某一个从节点提拔为主节点，保证我们的redis能够正常工作。
|
||||
|
||||
###### 故障判定
|
||||
|
||||
识别某个节点是否挂了。
|
||||
|
||||
1. 节点A给节点B发送ping包，B就会给A返回一个pong包。ping和pong除了携带message type属性之外，其他部分都是一样的。还会包含集群的配置信息（该节点的id，该节点属于哪个分片，该节点是主节点还是从节点，从属于哪个主节点，持有哪些slot槽位）。
|
||||
2. 每个节点，每秒钟都会给一些 随机的节点发送ping包，而不是给所有节点都发送。这样设定设为了在节点很多的时候，心跳包也会非常多。
|
||||
3. 当节点A向节点B发送ping包后，B不能如期回应的时候，此时A就会尝试重置和B的TCP连接，看能否连接成功，如果连接失败，就会认为B节点下线了，A就会把B设为PFAIL状态（相当于主观下线）。
|
||||
4. A判定B为PFAIL后，会通过redis内置的Gossip协议，和其他节点进行沟通，向其他节点确认B的状态。（每个 节点都会维护一个自己的下线列表，由于视角不同，每个节点的下线列表也就不同）。
|
||||
5. 此时A发现很多节点也认为B为PFAIL，并且数目超过集群节点个数的一半，那么A就会把B标记为PFAIL（相当于客观下线），并且把这个消息同步给其他节点（其他节点收到后，也会把B标记为PFAI）。
|
||||
|
||||
以下三种情况会出现集群宕机：
|
||||
|
||||
- 某个分片，所有的主节点和从节点都挂了。
|
||||
- 某个分片，主节点挂了，没有从节点。
|
||||
- 整个集群超过一半的主节点挂了。
|
||||
|
||||
###### 故障迁移
|
||||
|
||||
还是上述的例子。
|
||||
|
||||
如果B是从节点挂了，那么就不需要进行故障迁移，毕竟从节点挂了，还可以通过访问同一个 分片内的主节点或者其他从节点来获取数据。
|
||||
|
||||
如果B是主节点，就会由B的从节点（比如C和D）发生故障迁移。重新挑选一个主节点，代替之前主节点的位置。
|
||||
|
||||
具体过程如下：
|
||||
|
||||
1. 从节点需要判断自己是否具有参选资格，如果主节点和从节点太久没有进行通信（此时认为主节点和从节点的数据差异太大了），就失去竞选资格。
|
||||
2. 具有资格的节点，比如C和D，就会先休眠一段时间，休眠时间=500ms基础时间+【0，500ms】随机事件+排名*1000ms。offset值越大，排名就越靠前（越小）。offset表示主节点和从节点数据同步的进度。
|
||||
3. 比如C的休眠时间到了，C就会给集群中其他所有节点，进行拉票操作。但是只有主节点才有投票资格。
|
||||
4. 主节点就会把自己的票投给C节点（每个主节点只有一票），当C收到的票数超过主节点数目的一半，C就会晋升为主节点（C会自己执行slaveof no one，并且让D执行slaveof D）。
|
||||
5. 同时，C还会把自己称为主节点的消息，同步给集群中的其他节点，大家也都会更新自己保存的集群信息结构。
|
||||
|
||||
总之，哪个节点会成为主节点，就看哪个节点先被唤醒，哪个节点的休眠时间短，大概率就是新的主节点。
|
||||
|
||||
如果两个节点被唤醒的时间是差不多的，那么此时就各凭本事了，取决于网络延迟，线程调度等等因素。
|
||||
|
||||
**上述选举的过程，称为Raft算法。**
|
||||
|
||||
### 四，Redis典型应用——缓存
|
||||
|
||||
Redis最主要的三个用途：
|
||||
|
||||
1. 存储数据（内存数据库）
|
||||
2. 缓存
|
||||
3. 消息队列
|
||||
|
||||
##### 1，使用redis作为数据库的缓存
|
||||
|
||||
在一个网站中，通常会使用[关系型数据库](https://cloud.tencent.com/product/tencentdb-catalog?from_column=20065&from=20065)（如MySQL）来存储数据，关系型数据库虽然强大，但是有一个很大的缺陷，就是性能不高。（换言之 ，进行一次 查询操作消耗的系统资源较多）。
|
||||
|
||||
> 为什么说关系型数据库的性能不高？
|
||||
|
||||
1. 数据库是把数据存储在硬盘上的，硬盘的IO速度并不快，尤其是随机访问。
|
||||
2. 如果查询不能命中索引，就需要进行表的遍历，这就会大大增加 IO的次数。
|
||||
3. 关系型数据库对SQL的操作会进行一系列的解析，校验，优化工作。
|
||||
4. 如果是一些复杂查询，比如联合查询，需要进行笛卡尔积的操作，效率更是降低很多。
|
||||
|
||||
因为MySQL等数据库 ，效率比较低，所以承担的并发量就有限了，一旦请求量多了，数据库的压力就很大，甚至很容易就宕机了。对于服务器的每一个请求，都要消耗一定的硬件资源（CPU，内存，硬盘，网络带宽等等），任意一种资源的消耗超出了机器能提供的上限，机器就很容易出故障。
|
||||
|
||||
如何提高MySQL能承担的并发量？
|
||||
|
||||
1. 开源：引入更多的机器，构成数据集群。
|
||||
2. 节流：引入缓存，将一些热点数据保存到缓存中。后续在查询数据的时候，如果数据库中已经存在了，就不再访问MySQL了。
|
||||
|
||||
##### 2，如何知道redis中应该存储哪些数据？
|
||||
|
||||
也就是怎么获得热点数据。
|
||||
|
||||
这涉及到缓存的两种更新策略：1，定期生成 2，实时生成
|
||||
|
||||
1，定期生成
|
||||
|
||||
将访问的数据 ，以日志的 形式记录下来。接下来就可以针对这些日志进行统计了，统计这一天/一周/一个月，数据出现的频率，然后再按照降序排序，取出前20%的数据数据，这些数据 就是热点数据。
|
||||
|
||||
优点：上述过程，实际上实现起来比较简单，过程更可控，缓存中的数据是比较扶额和预期的，方便排查问题。
|
||||
|
||||
缺点：实时性不够。如果出现一些突发事件，有些本来不是热词的内容成了热词，这就可能会给后面的数据库带来较大的压力。
|
||||
|
||||
2，实时生成
|
||||
|
||||
- 如果在redis中查到了数据，就直接返回。
|
||||
- 如果没有查到，就从数据库查，同时把查到的数据写入redis中。
|
||||
|
||||
这里就会有一个问题，如果不停的向redis中写入数据，就会使redis的内存占用越来越高，逐渐达到内存上限。
|
||||
|
||||
> 此时如果继续向redis中写入数据，就会出现问题，为了解决这个问题，redis就引入了"内存淘汰策略"。 _**经典面试题：**_
|
||||
|
||||
- FIFO（First In First Out）先进先出：把缓存中存在时间最久的（也就是先来的数据）淘汰掉。
|
||||
- LRU（Least Recently Used）淘汰最近未使用的：记录每个key的最近访问时间，把最近访问时间最老的key淘汰掉
|
||||
- LFU（Least Frequently Used）淘汰访问次数最少的：记录每个key最近一段时间的访问次数，把访问次数最少的淘汰掉。
|
||||
- Random 随机淘汰：从所有的key中随机抽取一个淘汰掉。
|
||||
|
||||
##### 3，缓存预热，缓存穿透，缓存雪崩和缓存击穿
|
||||
|
||||
**缓存预热（Cache preheating）**
|
||||
|
||||
缓存中的数据，有两种更新策略：**1，定期生成 2，实时生成**
|
||||
|
||||
1. 如果使定期生成，就不涉及到预热。
|
||||
2. 如果是实时生成，在redis服务首次接入之后，服务器里是没有数据的，此时客户端的所有请求就都会打给MySQL，如果请求量太多，可能就会导致MySQL服务挂了。随着时间的推移，reids中的数据越来越多，MySQl承担的压力也就越来越小了。
|
||||
|
||||
缓存预热，就是为了解决上述问题。把定期生成和实时生成相结合，先通过离线的方式，通过一些统计的途径，先找到一批热点数据，导入到redis中。此时导入的这批热点数据就能帮MySQL分担一些压力了。随着时间的推移，使用新的热点数据来淘汰旧的热点数据。
|
||||
|
||||
在刚开始架构演进的时候，没有缓存，此时要加入缓存，就要进行缓存预热。还有当服务器进行重启的时候，我们要保证重启之后缓存中是否有数据以及 这里的数据 是否是热点数据，这也涉及到缓存预热。
|
||||
|
||||
---
|
||||
|
||||
**缓存穿透（Cache penetration）**
|
||||
|
||||
在一次查询的过程中，如果要查询的某个key，在redis中没有，在MySQL中也没有。也就意味着此时这个key是不会被放到redis中，那么下次访问依然会访问数据库，这就会导致数据库承担的请求太多，压力很大。这种情况称为缓存穿透。
|
||||
|
||||
出现这种情况可能的原因：
|
||||
|
||||
- 业务设计不合理：比如缺少必要的参数检验环节，导致非法到的key也被进行查询了。
|
||||
- 开发/运维误操作：不小心把部分数据从数据库中删除。
|
||||
- 黑客恶意攻击。
|
||||
|
||||
解决方案：
|
||||
|
||||
1. 如果发现这个key，在redis和MySQL中都不存在在，仍然写入redis，将value设成一个非法值（比如""）。再应用层程序可以检查出这是一个非法的key。
|
||||
2. 还可以引入布隆过滤器，每次查询redis/MySQL之前，都先判断一下key是否在布隆过滤器上存在。布隆过滤器本质是结合了hash+bitmap，以较小的空间开销，以较快的访问速度，实现针对key是否存在的判定。
|
||||
|
||||
---
|
||||
|
||||
**缓存雪崩（Cache avalanche）**
|
||||
|
||||
由于在短时间内，redis上大规模的key失效，导致缓存命中率陡然下降，并且MySQL压力迅速上升，甚至导致MySQL直接宕机。
|
||||
|
||||
可能的原因：
|
||||
|
||||
- redis直接挂了，redis宕机/redis集群模式下很多节点宕机。（这是最主要的）
|
||||
- redis正常工作，但是可能之前短时间内设置了很多key给redis，并且设置的过期时间是相同的。在给redis里设置key作为缓存的时候，有的时候为了考虑时效性，就会设置过期时间（和redis的内存淘汰机制是配合使用的）。
|
||||
|
||||
解决方法：
|
||||
|
||||
- 加强监控报警，加强redis集群可用性的保证。
|
||||
- 不给key设置过期时间，或者在设置过期时间的时候，添加随机因子（避免同一时刻过期 ）。
|
||||
|
||||
**缓存击穿（Cache breakdown）**
|
||||
|
||||
相当于缓存雪崩的特殊情况，针对**热点key**，突然过期了，导致大量的请求访问到数据库上，导致数据库宕机了。
|
||||
|
||||
解决方案：
|
||||
|
||||
1. 基于统计的方式发现热点key，并设置为永不过期。这种方案往往需要服务器做出较大的调整。比如把当前访问哪些key的日志记录下来，接到一个消息队列中，再通过一些计算，将结果再返回给我们的服务器。
|
||||
2. 进行必要的降级服务。例如访问数据库的时候，使用分布式锁，限制同时请求数据库的并发数。
|
||||
|
||||
### 五，分布式锁
|
||||
|
||||
在一个分布式系统中，会涉及到多个节点访问同一个公共资源的问题，此时就需要通过 锁 来做互斥控制，避免出现类似于 线程安全的问题。而C++中的std::mutex，这样的锁只能在当前进程中生效。
|
||||
|
||||
而在分布式系统中，是有很多进程的（每个服务器，都是独立的进程）。因此，之前的锁就难以对现在分布式系统中的多个进程之前产生制约。分布式系统中，多个进程之间的执行顺序也是不确定的。
|
||||
|
||||
此时就需要引入"分布式锁"，来解决上述 问题。
|
||||
|
||||
**所谓的分布式锁，也是一个/一组单独的服务器程序，给其他的服务器提供"加锁"这样的服务。redis是一种典型的可以是实现分布式锁的方案，但不是唯一的一种。**
|
||||
|
||||
|
||||
|
||||
买票服务器在进行买票的过程中，就需要先加锁，就是往redis上尝试设置一个特殊的key-value，完成买票后，就会把这个key-value删掉。其他服务器在买票的过程中，也会去尝试设置这个key-value，如果发现key-value已经存在，就认为加锁失败（是放弃还是阻塞，就看具体的实现策略了）。
|
||||
|
||||
**这个加锁过程其实就对标redis中的一个命令setnx key val，这个命令如果key不存在才会设置，如果key存在就会执行出错，同时解锁过程也对标redis中的del key命令。**
|
||||
|
||||
##### 1，引入过期时间
|
||||
|
||||
问题1：某个服务器加锁成功了(setnx成功)，如果该服务器执行后续逻辑的过程中，程序崩溃了，此时还没有执行到解锁操作。这种情况就会导致redis上的key无人删除，也就导致其他服务器无法获取到锁了。
|
||||
|
||||
解决办法：在加锁过程中，给这个key设置一个过期时间，set ex nx这样的命令来完成设置，时间到了，redis服务器会自动删除这个key，这是其他服务器就可以获取到锁了。
|
||||
|
||||
注意：在设置过期时间的时候，智能使用set nx ex这样的方式设置，不能使用set nx ，exprie这两个命令来设置。因为redis上多个命令之间，是无法保证原子性的，此时就可能出现，这两个命令，一个执行成功，一个执行失败。相比之下，使用一条命令设置，是更加稳妥的。
|
||||
|
||||
##### 2，引入校验id
|
||||
|
||||
问题2：所谓的加锁，就是给redis上设置一个key-val，所谓的解锁，就是给redis上的key-val删除掉。锁，就可以认为是redis上的一个普通键值对。可能会出现服务器1执行了加锁，而服务器2误执行了解锁。因此就可能给我们的系统带来严重的问题。（比如票数超卖)
|
||||
|
||||
为了解决这个问题，就引入了校验机制。
|
||||
|
||||
1. 给服务器编号，每个服务器都有自己的身份标识。
|
||||
2. 进行加锁的时候，设置key-val。**key对应着服务器要访问的资源，val表示服务器的编号。**
|
||||
3. 在解锁的时候，先查询这个锁对应的服务器编号，然后判定这个编号和执行解锁的服务器的编号是否一致，如果是，才能真正执行del；否则，执行失败。
|
||||
|
||||
##### 3，引入lua脚本
|
||||
|
||||
对于问题2，我们引入了校验id，但是还存在问题。就是在解锁的时候，需要两步操作，先获取到key对应的val，在执行del，此处是两步操作（不是原子的），就可能会出现问题。
|
||||
|
||||
一个服务器内部，也可能是多线程的，此时，就可能服务器A的两个线程都在执行解锁操作，首先进行id校验，都通过了，然后开始执行del命令，del就会被重复执行。
|
||||
|
||||
这看起来没有什么问题，但是如果此时一个线程执行完了del，又有一个服务器B来进行加锁(set nx ex)，加锁成功，之后服务器A的另一个线程执行del，就会把服务器B的锁给解掉。
|
||||
|
||||
归根节点，是因为get 和 del这两个命令不是原子的，此时可以引入事务，将这两个操作打包成一个事务，使在执行get 和 del之间不会执行其他操作（避免插队）。
|
||||
|
||||
**使用事务，能解决上述问题，但是在实践中，往往推荐使用更好的方案——lua脚本。**
|
||||
|
||||
**redis执行lua脚本的过程 ，也是原子的，相当于执行一条命令一样。**
|
||||
|
||||
**在redis官方文档中，也明确说明了，lua就属于事务的替代方案。**
|
||||
|
||||
##### 4，引入看门狗（Watch Dog）
|
||||
|
||||
在前面提到过，服务器在进行加锁的时候，要给key设置一个过期时间。
|
||||
|
||||
- 这个过期时间，如果设置的太短，就可能在服务器的业务逻辑还未执行完，锁就释放了。
|
||||
- 如果设置的太长，也会导致"锁释放不及时"的问题。
|
||||
|
||||
**这里更好的方式是"动态续约"。**
|
||||
|
||||
**初始情况下，设置一个过期时间（比如设置1s），就提前在还剩300ms的时候（不一定是300ms，数值可以灵活调整），如果当前任务还未执行完，就把过期时间再续上1s。等到时间又快到了，任务还未执行完，就再续。**
|
||||
|
||||
这样设置也有一个好处：如果服务器中途崩溃了，也就没人续约了，此时，锁就可以再较短的时间内被释放。
|
||||
|
||||
服务器进行"动态续约"往往是需要有一个专门的线程来完成这个事情，这个线程就叫做**"看门狗"。**
|
||||
|
||||
##### 5，redlock算法
|
||||
|
||||
使用redis作为分布式锁，redis本身是有可能挂了的。
|
||||
|
||||
要想保证redis的高可用，可以使用主从复制，哨兵，集群模式等方案。这里使用哨兵机制最合适。
|
||||
|
||||
进行加锁操作，就是把key设置到设置到主节点上，如果主节点挂了，有哨兵节点会把从节点升级为主节点，进一步保证刚才的锁可用。
|
||||
|
||||
**但是主节点和从节点的数据同步是有延迟的，可能主节点收到了加锁的请求(set nx ex），还没来得及推送给从节点，主节点就挂了。即使从节点升级成为了主节点，但是刚才加锁的对应的数据是不存在的。**
|
||||
|
||||
**此时就需要使用 redlock算法。（redis作者给出的一种方案）核心思想：冗余，少数服从多数。**
|
||||
|
||||
此时加锁，就是按照一定的顺序，针对这些redis都进行加锁操作。如果某个主节点挂了（加不上锁），没关系，继续给下一个主节点加锁。如果加锁成功的主节点个数超过总结点总数的一半，就视为加锁成功。同理，进行解锁的时候，每个主节点都会进行一遍解锁。
|
||||
|
||||
|
||||
@@ -1,592 +0,0 @@
|
||||
---
|
||||
tags: [全栈开发, 大作业, 执行计划, gRPC, Gin, OSS, Eino, React]
|
||||
create time: 2026-05-09 14:30
|
||||
---
|
||||
|
||||
# 大作业·执行计划 — 双端 gRPC HR 招聘系统
|
||||
|
||||
## 概述
|
||||
|
||||
本文档基于《大作业项目要求》《思维导图》《工程结构设计》三份参考资料，梳理出分阶段、可落地的开发执行计划。整体采用 **六阶段推进** 策略：环境准备 → Proto 先行 → 后端双服务 → **前端一日冲刺** → 联调测试 → 视频录制与提交，每个阶段明确任务清单、前置依赖和验收标准，确保按期完成高质量交付。
|
||||
|
||||
> [!tip] 如何使用本计划
|
||||
> 建议按阶段的顺序推进，不要跳跃。Proto 定义是前后端的"契约"，必须先于业务代码完成。每个阶段完成后对照验收清单自检，避免返工。
|
||||
|
||||
## 一、整体时间规划与打勾进度
|
||||
|
||||
将整个开发周期拆分为 6 个阶段，各阶段之间存在明确的先后依赖关系。下方是总进度看板，每完成一个阶段就打勾：
|
||||
|
||||
```mermaid
|
||||
gantt
|
||||
title 大作业开发总时间线
|
||||
dateFormat YYYY-MM-DD
|
||||
axisFormat %m-%d
|
||||
todayMarker stroke-width:3px,stroke:#fb8c00,opacity:0.6
|
||||
|
||||
section 阶段一 · 环境就绪 (M0)
|
||||
Go / Node / MySQL / OSS :done, p1, 2026-05-10, 1d
|
||||
.gitignore + .env.example :done, p1b, after p1, 30m
|
||||
|
||||
section 阶段二 · Proto 先行 (M1)
|
||||
7 个接口定义文件 :done, p2, 2026-05-11, 1d
|
||||
protoc 生成 Go 代码 :done, p2b, after p2, 30m
|
||||
|
||||
section 阶段三 · 后端双服务 (M2)
|
||||
3A · MySQL 建表 : p3a, 2026-05-12, 1d
|
||||
3B · Logic 核心服务 (12项) :milestone, m3b, 2026-05-14, 0d
|
||||
3C · Web 网关服务 : p3c, after p3a, 2d
|
||||
|
||||
section 阶段四 · 前端一日冲刺 (M3)
|
||||
Foundation 共享基建 : p4a, 2026-05-15, 3h
|
||||
候选人用户端 (6页) : p4u, after p4a, 4h
|
||||
HR 管理端 (7页) : p4h, after p4a, 5h
|
||||
Build 验证 + Commit :milestone,m4z, 2026-05-15, 0d
|
||||
|
||||
section 阶段五 · 联调自测 (M4)
|
||||
全链路跑通 : p5a, 2026-05-16, 1d
|
||||
专项测试 + Bug 修复 : p5b, 2026-05-17, 1d
|
||||
|
||||
section 阶段六 · 录制提交 (M5)
|
||||
文档完善 : p6a, 2026-05-18, 2d
|
||||
视频录制 + KDoc 提交 :milestone,m6end, 2026-05-18, 0d
|
||||
|
||||
%% 里程碑锚点
|
||||
milestone M0_环境就绪 :milestone, mk1, 2026-05-10, 0d
|
||||
milestone M1_Protobuf冻结 :milestone, mk2, 2026-05-11, 0d
|
||||
milestone M2_后端可运行 :milestone, mk3, 2026-05-14, 0d
|
||||
milestone M3_双端完成 :milestone, mk4, 2026-05-15, 0d
|
||||
milestone M4_联调通过 :milestone, mk5, 2026-05-17, 0d
|
||||
milestone M5_正式提交 :milestone, mk6, 2026-05-18, 0d
|
||||
```
|
||||
|
||||
<style>
|
||||
.gantt .done { fill: #c8e6c9 !important; stroke: #43a047 !important; stroke-width: 2px !important; }
|
||||
.gantt .active { fill: #fff9c4 !important; stroke: #fdd835 !important; stroke-width: 2px !important; }
|
||||
.gantt .milestone { fill: #ffccbc !important; stroke: #e64a19 !important; stroke-width: 3px !important; }
|
||||
</style>
|
||||
|
||||
| 阶段 | 日期 | 核心交付物 | 里程碑 |
|
||||
| --------------- | ------------- | ------------------------------ | -------- |
|
||||
| ~~阶段一：环境与基础建设~~ | ~~05-10~~ | Go / Node / MySQL / OSS 就绪 | ✅ **M0** |
|
||||
| 阶段二：Proto 接口定义 | ~~05-11~~ | 7 个 `.proto` 文件 + 生成代码 | ⬜ **M1** |
|
||||
| 阶段三：后端双服务 | 05-12 ~ 05-14 | Logic gRPC + Web Gin 均可独立运行 | ⬜ **M2** |
|
||||
| 阶段四：前端一日冲刺 | 05-15 | hr-frontend + user-frontend 启动 | ⬜ **M3** |
|
||||
| 阶段五：前后端联调 | 05-16 ~ 05-17 | 全链路测试通过 | ⬜ **M4** |
|
||||
| 阶段六：视频录制与提交 | 05-18 | 视频 + 文档全部提交 | ⬜ **M5** |
|
||||
|
||||
> [!tip] 使用说明
|
||||
> - 🟢 **绿色条** = 已完成阶段 · 🟡 **黄色条** = 当前活跃期 · 🔴 **菱形标记** = 里程碑检查点
|
||||
> - 橙色竖线为今日日期标注，直观对比当前所处阶段
|
||||
> - 甘特图下方表格同步映射 M0~M5 里程碑编号，与第九节里程碑总表一一对应
|
||||
|
||||
> [!question] 如果某个阶段超时了怎么办？
|
||||
> 优先级原则：核心功能（gRPC 分层调用、OSS 签名上传、Eino 对话）> 次要功能（分页搜索、数据可视化）。宁可缩减 UI 装饰细节，也要保住验收红线。
|
||||
|
||||
## 二、阶段一：环境与基础建设
|
||||
|
||||
> [!note] 进度追踪
|
||||
> - [x] T1.1 Go 1.21+ 安装并验证
|
||||
> - [x] T1.2 Node.js 18+ / npm 安装并验证
|
||||
> - [x] T1.3 MySQL 8.0+ 安装 + 数据库实例创建
|
||||
> - [x] T1.4 OSS 平台注册 + 私有 Bucket 创建
|
||||
> - [x] T1.5 Git 仓库初始化 + 目录结构建立
|
||||
> - [ ] T1.6 `.gitignore` + `.env.example` 初始化
|
||||
|
||||
<details>
|
||||
<summary>📋 展开查看详细任务表</summary>
|
||||
|
||||
### 2.1 详细任务清单
|
||||
|
||||
| 编号 | 任务 | 耗时估计 | 说明 |
|
||||
|------|------|----------|------|
|
||||
| T1.1 | 安装并验证 Go 1.21+ | 30min | `go version`，配置 GOPATH 和 GOMODCACHE |
|
||||
| T1.2 | 安装并验证 Node.js 18+ / npm | 30min | 后续用于两个前端项目 |
|
||||
| T1.3 | 安装并验证 MySQL 8.0+ | 30min | 创建数据库实例，记录连接信息 |
|
||||
| T1.4 | 注册 OSS 平台，创建私有 Bucket | 30min | 关闭匿名访问，关闭公开读权限 |
|
||||
| T1.5 | 创建 Git 仓库，建立最终目录结构 | 30min | 参照 `final_homework/` 规范 |
|
||||
| T1.6 | 初始化 .gitignore 和 .env.example | 30min | 敏感文件排除：.env、go.sum（可选）、node_modules |
|
||||
|
||||
</details>
|
||||
|
||||
### 2.2 前置条件
|
||||
|
||||
- 无，这是第一个阶段。
|
||||
|
||||
### 2.3 验收标准
|
||||
|
||||
- [ ] `go version`、`node -v`、`mysql --version` 均正常输出
|
||||
- [ ] OSS Bucket 已创建且为私有（匿名访问已关闭）
|
||||
- [ ] 本地目录结构已按 `工程结构.md` 的顶层树创建出来
|
||||
- [ ] `.gitignore` 正确排除了敏感配置文件
|
||||
|
||||
```bash
|
||||
# 预期目录骨架
|
||||
final_homework/
|
||||
├── hr-frontend/
|
||||
├── user-frontend/
|
||||
├── web-gin-service/
|
||||
├── logic-grpc-service/
|
||||
└── api/
|
||||
```
|
||||
|
||||
> [!warning] 常见陷阱
|
||||
> - OSS 密钥务必写入 .env 或独立配置文件，**不要硬编码到业务代码中**。真实业务场景中 key 是绝对禁止提交到仓库的。
|
||||
> - 新建 Git 仓库后立刻添加 .gitignore，避免误提交 .env 文件。
|
||||
|
||||
## 三、阶段二：Proto 接口定义（契约先行）
|
||||
|
||||
> [!note] 进度追踪
|
||||
> - [ ] T2.1 `common.proto` — 通用响应码、分页参数
|
||||
> - [ ] T2.2 `auth.proto` — Login/RPC、Register/RPC、VerifyToken/RPC
|
||||
> - [ ] T2.3 `job.proto` — CreateJob/RPC、UpdateJob/RPC、ListJobs/RPC、DeleteJob/RPC
|
||||
> - [ ] T2.4 `application.proto` — SubmitApplication/RPC、ListApplications/RPC
|
||||
> - [ ] T2.5 `profile.proto` — GetProfile/RPC、UpdateProfile/RPC
|
||||
> - [ ] T2.6 `resume.proto` — GenOssSign/RPC、SaveResume/RPC
|
||||
> - [ ] T2.7 `chat.proto` — SendChat/RPC、GetHistory/RPC
|
||||
> - [ ] T2.8 protoc 生成 Go 代码
|
||||
|
||||
<details>
|
||||
<summary>📋 展开查看详细任务表 + 前置条件</summary>
|
||||
|
||||
### 3.1 详细任务清单
|
||||
|
||||
| 编号 | 任务 | 前置依赖 | 耗时估计 |
|
||||
|------|------|----------|----------|
|
||||
| T2.1 | 定义 `common.proto`（通用响应码、分页参数） | — | 30min |
|
||||
| T2.2 | 定义 `auth.proto`（Login/RPC、Register/RPC、VerifyToken/RPC） | T2.1 | 30min |
|
||||
| T2.3 | 定义 `job.proto`（CreateJob/RPC、UpdateJob/RPC、ListJobs/RPC、DeleteJob/RPC） | T2.1 | 30min |
|
||||
| T2.4 | 定义 `application.proto`（SubmitApplication/RPC、ListApplications/RPC） | T2.1 | 30min |
|
||||
| T2.5 | 定义 `profile.proto`（GetProfile/RPC、UpdateProfile/RPC） | T2.1 | 30min |
|
||||
| T2.6 | 定义 `resume.proto`（GenOssSign/RPC、SaveResume/RPC） | T2.1 | 30min |
|
||||
| T2.7 | 定义 `chat.proto`（SendChat/RPC、GetHistory/RPC） | T2.1 | 30min |
|
||||
| T2.8 | protoc 生成 Go 代码 | T2.1 ~ T2.7 | 30min |
|
||||
|
||||
</details>
|
||||
|
||||
### 3.2 前置条件
|
||||
|
||||
- 阶段一已完成（T1.1 ~ T1.6）
|
||||
- protoc 编译器及 go plugin 插件已安装
|
||||
|
||||
### 3.3 验收标准
|
||||
|
||||
- [ ] `protoc --go_out=... --go-grpc_out=...` 在 `api/proto/v1/` 下编译通过
|
||||
- [ ] 生成的 Go 代码存在于两个服务的 `proto/gen/v1/` 目录
|
||||
- [ ] 所有 RPC 方法签名覆盖项目需求文档中的全部接口
|
||||
|
||||
> [!tip] Proto 设计最佳实践
|
||||
> - 每个 Service 对应一个 proto 文件，职责单一
|
||||
> - Request 和 Response 消息统一命名规范：`XxxRequest`、`XxxResponse`
|
||||
> - `common.proto` 中的 `CommonResponse{code, msg, data}` 作为所有响应的包装壳
|
||||
> - 字段使用 tag 编号，从 1 开始递增，预留扩展空间
|
||||
|
||||
## 四、阶段三：后端双服务开发
|
||||
|
||||
### 3.1 子阶段 3A：MySQL 数据库建表
|
||||
|
||||
> [!note] 进度追踪
|
||||
> - [ ] T3A.1 根据 ER 图设计 SQL DDL
|
||||
> - [ ] T3A.2 执行建表 + 插入测试种子数据
|
||||
|
||||
建表清单（对照 `db.md` 细化）：
|
||||
|
||||
| 表名 | 用途 | 关键字段 |
|
||||
|------|------|----------|
|
||||
| `users` | 用户表 | id, username, password_hash, role, created_at |
|
||||
| `jobs` | 岗位表 | id, creator_id, title, description, status, created_at |
|
||||
| `applications` | 投递记录表 | id, job_id, candidate_id, applied_at |
|
||||
| `profiles` | 候选人档案表 | id, user_id, name, phone, education, school, experience, skills |
|
||||
| `resumes` | 简历信息表 | id, profile_id, file_key, oss_url, created_at |
|
||||
| `chat_records` | AI对话历史表 | id, hr_id, question, ai_reply, created_at |
|
||||
|
||||
> [!note] 思考题
|
||||
> 为什么 `creator_id` 放在 jobs 表中而不是单独的 job_ownership 关联表？因为本系统架构轻量化，HR 仅管理本人发布的岗位，单字段外键足以表达这种一对一的归属关系。
|
||||
|
||||
### 3.2 子阶段 3B：Logic 核心业务服务
|
||||
|
||||
> [!note] 进度追踪
|
||||
> - [ ] T3B.1 gRPC Server 框架 + config 模块
|
||||
> - [ ] T3B.2 AuthService（注册/登录/JWT签发）
|
||||
> - [ ] T3B.3 JobService（岗位 CRUD + 创建者权限校验）
|
||||
> - [ ] T3B.4 ApplicationService（投递逻辑 + 校验拦截）
|
||||
> - [ ] T3B.5 ProfileService（候选人档案增改查）
|
||||
> - [ ] T3B.6 ResumeService + OSS signer（签名 URL 生成 + 文件头校验）
|
||||
> - [ ] T3B.7 ChatService（意图解析 → SQL查询 → Prompt拼接 → Eino推送 → 持久化）
|
||||
> - [ ] T3B.8 repository 层数据访问封装（6张表）
|
||||
> - [ ] T3B.9 converter 层 proto ↔ model 转换
|
||||
> - [ ] T3B.10 JWT 工具模块（签发 + 验证 + 角色提取）
|
||||
> - [ ] T3B.11 AI 模块封装（Eino Chat Engine + prompt 模板 + 意图解析器）
|
||||
> - [ ] T3B.12 Logic 服务独立启动测试
|
||||
|
||||
<details>
|
||||
<summary>📋 展开查看 Logic 详细任务表</summary>
|
||||
|
||||
| 编号 | 任务 | 前置依赖 | 耗时估计 |
|
||||
|------|------|----------|----------|
|
||||
| T3B.1 | 搭建 gRPC Server 框架 + config 模块 | T3A.2 | 1h |
|
||||
| T3B.2 | 实现 AuthService（注册/登录/JWT签发） | T3B.1 | 2h |
|
||||
| T3B.3 | 实现 JobService（岗位 CRUD + 创建者权限校验） | T3B.1 | 2h |
|
||||
| T3B.4 | 实现 ApplicationService（投递逻辑 + 校验拦截） | T3B.1, T3B.3 | 2h |
|
||||
| T3B.5 | 实现 ProfileService（候选人档案增改查） | T3B.1 | 1.5h |
|
||||
| T3B.6 | 实现 ResumeService + OSS signer（签名 URL 生成 + 文件头校验） | T3B.1 | 2h |
|
||||
| T3B.7 | 实现 ChatService（意图解析 → SQL查询 → Prompt拼接 → Eino推送 → 持久化） | T3B.1, T3A.2 | 2.5h |
|
||||
| T3B.8 | repository 层数据访问封装（6张表） | T3B.1 | 2h |
|
||||
| T3B.9 | converter 层 proto ↔ model 转换 | T2.8, T3B.8 | 1h |
|
||||
| T3B.10 | JWT 工具模块（签发 + 验证 + 角色提取） | T3B.1 | 1h |
|
||||
| T3B.11 | AI 模块封装（Eino Chat Engine + prompt 模板 + 意图解析器） | T3B.1 | 2h |
|
||||
| T3B.12 | Logic 服务独立启动测试 | T3B.2 ~ T3B.11 | 1h |
|
||||
|
||||
</details>
|
||||
|
||||
#### Logic 核心流程自查
|
||||
|
||||
- [ ] 用户注册时密码 bcrypt 加密存储
|
||||
- [ ] 登录成功签发 JWT（包含 userId + role）
|
||||
- [ ] 岗位编辑/下架时校验当前操作用户 == creator_id
|
||||
- [ ] 候选人投递时拦截：未完善资料或无简历 → 返回错误码
|
||||
- [ ] OSS 签名 URL 严格后缀白名单 (.pdf/.doc/.docx) + 文件头 Magic Number 校验
|
||||
- [ ] 简历不经过服务端缓存，客户端直传 OSS
|
||||
- [ ] AI 对话每条问答自动写入 chat_records 表
|
||||
|
||||
> [!danger] 验收红线
|
||||
> Logic 服务内所有业务逻辑只能通过 gRPC Server 暴露，Web 服务不得通过同工程内部函数直连调用。如果同一个 Go module 里直接 import service 包 = 架构违规。
|
||||
|
||||
### 3.3 子阶段 3C：Web 网关服务
|
||||
|
||||
> [!note] 进度追踪
|
||||
> - [ ] T3C.1 Gin 项目框架 + router 注册
|
||||
> - [ ] T3C.2 CORS 中间件（全局跨域处理）
|
||||
> - [ ] T3C.3 JWT 鉴权中间件（读取 Token + 角色校验）
|
||||
> - [ ] T3C.4 参数合法性校验中间件
|
||||
> - [ ] T3C.5 gRPC Client 连接池 + codec JSON 转换
|
||||
> - [ ] T3C.6 Auth Handler
|
||||
> - [ ] T3C.7 Job Handler
|
||||
> - [ ] T3C.8 Application Handler
|
||||
> - [ ] T3C.9 Profile Handler
|
||||
> - [ ] T3C.10 Resume Handler
|
||||
> - [ ] T3C.11 Chat Handler
|
||||
> - [ ] T3C.12 Web 服务独立启动测试
|
||||
|
||||
<details>
|
||||
<summary>📋 展开查看 Web 网关详细任务表</summary>
|
||||
|
||||
| 编号 | 任务 | 前置依赖 | 耗时估计 |
|
||||
|------|------|----------|----------|
|
||||
| T3C.1 | 搭建 Gin 项目框架 + router 注册 | T3B.12 | 1h |
|
||||
| T3C.2 | CORS 中间件（全局跨域处理） | T3C.1 | 30min |
|
||||
| T3C.3 | JWT 鉴权中间件（读取 Token + 角色校验） | T3B.10 | 1h |
|
||||
| T3C.4 | 参数合法性校验中间件 | T3C.1 | 1h |
|
||||
| T3C.5 | gRPC Client 连接池 + codec JSON 转换 | T3B.12 | 1.5h |
|
||||
| T3C.6 | Auth Handler（POST /api/auth/login, register） | T3C.5, T3B.2 | 1h |
|
||||
| T3C.7 | Job Handler（CRUD 路由映射到 gRPC） | T3C.5, T3B.3 | 1.5h |
|
||||
| T3C.8 | Application Handler | T3C.5, T3B.4 | 1h |
|
||||
| T3C.9 | Profile Handler | T3C.5, T3B.5 | 1h |
|
||||
| T3C.10 | Resume Handler（获取签名 URL 返回给前端） | T3C.5, T3B.6 | 1.5h |
|
||||
| T3C.11 | Chat Handler（AI 对话转发） | T3C.5, T3B.7 | 1.5h |
|
||||
| T3C.12 | Web 服务独立启动，用 curl/postman 测试 | T3C.6 ~ T3C.11 | 1h |
|
||||
|
||||
</details>
|
||||
|
||||
#### Web 端架构自查
|
||||
|
||||
- [ ] Handler 中没有任何核心业务逻辑——只有参数解析 + gRPC 调用转发
|
||||
- [ ] JWT 中间件在路由注册前挂载，未携带 Token 的请求一律返回 401
|
||||
- [ ] 所有 gRPC 调用都有 context deadline（防止阻塞）
|
||||
- [ ] 错误码统一通过 CommonResponse.code 传递
|
||||
|
||||
## 五、阶段四：前端一日冲刺
|
||||
|
||||
> [!tip] 技术选型确认
|
||||
> 前端统一使用 **React + Vite + TypeScript + Axios**，UI 组件库推荐 **Ant Design**（开箱即用、减少造轮子时间）。前端只负责页面渲染和接口请求，所有业务逻辑在后端处理。
|
||||
|
||||
### 4.1 核心策略：共享基础层 + 下午独立填页
|
||||
|
||||
两个前端共用了同一套后端 API 契约（`api/proto/v1/`），因此**不需要各自从零搭架子**。关键压缩思路：
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
subgraph Foundation["Foundation（共享基础层）"]
|
||||
A1["hr-frontend 脚手架初始化"] --> A2["user-frontend 脚手架初始化"]
|
||||
A2 --> A3["双方同步搭建: Router/Axios/AuthContext/布局组件"]
|
||||
A3 --> A4["Ant Design 主题配置"]
|
||||
end
|
||||
|
||||
subgraph Candidate["候选人用户端（独立完成）"]
|
||||
B1["公开岗位列表"] --> B2["登录注册"] --> B3["档案表单"] --> B4["OSS直传"] --> B5["投递记录"]
|
||||
end
|
||||
|
||||
subgraph HR["HR 管理端（独立完成）"]
|
||||
C1["登录注册"] --> C2["岗位CRUD"] --> C3["候选人列表"] --> C4["AI对话窗口"]
|
||||
end
|
||||
|
||||
A4 -.-> B1
|
||||
A4 -.-> C1
|
||||
```
|
||||
|
||||
| 模块 | 策略 | 复用收益 |
|
||||
|------|------|----------|
|
||||
| Foundation | 两个项目同时跑：Vite 初始化 + Router + Axios client + AuthContext + 布局组件 | 每个文件只写一次，两份代码各自 `cp -r` 起步，省去重复劳动 |
|
||||
| 候选人 / HR | 各自独立填充页面——候选人端 6 页 / HR 端 7 页，互不干扰 | 后端 API 已完成，前端只对接已有接口 |
|
||||
|
||||
### 4.2 Foundation 搭建
|
||||
|
||||
> [!note] 进度追踪
|
||||
> - [ ] T4.AM.1 hr-frontend 脚手架初始化 (`create-vite`)
|
||||
> - [ ] T4.AM.1b user-frontend 脚手架初始化 (`create-vite`)
|
||||
> - [ ] T4.AM.2 安装依赖 (antd, icons, react-router-dom)
|
||||
> - [ ] T4.AM.3 路由配置 + Layout 组件（hr: Sidebar/Header, user: Navbar/Footer）
|
||||
> - [ ] T4.AM.4 Axios client 封装（baseURL / interceptor / token 注入）
|
||||
> - [ ] T4.AM.5 AuthContext（useContext 管理 JWT，isAuthenticated / role 状态）
|
||||
> - [ ] T4.AM.6 Ant Design 全局主题 & 全局 CSS
|
||||
|
||||
<details>
|
||||
<summary>📋 展开查看详细任务表</summary>
|
||||
|
||||
| 编号 | 任务 | 耗时 | 说明 |
|
||||
|------|------|------|------|
|
||||
| T4.AM.1 | `npx create-vite hr-frontend --template react-ts` | 5min | 同步创建两个项目 |
|
||||
| T4.AM.1b | `npx create-vite user-frontend --template react-ts` | 5min | — |
|
||||
| T4.AM.2 | 安装依赖 (`antd`, `@ant-design/icons`, `react-router-dom`) | 10min | 两端同步操作 |
|
||||
| T4.AM.3 | 路由配置 + Layout 组件（hr: Sidebar/Header, user: Navbar/Footer） | 45min | 各自按风格定制 |
|
||||
| T4.AM.4 | Axios client 封装（baseURL / interceptor / token 注入） | 30min | 模板几乎相同，改 baseURL 即可 |
|
||||
| T4.AM.5 | AuthContext（useContext 管理 JWT，isAuthenticated / role 状态） | 30min | 两端复制 + 角色名差异 |
|
||||
| T4.AM.6 | Ant Design 全局主题 & 全局 CSS | 20min | hr 用深色主题, user 用浅色主题 |
|
||||
|
||||
</details>
|
||||
|
||||
#### AM 成果验证
|
||||
|
||||
- [ ] 两个 `npm run dev` 均能启动，显示空白布局框架
|
||||
- [ ] 路由切换正常，Axios 请求可发送到 `http://localhost:8080/api`
|
||||
|
||||
> [!note] 思考题
|
||||
> 为什么 AuthContext 只需要改"角色名"就可以复用？因为前后端的鉴权模型是一致的——都靠 JWT 中的 `role` 字段区分 HR/候选人。这个设计体现了"接口契约驱动开发"的思想：proto 定义了统一的用户身份模型，前端只需消费它。
|
||||
|
||||
### 4.3 候选人用户端
|
||||
|
||||
> [!note] 进度追踪
|
||||
> - [ ] T4.U.1 HomePage — 公开岗位列表（免登录浏览）
|
||||
> - [ ] T4.U.2 LoginPage + RegisterPage — 表单 + 提交到 `/api/auth/login`
|
||||
> - [ ] T4.U.3 JobDetailPage — 岗位详情 + 条件渲染投递按钮
|
||||
> - [ ] T4.U.4 SetupProfilePage — 结构化档案表单
|
||||
> - [ ] T4.U.5 ResumeUploadPage — OSS 签名 URL 直传组件
|
||||
> - [ ] T4.U.6 ApplicationPage + WarningModal — 投递记录 + 拦截弹窗
|
||||
|
||||
<details>
|
||||
<summary>📋 展开查看详细任务表</summary>
|
||||
|
||||
| 编号 | 任务 | 前置依赖 | 耗时 | 页面数 |
|
||||
|------|------|----------|------|--------|
|
||||
| T4.U.1 | HomePage：调用 `/api/jobs` 展示岗位卡片列表（免登录） | T4.AM | 40min | 1 |
|
||||
| T4.U.2 | LoginPage + RegisterPage：表单 + 提交到 `/api/auth/login` | T4.AM | 40min | 2 |
|
||||
| T4.U.3 | JobDetailPage：岗位详情 + 条件渲染投递按钮（已登录 && 有档案 && 有简历） | T4.U.1 | 40min | 1 |
|
||||
| T4.U.4 | SetupProfilePage：Ant Design Form 表格单（姓名/电话/学历/院校/经历/技能） | T4.AM | 30min | 1 |
|
||||
| T4.U.5 | ResumeUploadPage：选择文件 → 调 `/api/resume/upload` 拿签名 URL → 客户端 PUT 到 OSS | T4.AM, T3C.10 | 50min | 1 |
|
||||
| T4.U.6 | ApplicationPage + WarningModal：投递记录 + 拦截弹窗 | T4.AM | 30min | 1+1 |
|
||||
|
||||
</details>
|
||||
|
||||
#### 候选人端关键交互逻辑
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A["游客打开 /user/"] --> B["查看岗位列表"]
|
||||
B --> C["点击投递按钮"]
|
||||
C --> D{"是否已登录？"}
|
||||
D -->|"否"| E["跳转 /user/login"]
|
||||
D -->|"是"| F{"是否完善档案？"}
|
||||
F -->|"否"| G["提示跳转到 /user/profile/setup"]
|
||||
F -->|"是"| H{"是否有合规简历？"}
|
||||
H -->|"否"| I["提示 /user/resume/upload<br/>PDF/DOC/DOCX 格式校验"]
|
||||
H -->|"是"| J["发送 POST /api/applications"]
|
||||
J --> K["投递成功 ✅"]
|
||||
```
|
||||
|
||||
### 4.4 HR 管理端
|
||||
|
||||
> [!note] 进度追踪
|
||||
> - [ ] T4.H.1 LoginPage + RegisterPage（HR 账号体系）
|
||||
> - [ ] T4.H.2 Dashboard/HomePage — 工作台概览
|
||||
> - [ ] T4.H.3 JobListPage — 本人岗位列表（分页 + 搜索）
|
||||
> - [ ] T4.H.4 JobEditPage — 新建/编辑岗位表单
|
||||
> - [ ] T4.H.5 CandidatePage — 岗位下候选人列表
|
||||
> - [ ] T4.H.6 ProfileViewPage — 候选人结构化档案只读展示
|
||||
> - [ ] T4.H.7 ChatPage — AI 智能对话窗口
|
||||
|
||||
<details>
|
||||
<summary>📋 展开查看详细任务表</summary>
|
||||
|
||||
| 编号 | 任务 | 前置依赖 | 耗时 | 页面数 |
|
||||
|------|------|----------|------|--------|
|
||||
| T4.H.1 | LoginPage + RegisterPage（HR 账号体系） | T4.AM | 30min | 2 |
|
||||
| T4.H.2 | Dashboard/HomePage：工作台概览（数据卡片） | T4.AM | 30min | 1 |
|
||||
| T4.H.3 | JobListPage：本人岗位列表（Ant Design Table + 分页 + 搜索） | T4.AM | 50min | 1 |
|
||||
| T4.H.4 | JobEditPage：新建/编辑岗位表单 | T4.AM | 40min | 1 |
|
||||
| T4.H.5 | CandidatePage：岗位下候选人列表 + 跳转档案详情页 | T4.AM | 50min | 1 |
|
||||
| T4.H.6 | ProfileViewPage：候选人结构化档案只读展示 | T4.H.5 | 30min | 1 |
|
||||
| T4.H.7 | ChatPage：AI 智能对话窗口（消息气泡 + 历史加载） | T4.AM, T3C.11 | 80min | 1 |
|
||||
|
||||
</details>
|
||||
|
||||
#### ChatPage 核心交互时序
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant P as ChatPage
|
||||
participant S as ChatContext
|
||||
participant A as Axios
|
||||
participant W as Web-Gin
|
||||
|
||||
Note over P,W: 页面加载时自动拉历史
|
||||
P->>S: useEffect 触发
|
||||
S->>A: GET /api/chat/history
|
||||
A->>W: 带 JWT
|
||||
W-->>A: 历史消息数组
|
||||
A-->>S: state.push(...records)
|
||||
S-->>P: 渲染对话流
|
||||
|
||||
Note over P,W: 用户输入新提问
|
||||
P->>A: POST /api/chat/messages {question}
|
||||
A->>W: 经 gRPC 转发到 Logic
|
||||
W-->>A: {reply, records[]}
|
||||
A-->>S: 追加 AI 回复
|
||||
S-->>P: 自动滚动到底部
|
||||
```
|
||||
|
||||
### 4.5 收尾
|
||||
|
||||
> [!note] 进度追踪
|
||||
> - [ ] T4.Z.1 两端 `npm run build` 验证无编译错误
|
||||
> - [ ] T4.Z.2 检查 .env 是否正确指向后端地址
|
||||
> - [ ] T4.Z.3 git add + commit 本阶段变更
|
||||
|
||||
> [!warning] 前端权限边界
|
||||
> 前端只做视觉展示和跳转控制。**真正的权限校验必须发生在后端**。例如：即使前端显示了投递按钮，后端也应该再次校验候选人是否满足条件；不应依赖前端隐藏按钮来保护安全。验收时评委可能会故意绕过前端直接调接口测试。
|
||||
|
||||
> [!tip] 加速技巧速查
|
||||
> - Ant Design 的 `Form` + `Input` + `Select` 可以直接粘贴文档示例修改
|
||||
> - 岗位列表复用同一个 `JobCard` 组件（候选人端和 HR 端都可以引用）
|
||||
> - Axios interceptor 写一次就能用在两个项目中
|
||||
> - 如果某个页面实在写不完，先用 `console.log` 占位，确保核心功能优先上线
|
||||
|
||||
## 六、阶段五：前后端联调与自测
|
||||
|
||||
> [!note] 进度追踪
|
||||
> - [ ] T5.1 全链路跑通：注册 → 登录 → 岗位发布 → 浏览
|
||||
> - [ ] T5.2 OSS 签名上传端到端测试（候选人端直传）
|
||||
> - [ ] T5.3 AI 对话完整流程测试（提问 → 数据查询 → 回答 → 历史加载）
|
||||
> - [ ] T5.4 权限隔离测试（非创建者操作他人岗位应被拒绝）
|
||||
> - [ ] T5.5 文件格式拦截测试（上传图片/TXT应为非法）
|
||||
> - [ ] T5.6 游客 vs 登录态功能边界测试
|
||||
> - [ ] T5.7 Bug 修复与体验优化
|
||||
|
||||
### 6.1 详细任务清单
|
||||
|
||||
| 编号 | 任务 | 前置依赖 | 耗时估计 |
|
||||
|------|------|----------|----------|
|
||||
| T5.1 | 全链路跑通：注册 → 登录 → 岗位发布 → 浏览 | T4.Z.3 | 2h |
|
||||
| T5.2 | OSS 签名上传端到端测试（候选人端直传） | T5.1 | 2h |
|
||||
| T5.3 | AI 对话完整流程测试（提问 → 数据查询 → 回答 → 历史加载） | T5.1 | 2h |
|
||||
| T5.4 | 权限隔离测试（非创建者操作他人岗位应被拒绝） | T5.1 | 1h |
|
||||
| T5.5 | 文件格式拦截测试（上传图片/TXT应为非法） | T5.2 | 1h |
|
||||
| T5.6 | 游客 vs 登录态功能边界测试 | T5.1 | 1h |
|
||||
| T5.7 | Bug 修复与体验优化 | T5.1 ~ T5.6 | 2h |
|
||||
|
||||
### 6.2 验收 Checklist
|
||||
|
||||
对照以下每一项逐项打勾：
|
||||
|
||||
- [ ] gRPC 分层：Web 与 Logic 之间全部通过 gRPC 调用，无同工程内部函数调用
|
||||
- [ ] OSS 签名 URL：文件不落地本地，客户端直传 OSS
|
||||
- [ ] Eino 框架：使用了 Eino 封装的 Chat，非裸写 HTTP
|
||||
- [ ] JWT 鉴权：HR 只能管理自己发布的岗位，候选人未完善资料不可投递
|
||||
- [ ] AI 对话持久化：每条问答对入 MySQL，刷新页面自动加载历史上下文
|
||||
- [ ] 双端前端独立运行：hr-frontend 和 user-frontend 各自 `npm run dev` 均可启动
|
||||
- [ ] 四个源码目录完整、三个文档文件齐全
|
||||
|
||||
## 七、阶段六：视频录制与提交
|
||||
|
||||
> [!note] 进度追踪
|
||||
> - [ ] T6.1 撰写 answer.md（拓展设计方案：OpenClaw/Hermes 集成思路）
|
||||
> - [ ] T6.2 完善 README.md（启动部署指南 + 项目亮点）
|
||||
> - [ ] T6.3 完善 api.md（前后端接口说明）
|
||||
> - [ ] T6.4 完善 db.md（数据库设计文档补充）
|
||||
> - [ ] T6.5 整理代码仓库（检查 .gitignore、清理临时文件）
|
||||
> - [ ] T6.6 录制演示视频（原生实操、口述两大核心技术点）
|
||||
> - [ ] T6.7 提交至 KDoc 表单
|
||||
|
||||
### 7.1 详细任务清单
|
||||
|
||||
| 编号 | 任务 | 耗时估计 |
|
||||
|------|------|----------|
|
||||
| T6.1 | 撰写 answer.md（拓展设计方案：OpenClaw/Hermes 集成思路） | 2h |
|
||||
| T6.2 | 完善 README.md（启动部署指南 + 项目亮点） | 1.5h |
|
||||
| T6.3 | 完善 api.md（前后端接口说明） | 1.5h |
|
||||
| T6.4 | 完善 db.md（数据库设计文档补充） | 1h |
|
||||
| T6.5 | 整理代码仓库（检查 .gitignore、清理临时文件） | 1h |
|
||||
| T6.6 | 录制演示视频（原生实操、口述两大核心技术点） | 2h |
|
||||
| T6.7 | 提交至 KDoc 表单 | 30min |
|
||||
|
||||
### 7.2 视频录制脚本大纲
|
||||
|
||||
| 时间段 | 内容 | 口述要点 |
|
||||
|--------|------|----------|
|
||||
| 0:00-0:30 | 开场 + 服务启动演示 | "我现在依次启动 Logic 服务和 Web 网关服务..." |
|
||||
| 0:30-2:00 | 候选人端操作流程 | "候选人浏览岗位、注册、完善档案、上传简历、投递..." |
|
||||
| 2:00-3:00 | 口述核心技术点①：gRPC 两层架构 | "Web 网关接收 HTTP 请求后，通过 gRPC 远程调用 Logic 服务...这两个是独立进程..." |
|
||||
| 3:00-4:00 | 口述核心技术点②：OSS 签名 URL | "简历文件先获取签名URL，然后客户端直传 OSS，服务端零缓存..." |
|
||||
| 4:00-5:30 | HR 管理端操作流程 | "HR 登录、发布岗位、查看候选人、AI 对话..." |
|
||||
| 5:30-6:30 | AI 对话演示 | "输入自然语言提问，后端查询 MySQL 真实数据，通过 Eino 推送大模型..." |
|
||||
| 6:30-7:00 | 总结与结尾 | 简要说明个人开发收获和优化方向 |
|
||||
|
||||
> [!important] 视频硬性要求
|
||||
> - **禁止剪辑拼接**：一次录完，保证画面真实
|
||||
> - **全程配语音解说**：不能无声黑屏
|
||||
> - **必录两大技术点口述**：gRPC 分层调用逻辑、OSS 签名 URL 安全上传下载
|
||||
> - **文件命名**：`姓名_学号_全栈大作业.mp4`
|
||||
|
||||
## 八、风险识别与应对
|
||||
|
||||
| 风险 | 影响范围 | 概率 | 应对措施 |
|
||||
|------|----------|------|----------|
|
||||
| OSS 平台注册审核慢 | 整个项目 | 中 | 提前注册，使用 MinIO 本地替代方案作为兜底 |
|
||||
| Eino 框架学习成本超预期 | AI 对话模块 | 中 | 官方文档优先，只使用基础 Chat 组件，不做复杂编排 |
|
||||
| Protobuf 字段频繁变更 | 前后端同步 | 高 | Proto 先行、冻结接口后再写业务代码；做好注释 |
|
||||
| gRPC 调试困难 | 后端通信 | 中 | 启用 grpcurl 命令行工具进行 RPC 调用调试 |
|
||||
| 前端样式适配耗时过长 | UI 呈现 | 中 | 使用现成 UI 组件库（Ant Design），不自研 CSS |
|
||||
| JWT Token 过期处理遗漏 | 用户体验 | 低 | 初期可不实现自动刷新，手动重新登录即可 |
|
||||
|
||||
## 九、里程碑检查点
|
||||
|
||||
> [!note] 里程碑进度追踪
|
||||
> 点击以下复选框标记里程碑完成情况：
|
||||
> - [ ] **M0** — 环境就绪
|
||||
> - [ ] **M1** — Proto 冻结
|
||||
> - [ ] **M2** — 后端可独立运行
|
||||
> - [ ] **M3** — 双端前端完成
|
||||
> - [ ] **M4** — 全链路联调通过
|
||||
> - [ ] **M5** — 视频已录制
|
||||
> - [ ] **M6** — 正式提交
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
M0["环境就绪<br/>阶段一"] --> M1["Proto 冻结<br/>阶段二"]
|
||||
M1 --> M2["后端可独立运行<br/>阶段三"]
|
||||
M2 --> M3["双端前端完成<br/>阶段四"]
|
||||
M3 --> M4["全链路联调通过<br/>阶段五"]
|
||||
M4 --> M5["视频已录制<br/>待提交"]
|
||||
M5 --> M6["正式提交<br/>KDoc表单"]
|
||||
|
||||
classDef done fill:#c8e6c9;
|
||||
classDef current fill:#fff9c4;
|
||||
classDef future fill:#eceff1;
|
||||
class M0,M1,M2,M3,M4 done;
|
||||
class M5 current;
|
||||
class M6 future;
|
||||
```
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[大作业项目要求]] — 作业完整需求文档
|
||||
- [[思维导图]] — 双端 gRPC HR 系统的知识体系与核心考点
|
||||
- [[工程结构]] — 详细的仓库目录结构与代码组织
|
||||
@@ -13,8 +13,8 @@ create time: 2026-05-11 16:00
|
||||
|
||||
### 入门
|
||||
|
||||
| # | 笔记 | 读它如果... |
|
||||
|---|------|------------|
|
||||
| # | 笔记 | 读它如果... |
|
||||
| ----------------------------------------------------------------- | ------------------------------ | ---------------------- |
|
||||
| [[hhs/gRPC/3. 服务端实现/08-Server 搭建与注册/01-Hello World 最小可运行 Server]] | **第一课**：三段式模板，从零搭起一个能跑的 server | 你是 gRPC 新手，想先看到"能跑的代码" |
|
||||
|
||||
### 核心概念
|
||||
|
||||
@@ -1,20 +1,22 @@
|
||||
---
|
||||
tags: [gRPC, Go, Server, Best Practice]
|
||||
create time: 2026-05-13 14:30
|
||||
create time: 2026-05-15 10:00
|
||||
---
|
||||
|
||||
# Unimplemented 零-Stub 模式
|
||||
|
||||
## 概述
|
||||
|
||||
`UnimplementedXxxServer` 是 protoc-gen-go 为每个 gRPC service 自动生成的"空实现"结构体。通过嵌入它到自定义的 Service 结构体中，开发者只需编写实际需要的方法，其余方法自动获得 `codes.Unimplemented` 默认响应——这是一种兼顾开发便利性与接口契约安全的 Go 语言惯用模式。
|
||||
`UnimplementedXxxServer` 是 `protoc-gen-go` 为每个 gRPC service 自动生成的"空实现"结构体。通过将其嵌入自定义 Service 结构体，开发者只需编写实际需要的方法，未覆写的方法自动返回 `codes.Unimplemented` 错误——这是一种兼顾开发便利性与接口契约安全的 Go 语言惯用模式。
|
||||
|
||||
> [!question] 如果没有这个机制会怎样？
|
||||
> 想象你实现了三个 RPC method，后来 proto 新增了一个，编译器不报错——你的新方法永远不会被调用，直到线上某个 client 发出请求后才暴露出 Bug。这就是"静默失败"陷阱。
|
||||
> 假设你实现了三个 RPC method，后来 proto 新增了一个。**编译器不会报错**——你的新方法永远不会被调用，直到线上某个 client 发出请求后才暴露出 Bug。这就是"静默失败"陷阱。
|
||||
|
||||
核心思想：**把运行时 Bug 提前到编译期发现**。
|
||||
|
||||
## Protobuf 生成的代码结构
|
||||
|
||||
当你写一个 proto service：
|
||||
当你定义一个 proto service：
|
||||
|
||||
```proto
|
||||
service UserService {
|
||||
@@ -23,12 +25,12 @@ service UserService {
|
||||
}
|
||||
```
|
||||
|
||||
protoc 会生成三类关键代码：
|
||||
protoc 生成三类关键代码：
|
||||
|
||||
| 生成物 | 作用 |
|
||||
|--------|------|
|
||||
| `UserServiceServer` interface | 你必须实现的方法集合 |
|
||||
| `UnimplementedUserServiceServer` struct | 所有方法都返回 `Unimplemented` 错误的默认实现 |
|
||||
| `UserServiceServer` interface | 你必须满足的方法集合 |
|
||||
| `UnimplementedUserServiceServer` struct | 所有方法都返回 `codes.Unimplemented` 错误的默认实现 |
|
||||
| `RegisterUserServiceServer()` 函数 | 将你的实现注册到 server 分发表 |
|
||||
|
||||
重点看 `UserServiceServer` interface 的定义：
|
||||
@@ -41,13 +43,14 @@ type UserServiceServer interface {
|
||||
}
|
||||
```
|
||||
|
||||
`mustEmbedUnimplementedUserServiceServer()` 是一个**无参数的空方法**。它的存在让 interface 成为封闭类型——其他任何想满足此接口的类型都必须显式嵌入 `UnimplementedUserServiceServer`，否则编译期直接拦截。这是 Go 社区著名的"封闭接口"（unexported method trick）反模式之一，但在 protobuf 场景下它是有意为之的设计。
|
||||
`mustEmbedUnimplementedUserServiceServer()` 是一个无参空方法。它让 interface 成为**封闭类型**——任何想满足此接口的类型都必须显式嵌入 `UnimplementedUserServiceServer`，否则编译期直接拦截。这是 Go 社区著名的"封闭接口"（unexported method trick）设计手法，在 protobuf 场景下是有意为之。
|
||||
|
||||
## 为什么必须嵌入
|
||||
> [!note] 为什么叫 "closed set of methods"？
|
||||
> Go 的 interface 是 implicit（隐式实现），正常情况下你可以随时"默默"实现一个新接口。但 protobuf 通过注入一个只能由生成的 struct 提供的方法，把这个隐式契约变成了**显式嵌入**——你必须主动写下一行 `pb.UnimplementedUserServiceServer`，这种"被迫直面"就是安全感的来源。
|
||||
|
||||
### 1. 减少样板代码
|
||||
## 嵌入用法
|
||||
|
||||
嵌入后只需要实现你需要的那些方法：
|
||||
嵌入后只需实现需要的业务方法：
|
||||
|
||||
```go
|
||||
type userService struct {
|
||||
@@ -62,89 +65,119 @@ func (s *userService) CreateUser(ctx context.Context, req *pb.CreateUserRequest)
|
||||
return &pb.CreateUserResponse{Id: generatedId}, nil
|
||||
}
|
||||
|
||||
// GetUser can be omitted — UnimplementedUserServiceServer returns the default error:
|
||||
// GetUser 不写 — UnimplementedUserServiceServer 自动返回：
|
||||
// status.Error(codes.Unimplemented, "method GetUser not implemented")
|
||||
```
|
||||
|
||||
### 2. Proto 新增 RPC Method → 编译期告警
|
||||
### Proto 新增 Method → 编译期告警
|
||||
|
||||
这是该模式最大的价值。假设后续你在 proto 里加了一个方法：
|
||||
这是该模式最大的价值。**先回答一个疑惑**：proto 新增了 `DeleteUser`，重新运行 protoc 后 `UnimplementedUserServiceServer` 自身也会多出对应的默认实现，你的嵌入结构体照样能编译通过——那为什么说有风险前置？
|
||||
|
||||
```proto
|
||||
service UserService {
|
||||
rpc CreateUser(...) returns (...);
|
||||
rpc GetUser(...) returns (...);
|
||||
rpc DeleteUser(...) returns (...); // ← 新增
|
||||
}
|
||||
```
|
||||
原因在于两个实际场景：
|
||||
|
||||
重新运行 protoc 后，`UserServiceServer` interface 会多出 `DeleteUser` 签名。**此时编译就会失败**：
|
||||
**场景 A：protoc 重新生成后忘记更新依赖**
|
||||
如果你在同一份代码库里只改了 proto 文件，却忘了对所有 micro-service 跑 protoc，那些没更新的 service 就会报编译错误：
|
||||
|
||||
```
|
||||
cannot use &userService{} as UserServiceServer:
|
||||
missing method DeleteUser in receiver type userService
|
||||
missing method DeleteUser in receiver type userService
|
||||
```
|
||||
|
||||
从"线上偶发 Bug"变成了"提交前就发现"——把风险前置到了编译期。
|
||||
CI 的编译检查会直接拦住——**某个服务漏跑 protoc**，而不是等到线上被调用的时候才发现这个方法从未被实现。
|
||||
|
||||
### 3. 强制接口契约意识
|
||||
**场景 B：忘记嵌入 → 退化回普通接口**
|
||||
如果不 embed `UnimplementedXxxServer`，proto 新增 method 时编译器照样不拦你。新方法永远不会被调用，直到线上某个 client 触发了它——这就退化成了"没这个机制之前"的样子。这也是为什么"正确嵌入"是这套模式生效的前提。
|
||||
|
||||
如果不用 embed，你可以"选择性实现"——只有某些方法、其他全忽略。这会导致服务方和客户端对接口理解不一致。Zero-stub 模式强迫每次新增 method 时都做一次有意识的决策：**实现它**，还是保持 Unimplemented？
|
||||
---
|
||||
|
||||
## 与反射型语言的对比
|
||||
> [!question] 那"强制接口契约意识"怎么理解？
|
||||
>
|
||||
> 正确用法下，Proto 新增 method 后，`UnimplementedXxxServer` 也会跟着长出新的兜底实现，编译是**通过的**。但这正是设计者想要的效果：
|
||||
> - **不强制你立刻实现**（不影响正常请求）
|
||||
> - **但强制你在 protoc 重新生成的那一刻"看到"变更**
|
||||
> - 从此时起你有两次决策机会：① 跑 protoc 时意识到契约变了；② 决定是否要把 `codes.Unimplemented` 替换成真实逻辑
|
||||
> - 对比非类型安全语言（Java 等），新方法可以永远不被实现且永远不被发现——Go 版本至少让每次 proto 变更都变得**可追踪**
|
||||
|
||||
在 Java 等语言中，gRPC 通常要求你继承一个基类（如 `UserServiceImplBase`），效果类似：
|
||||
## 嵌入策略对比
|
||||
|
||||
```java
|
||||
public class UserServiceImpl extends UserServiceImplBase {
|
||||
@Override
|
||||
public void createUser(..., StreamObserver observer) {
|
||||
// 只重写需要的
|
||||
}
|
||||
// getUser 自动走父类的 Unimplemented
|
||||
不同语言的 gRPC 框架提供了类似的保底机制，但 Go 的嵌入方式有其独特优势：
|
||||
|
||||
| 维度 | Go（嵌入） | Java / C++（继承基类） | Python（抽象基类） |
|
||||
|------|-----------|----------------------|-------------------|
|
||||
| **语法** | `struct` 嵌入 | 继承 `ServiceImplBase` | 继承 `Servicer` + `@abc.abstractmethod` |
|
||||
| **单继承限制** | 无（可嵌多个类型） | 有 | 有 |
|
||||
| **方法优先级控制** | 嵌入顺序决定 | 虚函数重写 | MRO 决定 |
|
||||
| **扩展性** | 可同时混入 store、logger 等依赖 | 只能通过构造函数传递 | 同上 |
|
||||
|
||||
Go 版本的优势在于**嵌入比继承更灵活**——可以同时嵌入多个类型、控制方法优先级（离当前结构体越近优先匹配），并且没有单继承限制。
|
||||
|
||||
## Streaming RPC 下的行为
|
||||
|
||||
上面的例子都是 unary RPC。对于 streaming RPC，behavior 完全一致：
|
||||
|
||||
```go
|
||||
type MessageService struct {
|
||||
pb.UnimplementedMessageServiceServer
|
||||
}
|
||||
|
||||
// 只实现 stream-send 的场景
|
||||
func (s *MessageService) StreamMessages(req *StreamRequest, ss grpc.ServerStream) error {
|
||||
for i := 0; i < req.Count; i++ {
|
||||
if err := ss.SendMsg(&StreamResponse{Data: fmt.Sprintf("msg-%d", i)}); err != nil {
|
||||
return status.Errorf(codes.Internal, "send failed: %v", err)
|
||||
}
|
||||
}
|
||||
return nil
|
||||
}
|
||||
|
||||
// BidirectionalStreaming 不写 → 自动返回 codes.Unimplemented
|
||||
```
|
||||
|
||||
Go 版本的优势在于**嵌入比继承更灵活**——你可以同时嵌入多个类型、控制方法优先级（离当前结构体越近优先匹配），并且没有单继承限制。
|
||||
关键点：
|
||||
|
||||
- UnimplementedStub 对 unary、server-streaming、client-streaming、bidirectional-streaming **统一处理**
|
||||
- Streaming handler 的错误返回值仍然是 `error`，未覆写时同样走 `codes.Unimplemented`
|
||||
- 如果你在 CI 中有编译检查，streaming 方法的遗漏也能被捕获
|
||||
|
||||
## 执行流程图解
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
Client["Client RPC Call"] --> Lookup["Server 查找 dispatch table"]
|
||||
Client["Client RPC Call"] --> Lookup["Server dispatch table"]
|
||||
Lookup --> Found{"Method 是否被覆写？"}
|
||||
Found -->|"是"| Handler["Handler 执行业务逻辑"]
|
||||
Found -->|"否"| Fallback["UnimplementedStub<br/>codes.Unimplemented 错误"]
|
||||
Found -->|"否"| Fallback["UnimplementedStub<br/>codes.Unimplemented"]
|
||||
|
||||
Handler --> Resp["Response to Client"]
|
||||
Fallback --> Resp
|
||||
|
||||
ProtoChanged["Proto 新增 Method"] --> GenCode["Protoc 重新生成"]
|
||||
GenCode --> CompileErr["userService 缺少新方法，编译失败 ✅"]
|
||||
GenCode --> AllUpdated["所有 service 同步更新<br/>Embed 自动继承新方法，编译通过"]
|
||||
GenCode --> PartialUpdate["部分 service 漏跑 protoc<br/>CI 拦截 ✅"]
|
||||
|
||||
style Client fill:#E3F2FD,stroke:#1976D2
|
||||
style Handler fill:#A8E6CF,stroke:#2E7D32
|
||||
style Fallback fill:#FFB3BA,stroke:#C62828
|
||||
style CompileErr fill:#FFF3E0,color:#000,stroke:#E65100
|
||||
style AllUpdated fill:#FFF3E0,color:#000,stroke:#E65100
|
||||
style PartialUpdate fill:#FFF3E0,color:#000,stroke:#E65100
|
||||
```
|
||||
|
||||
## 实际使用中的注意事项
|
||||
|
||||
> [!warning] 不要手动实现 Unimplemented 方法
|
||||
>
|
||||
> 如果在自己的结构体中也定义了同名 method（比如不小心写了 `MustEmbedUnimplementedUserServiceServer()`），它会覆盖嵌入类型的空方法。虽然功能上不影响（interface 检查只看是否存在），但语义混乱，应避免。
|
||||
|
||||
如果你在自己的结构体中也定义了一个同名 method（比如不小心写了 `func (s *userService) MustEmbedUnimplementedUserServiceServer()`），它会**覆盖**嵌入类型的空方法。虽然功能上不影响（interface 检查只看是否存在），但语义混乱，应避免。
|
||||
|
||||
> [!tip] 如何快速确认某个 Service 的所有方法都被覆盖了？
|
||||
|
||||
可以用 IDE 的 "implement interface" 功能列出未实现的方法，或者写一个简单的 compile test：
|
||||
|
||||
```go
|
||||
var _ pb.UserServiceServer = (*userService)(nil) // 编译期检查
|
||||
```
|
||||
|
||||
加上这一行后，任何遗漏的方法都会在这句编译报错，适合作为 CI 的一部分。
|
||||
|
||||
## 常见陷阱
|
||||
> [!warning] embed vs pointer embed 的选择
|
||||
>
|
||||
> gRPC 生成的 `UnimplementedXxxServer` **值类型和指针类型都可以嵌入**，但效果不同：
|
||||
>
|
||||
> | 嵌入方式 | `*userService` 是否满足接口 | 说明 |
|
||||
> |---------|---------------------------|------|
|
||||
> | `pb.UnimplementedXxxServer`（值） | `*userService` ✅ | 推荐，指针接收者可调用值方法 |
|
||||
> | `*pb.UnimplementedXxxServer`（指针） | `*userService` ✅ 且 `userService` ❌ | 仅指针满足接口 |
|
||||
>
|
||||
> **最佳实践**: 大多数 gRPC server 方法签名是 `func (s *Service) Method(...)`，所以嵌入值类型的 `Unimplemented` 即可同时支持两种调用方式。
|
||||
|
||||
> [!danger] 嵌入顺序决定方法优先级
|
||||
>
|
||||
@@ -157,46 +190,38 @@ var _ pb.UserServiceServer = (*userService)(nil) // 编译期检查
|
||||
> }
|
||||
> ```
|
||||
>
|
||||
> 养成**将 Unimplemented 嵌入放在最后**的习惯，避免意外覆盖：
|
||||
> 养成**将 Unimplemented 嵌入放在最后**的习惯：
|
||||
>
|
||||
> ```go
|
||||
> type userService struct {
|
||||
> *UserStore // 业务依赖先放前面
|
||||
> someHelper // 工具类
|
||||
> logger // 工具类
|
||||
> pb.UnimplementedUserServiceServer // 永远放最后
|
||||
> }
|
||||
> ```
|
||||
|
||||
> [!warning] `embed` vs `pointer embed` 的选择
|
||||
>
|
||||
> gRPC 生成的 `UnimplementedXxxServer` **值类型和指针类型都可以嵌入**，但效果不同：
|
||||
>
|
||||
> | 嵌入方式 | `*userService` 是否满足接口 | 说明 |
|
||||
> |---------|---------------------------|------|
|
||||
> | `pb.UnimplementedXxxServer`（值） | `*userService` ✅ | 推荐，指针接收者可调用值方法 |
|
||||
> | `*pb.UnimplementedXxxServer`（指针） | `*userService` ✅ 且 `userService` ❌ | 仅指针满足接口 |
|
||||
>
|
||||
> **最佳实践**: 大多数 gRPC server 方法签名是 `func (s *Service) Method(...)`，所以用指针 receiver。嵌入值类型的 `Unimplemented` 即可同时支持两种调用方式。
|
||||
|
||||
## Server 集成示例
|
||||
|
||||
下面是一个完整的、可直接运行的 Server 搭建片段，展示 UnimplementedStub 在整个链路中的位置：
|
||||
下面展示 UnimplementedStub 在整个服务链路中的位置（核心逻辑已简化）：
|
||||
|
||||
```go
|
||||
package server
|
||||
|
||||
import (
|
||||
"context"
|
||||
"fmt"
|
||||
"log"
|
||||
|
||||
"google.golang.org/grpc"
|
||||
"google.golang.org/grpc/codes"
|
||||
"google.golang.org/grpc/status"
|
||||
pb "your/proto/package"
|
||||
)
|
||||
|
||||
// UserServiceImpl — 只需实现实际需要的方法
|
||||
type UserServiceImpl struct {
|
||||
store *UserStore // 业务依赖
|
||||
pb.UnimplementedUserServiceServer // 放最后
|
||||
store *UserStore // 业务依赖
|
||||
pb.UnimplementedUserServiceServer // 永远放最后
|
||||
}
|
||||
|
||||
func (s *UserServiceImpl) CreateUser(ctx context.Context, req *pb.CreateUserRequest) (*pb.CreateUserResponse, error) {
|
||||
@@ -222,9 +247,39 @@ func Register(srv *grpc.Server, store *UserStore) {
|
||||
```
|
||||
|
||||
关键要点：
|
||||
- `RegisterUserServiceServer()` 内部会校验你传入的类型是否实现了 `UserServiceServer` interface
|
||||
|
||||
- `RegisterUserServiceServer()` 内部会校验传入的类型是否实现了 `UserServiceServer` interface
|
||||
- 由于 `UnimplementedUserServiceServer` 提供了所有方法的默认实现，你只需编写实际需要的 method
|
||||
- Proto 新增 method → protoc 重新生成 → 编译失败 → **有意识的决策点**
|
||||
- Proto 新增 method → protoc 重新生成 → **变更暴露** → 有意识的决策点（是否把 `codes.Unimplemented` 替换成真实逻辑）
|
||||
|
||||
## 常见排错
|
||||
|
||||
> [!bug] 忘记 embed → "missing method xxx" 编译错误
|
||||
>
|
||||
> 如果你看到类似下面的错误，首先检查是否忘写了嵌入行：
|
||||
>
|
||||
> ```
|
||||
> cannot use &userService{} as UserServiceServer:
|
||||
> missing method CreateUser in receiver type userService
|
||||
> ```
|
||||
>
|
||||
> 确认嵌入 `pb.UnimplementedXxxServer` 后即可解决。
|
||||
|
||||
> [!bug] embed 的是指针而不是值 → `userService` 类型不满足接口
|
||||
>
|
||||
> ```go
|
||||
> type userService struct {
|
||||
> *pb.UnimplementedUserServiceServer // 指针嵌入
|
||||
> }
|
||||
> var _ UserServiceServer = &userService{} // ✅
|
||||
> var _ UserServiceServer = userService{} // ❌ compile error
|
||||
> ```
|
||||
>
|
||||
> 如果你的某些代码以值类型传 service，建议改用值嵌入。
|
||||
|
||||
> [!bug] 自定义方法与嵌入类型冲突
|
||||
>
|
||||
> 如果你在结构体上手动定义了 `mustEmbedUnimplementedUserServiceServer()` 或其他与嵌入类型同名的方法，它会在方法解析时**遮蔽**嵌入类型的方法——虽然通常不会影响最终行为，但会造成混淆和潜在 bug。
|
||||
|
||||
## 关联笔记
|
||||
|
||||
|
||||
@@ -166,6 +166,8 @@ log.Printf("Response headers: Allow-Origin=%s", c.Writer.Header().Get("Access-Co
|
||||
|
||||
#### 场景 4：Nginx / 反向代理挡住了 CORS header
|
||||
|
||||
> 详细的 Nginx 反向代理处理跨域的三种方案，详见 [[hzh/DEV/跨域问题调试/nginx-reverse-proxy-cors]]。
|
||||
|
||||
当你使用 Nginx 做反向代理时，它默认会过滤掉上游没有明确声明的 header。
|
||||
|
||||
```nginx
|
||||
@@ -264,6 +266,7 @@ export default {
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[hzh/DEV/跨域问题调试/nginx-reverse-proxy-cors]] — Nginx 反向代理处理跨域的三种方案
|
||||
- [[GIN/3-middleware/cors-registration-scope]] — 全局 vs 分组注册 CORS 中间件的取舍
|
||||
- [[GIN/3-middleware/cors-preflight]] — OPTIONS 预检请求的触发条件与两轮对话流程
|
||||
- [[GIN/3-middleware]] — 中间件三级作用域机制
|
||||
@@ -0,0 +1,244 @@
|
||||
---
|
||||
tags: [Nginx, 反向代理, 跨域, CORS, 运维]
|
||||
create time: 2026-05-15 18:00
|
||||
---
|
||||
|
||||
# Nginx 反向代理处理跨域
|
||||
|
||||
## 概述
|
||||
|
||||
本文档讲解如何利用 Nginx 反向代理解决浏览器端跨域（CORS）问题，从"最干净的方案"到"兜底方案"逐一展开，覆盖生产环境的典型场景。
|
||||
|
||||
> [!TIP] 核心思路
|
||||
> 跨域是浏览器的安全策略，不是后端的限制。Nginx 做反向代理的核心思想：**让浏览器看到的地址和页面同源**，或者 **由 Nginx 在响应头中注入合法的 CORS header**。
|
||||
|
||||
## 正文
|
||||
|
||||
### 三种方案总览
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A[遇到跨域问题] --> B{能否统一域名?}
|
||||
B -- 能 --> C["方案一: 同源代理<br/>零跨域, 最干净"]
|
||||
B -- 不能 --> D{后端已设 CORS header?}
|
||||
D -- 能控制后端 --> E["方案二: Nginx 注入<br/>网关统一管理"]
|
||||
D -- 无法改后端 --> F["方案三: 透传 Header<br/>保留上游配置"]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 方案一：同源代理 — 从根本上消灭跨域（推荐）
|
||||
|
||||
请求的域名和页面域名完全一致，浏览器根本不认为这是跨域请求。
|
||||
|
||||
```nginx
|
||||
server {
|
||||
listen 80;
|
||||
server_name app.example.com;
|
||||
|
||||
# 前端静态资源
|
||||
location / {
|
||||
root /usr/share/nginx/html;
|
||||
try_files $uri $uri/ /index.html;
|
||||
}
|
||||
|
||||
# API 代理 — 浏览器看到 /api/xxx，和页面同源
|
||||
location /api/ {
|
||||
proxy_pass http://backend:8080;
|
||||
proxy_set_header Host $host;
|
||||
proxy_set_header X-Real-IP $remote_addr;
|
||||
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
|
||||
proxy_set_header X-Forwarded-Proto $scheme;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**请求链路示意：**
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant B as 浏览器
|
||||
participant N as Nginx
|
||||
participant S as 后端服务
|
||||
|
||||
B->>N: GET /api/user （同源，无预检）
|
||||
N->>S: GET /api/user
|
||||
S-->>N: 200 OK (body)
|
||||
N-->>B: 200 OK (body，不含 CORS header)
|
||||
```
|
||||
|
||||
| 维度 | 说明 |
|
||||
|------|------|
|
||||
| 是否真正解决跨域 | ✅ 根本解决，浏览器不认为存在跨域 |
|
||||
| Cookie / Session | 天然支持，无需额外配置 |
|
||||
| 安全性 | 最高，不存在任何跨域风险 |
|
||||
| 适用前提 | 你能控制前端部署域名 |
|
||||
|
||||
> **思考**：如果前端和后端分别部署在不同的子域名（如 `app.example.com` 和 `api.example.com`），这个方案还适用吗？不适用——这就是下面两种方案的用武之地。
|
||||
|
||||
---
|
||||
|
||||
### 方案二：Nginx 注入 CORS header（前后端无法同域时）
|
||||
|
||||
当 API 确实需要独立域名时，Nginx 充当"CORS 网关"，负责注入正确的响应头。
|
||||
|
||||
```nginx
|
||||
server {
|
||||
listen 80;
|
||||
server_name api.example.com;
|
||||
|
||||
# 允许的合法前端域名列表
|
||||
set $cors_origin "";
|
||||
|
||||
if ($http_origin ~* "^https://(app\.example\.com|dev\.example\.com)$") {
|
||||
set $cors_origin $http_origin;
|
||||
}
|
||||
|
||||
location /api/ {
|
||||
proxy_pass http://backend:8080;
|
||||
|
||||
# 白名单校验后的 Origin（未匹配则不注入，防止随意跨域）
|
||||
add_header Access-Control-Allow-Origin $cors_origin always;
|
||||
add_header Access-Control-Allow-Credentials "true" always;
|
||||
add_header Access-Control-Allow-Headers "Content-Type, Authorization, X-Token" always;
|
||||
add_header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS" always;
|
||||
add_header Access-Control-Max-Age "3600" always;
|
||||
add_header Access-Control-Expose-Headers "X-Total-Count, X-Request-Id" always;
|
||||
|
||||
# 预检请求直接响应 204
|
||||
if ($request_method = OPTIONS) {
|
||||
return 204;
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**为什么这里用了正则白名单而不是直接回显 `$http_origin`？**
|
||||
|
||||
因为直接回显虽然省事，但意味着**任意域名**都能通过白名单校验拿到 CORS header，等同于变相开放。通过 `~*` 正则限定具体域名，是安全加固的一层。
|
||||
|
||||
#### 关键参数解释
|
||||
|
||||
| 参数 | 作用 | 注意事项 |
|
||||
|------|------|---------|
|
||||
| `add_header ... always` | `always` 确保即使后端返回 4xx/5xx 也加上 CORS header | 不加 `always` 时错误响应会丢失跨域信息 |
|
||||
| `set $cors_origin ""` | 初始化为空，默认不允许跨域 | 这是一种"拒绝所有、放行白名单"的安全策略 |
|
||||
| `if ($request_method = OPTIONS)` | 拦截预检请求，避免转发给后端 | Nginx 的 `if` 在此处使用是安全的（官方推荐用法） |
|
||||
| `Access-Control-Max-Age` | 浏览器缓存预检结果的时间（秒） | 开发时建议设为 `0`，生产可设 `3600`~`86400` |
|
||||
|
||||
> [!WARNING] Credential 模式陷阱
|
||||
> 如果设置了 `Access-Control-Allow-Credentials: true`，`Access-Control-Allow-Origin` **绝对不能是 `*`**。必须动态回显具体域名或走白名单——上面的配置已经通过白名单规避了这个问题。
|
||||
|
||||
---
|
||||
|
||||
### 方案三：透传后端 CORS header
|
||||
|
||||
当后端已经正确配置了 CORS header 时，**默认情况下 Nginx 不会移除这些响应头**，所以大多数场景你不需要任何额外配置。
|
||||
|
||||
> [!TIP] Nginx Header 传递规则（重点）
|
||||
> - **无 `add_header` 时**：Nginx 完整透传上游响应头（包括 CORS header），且子级 `location` 会继承父级的 `add_header`。
|
||||
> - **有 `add_header` 时**：Nginx **丢弃所有父级 `add_header` + 上游的 CORS header**。此时必须显式重新添加需要的头。
|
||||
>
|
||||
> 这是最常见的坑——你在某个 `location` 里加了一个自定义 header，结果发现 CORS header 突然消失了。
|
||||
|
||||
```nginx
|
||||
# 如果你的 Nginx 配置里只有纯粹的 proxy_pass，无需额外操作：
|
||||
location /api/ {
|
||||
proxy_pass http://backend:8080;
|
||||
}
|
||||
```
|
||||
|
||||
但如果因为其他原因你已经在这个 `location` 里有 `add_header`（比如加了自定义 X-Custom-Header），就需要把 CORS header 一并补上：
|
||||
|
||||
```nginx
|
||||
location /api/ {
|
||||
proxy_pass http://backend:8080;
|
||||
|
||||
# 原有自定义 header
|
||||
add_header X-Request-Id $request_id always;
|
||||
|
||||
# 补充 CORS header（否则会被 Nginx 吞掉）
|
||||
proxy_hide_header Access-Control-Allow-Origin;
|
||||
if ($http_origin ~* "^https://.+\.example\.com$") {
|
||||
add_header Access-Control-Allow-Origin $http_origin always;
|
||||
add_header Access-Control-Allow-Credentials "true" always;
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
| 做法 | 效果 | 适用场景 |
|
||||
|------|------|---------|
|
||||
| 不加任何 header | ✅ 完全透传后端 CORS | 后端已配置 CORS，Nginx 只做纯代理 |
|
||||
| 仅加 `proxy_hide_header` | ⚠️ 不发送 CORS header | 需要临时屏蔽后端的 CORS |
|
||||
| 加 `add_header` + `proxy_hide_header` | ✅ 手动重建 CORS | 已在该 location 有其他 header 需共存时 |
|
||||
|
||||
> [!NOTE] 最佳实践建议
|
||||
> 如果后端和前端都在你的控制范围内，**统一将 CORS 配置放在后端中间件层**是最推荐的做法。Nginx 只负责路由转发，不做跨域决策——这样配置清晰、易于维护和审计。只有当你无法修改后端代码时，才需要在 Nginx 层"代劳"设置 CORS header（即回到方案二）。
|
||||
|
||||
---
|
||||
|
||||
### 常见陷阱与调试技巧
|
||||
|
||||
#### 陷阱一：`proxy_pass` 尾部斜杠的语义差异
|
||||
|
||||
`location /api/` 和 `proxy_pass` URL 末尾的 `/` 组合会产生不同行为，这是最容易踩的坑。
|
||||
|
||||
| `location` | `proxy_pass` 结尾 | 请求 `/api/user` → 转发给后端的路径 |
|
||||
|------------|------------------|-----------------------------------|
|
||||
| `/api/` | 无 `/`（`http://backend:8080`） | `/api/user`（原样转发） |
|
||||
| `/api/` | 有 `/`（`http://backend:8080/`） | `/user`（`/api/` 被截断替换） |
|
||||
|
||||
> **记忆口诀**：`proxy_pass` URL 末尾有没有 `/`，决定了 location 匹配部分是否会被截断。
|
||||
> - 没 `/` → 保持前端路径前缀不变（适合前后端共用同一个 API 前缀）
|
||||
> - 有 `/` → 自动去掉 location 前缀（适合后端路由不需要前缀的场景）
|
||||
|
||||
#### 陷阱二：CORS header 突然消失 — Nginx 的继承规则
|
||||
|
||||
Nginx 的 `add_header` 有一个非常反直觉的行为：**一旦你在某个层级定义了 `add_header`，该层级及以下会丢弃所有父级的 header + 上游响应头。**
|
||||
|
||||
排查方法：
|
||||
1. 用 `curl -vI https://api.example.com/api/test` 直接看响应头
|
||||
2. 如果能看到 CORS header → 是 Nginx 配置层覆盖问题，回到方案三的规则修复
|
||||
3. 如果看不到 → 检查后端实际返回了哪些 header（可能后端根本没设）
|
||||
|
||||
#### 陷阱三：`Access-Control-Allow-Headers` 遗漏字段
|
||||
|
||||
浏览器预检时会带上自定义 header（如 `X-Token`, `Authorization`），如果 Nginx 白名单中不包含这些字段，预检直接失败：
|
||||
|
||||
```bash
|
||||
# 在控制台观察到的典型错误
|
||||
# Access to XMLHttpRequest at '...' from origin '...' has been blocked by CORS policy:
|
||||
# Request header field x-token is not allowed by Access-Control-Allow-Headers in preflight response.
|
||||
```
|
||||
|
||||
解决：确保 `Access-Control-Allow-Headers` 包含前端所有可能发送的自定义 header。
|
||||
|
||||
#### 调试 Checklist
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[浏览器报 CORS 错误] --> B{curl 能正常访问?}
|
||||
B -- No --> C["检查后端服务是否存活<br/>及健康检查路径"]
|
||||
B -- Yes --> D{"Response Header 有 CORS?"}
|
||||
D -- No --> E["后端未设置 CORS header<br/>→ 在后端中间件中添加"]
|
||||
D -- Yes --> F{"curl 有但浏览器没有?"}
|
||||
F -- Yes --> G["Nginx add_header 覆盖了上游<br/>→ 检查方案三的继承规则"]
|
||||
F -- No --> H["检查 Response Status Code<br/>是否为 2xx/3xx?<br/>(4xx/5xx 需加 always)"]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 对比总结
|
||||
|
||||
| 维度 | 方案一（同源代理） | 方案二（Nginx 注入） | 方案三（透传后端） |
|
||||
|------|------------------|--------------------|-------------------|
|
||||
| 是否真正解决跨域 | ✅ 根本解决 | ⚠️ 表面绕过 | ⚠️ 取决于后端 |
|
||||
| 安全性 | 最高（无跨域） | 高（白名单可控） | 低（信任后端） |
|
||||
| Cookie 支持 | ✅ 天然支持 | ✅ 配合白名单可用 | ✅ 天然支持 |
|
||||
| 维护成本 | 低 | 中等（域名变更需改配置） | 最低 |
|
||||
| 推荐优先级 | 🥇 首选 | 🥈 次选 | 🥉 兜底 |
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[hzh/DEV/跨域问题调试]] — 跨域排查完整指南
|
||||
- [[GIN/3-middleware/cors-registration-scope]] — 后端 Go/Gin 端 CORS 中间件配置参考
|
||||
+17
-11
@@ -7,7 +7,7 @@ create time: 2026-04-28 00:00
|
||||
|
||||
## 概述
|
||||
|
||||
Gin 提供了三种方式提供静态资源：`Static`（目录映射）、`StaticFS`（自定义文件系统）和 `StaticFile`（单文件）。理解它们的区别和使用场景，是构建完整 Web 服务的基础。
|
||||
Gin 提供了三种核心 API 提供静态资源：`Static`（目录映射）、`StaticFS`（自定义文件系统）和 `StaticFile`（单文件）。此外，通过 `io.Reader` 直接返回文件流以及自定义中间件也是实际项目中常见的手段。理解它们的区别和使用场景，是构建完整 Web 服务的基础。
|
||||
|
||||
思考题：为什么生产环境通常不推荐用 Go 直接提供静态文件？Nginx/CDN 相比有什么优势？
|
||||
|
||||
@@ -94,9 +94,9 @@ r.StaticFile("/robots.txt", "./static/robots.txt")
|
||||
r.Run(":8080")
|
||||
```
|
||||
|
||||
### 4. `io.Reader` 直接返回文件流
|
||||
### 4. 从内存直接返回文件
|
||||
|
||||
对于不需要落盘的文件（如数据库读取的图片、动态生成的 PDF），可以直接从 Reader 输出：
|
||||
对于不需要落盘的文件（如数据库读取的图片、动态生成的 PDF），可以直接从内存输出到响应体：
|
||||
|
||||
```go
|
||||
func getFileFromDB(c *gin.Context) {
|
||||
@@ -107,14 +107,14 @@ func getFileFromDB(c *gin.Context) {
|
||||
return
|
||||
}
|
||||
|
||||
// 直接用 io.Reader 写入响应
|
||||
// DataBytes 直接写入 body，比 SetHeader + Write 更简洁
|
||||
c.DataBytes(http.StatusOK, contentType, fileData)
|
||||
// 或者
|
||||
// c.Writer.Header().Set("Content-Type", contentType)
|
||||
// c.Writer.Write(fileData)
|
||||
}
|
||||
```
|
||||
|
||||
> [!tip] Reader vs []byte
|
||||
> Gin 没有提供专门的 `Reader` 接口写入流式数据。大文件场景建议配合 `c.File()`（内部使用 `sendfile`）或手动实现分块写入，避免一次性加载整个文件到内存。
|
||||
|
||||
### 5. 自定义文件服务器
|
||||
|
||||
如果需要控制缓存头、限速、访问权限等，可以自己实现 `StaticFS`：
|
||||
@@ -124,19 +124,22 @@ func secureStatic() gin.HandlerFunc {
|
||||
return func(c *gin.Context) {
|
||||
path := c.Request.URL.Path
|
||||
|
||||
// 安全检查：防止目录遍历攻击
|
||||
// 安全检查：确保请求路径在允许的目录范围内
|
||||
// filepath.Clean 会解析 ".."，防止目录遍历攻击
|
||||
cleanPath := filepath.Clean(path)
|
||||
if strings.Contains(cleanPath, "..") {
|
||||
baseDir, _ := filepath.Abs("./static") // 允许的基础目录
|
||||
targetPath, _ := filepath.Abs(filepath.Join(baseDir, cleanPath))
|
||||
if !strings.HasPrefix(targetPath, baseDir+"/") && targetPath != baseDir {
|
||||
c.AbortWithStatus(http.StatusForbidden)
|
||||
return
|
||||
}
|
||||
|
||||
// 设置缓存头
|
||||
// 设置缓存和安全头
|
||||
c.Header("Cache-Control", "public, max-age=31536000") // 一年
|
||||
c.Header("X-Content-Type-Options", "nosniff")
|
||||
|
||||
// 交给内置文件服务器
|
||||
http.FileServer(http.Dir("./static")).ServeHTTP(c.Writer, c.Request)
|
||||
http.FileServer(http.Dir(baseDir)).ServeHTTP(c.Writer, c.Request)
|
||||
}
|
||||
}
|
||||
|
||||
@@ -148,6 +151,9 @@ func main() {
|
||||
}
|
||||
```
|
||||
|
||||
> [!warning] 常见错误
|
||||
> 不要这样写：`strings.Contains(path, "..")`。因为 `filepath.Clean()` 已经解析了 `..`，清理后的路径中不会出现 `..`。正确做法是比较**解析后**的绝对路径是否仍在允许的基目录内。
|
||||
|
||||
### 6. 静态文件 vs API 性能对比
|
||||
|
||||
```mermaid
|
||||
|
||||
@@ -157,7 +157,7 @@ func main() {
|
||||
|
||||
> **安全警告：** 如果不设置可信代理，攻击者可以伪造 `X-Forwarded-For` 头注入任意 IP，绕过 IP 白名单限流。务必只信任你知道的代理 IP 段。
|
||||
|
||||
### 5. 完整的生產環境啟動範例
|
||||
### 5. 完整的生产环境启动规范
|
||||
|
||||
```go
|
||||
func main() {
|
||||
|
||||
@@ -148,6 +148,6 @@ graph TB
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[02-服务治理/服务发现/README]] — 网关需要订阅服务实例列表
|
||||
- [[02-服务治理/流量治理/README]] — 高级路由和灰度发布的延伸
|
||||
- [[02-服务治理/04-服务发现]] — 网关需要订阅服务实例列表
|
||||
- [[02-服务治理/08-流量治理]] — 高级路由和灰度发布的延伸
|
||||
- [[hzh/MS/API 设计原则]] — API Gateway 的设计与 REST/gRPC 选型
|
||||
@@ -176,6 +176,6 @@ a1b2c3d4e5f6...
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[02-服务治理/API网关/README]] — 网关层的统一鉴权和限流
|
||||
- [[02-服务治理/服务发现/README]] — 服务注册时也需要安全认证
|
||||
- [[02-服务治理/01-API网关]] — 网关层的统一鉴权和限流
|
||||
- [[02-服务治理/04-服务发现]] — 服务注册时也需要安全认证
|
||||
- [[hzh/MS/API 设计原则]] — API 设计中的安全考量
|
||||
@@ -204,6 +204,6 @@ flowchart LR
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[02-服务治理/API网关/README]] — API Gateway 可以在入口处注入 trace_id
|
||||
- [[04-可观测性/链路追踪/README]] — 更详细的链路追踪设计方法论
|
||||
- [[02-服务治理/配置管理/README]] — 配置中心的动态刷新可以联动调整采样率
|
||||
- [[02-服务治理/01-API网关]] — API Gateway 可以在入口处注入 trace_id
|
||||
- [[04-可观测性/03-链路追踪]] — 更详细的链路追踪设计方法论
|
||||
- [[02-服务治理/07-配置管理]] — 配置中心的动态刷新可以联动调整采样率
|
||||
@@ -200,6 +200,6 @@ sequenceDiagram
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[02-服务治理/API网关/README]] — API Gateway 是服务发现的用户之一
|
||||
- [[02-服务治理/容错模式/README]] — 健康检查是容错体系的基础
|
||||
- [[05-部署运维/Kubernetes/README]] — K8s Service 的服务发现原理
|
||||
- [[02-服务治理/01-API网关]] — API Gateway 是服务发现的用户之一
|
||||
- [[02-服务治理/06-容错模式]] — 健康检查是容错体系的基础
|
||||
- [[05-部署运维/02-Kubernetes]] — K8s Service 的服务发现原理
|
||||
@@ -199,6 +199,6 @@ sequenceDiagram
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[02-服务治理/API网关/README]] — API Gateway 负责协议转换
|
||||
- [[03-数据一致性/分布式事务/README]] — 消息投递的一致性保障
|
||||
- [[05-部署运维/Kubernetes/README]] — Sidecar 代理透明拦截通信流量
|
||||
- [[02-服务治理/01-API网关]] — API Gateway 负责协议转换
|
||||
- [[03-数据一致性/02-分布式事务]] — 消息投递的一致性保障
|
||||
- [[05-部署运维/02-Kubernetes]] — Sidecar 代理透明拦截通信流量
|
||||
@@ -536,6 +536,6 @@ sequenceDiagram
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[02-服务治理/API网关/README]] — 网关层的限流和熔断插件
|
||||
- [[02-服务治理/服务发现/README]] — 健康检查是服务发现的基础
|
||||
- [[04-可观测性/Metrics监控/README]] — 熔断器的指标暴露和告警联动
|
||||
- [[02-服务治理/01-API网关]] — 网关层的限流和熔断插件
|
||||
- [[02-服务治理/04-服务发现]] — 健康检查是服务发现的基础
|
||||
- [[04-可观测性/01-Metrics监控]] — 熔断器的指标暴露和告警联动
|
||||
@@ -169,5 +169,5 @@ flowchart LR
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[02-服务治理/服务发现/README]] — Nacos 同时提供服务发现和配置管理
|
||||
- [[05-部署运维/Kubernetes/README]] — ConfigMap/Secret 是 K8s 的配置注入方式
|
||||
- [[02-服务治理/04-服务发现]] — Nacos 同时提供服务发现和配置管理
|
||||
- [[05-部署运维/02-Kubernetes]] — ConfigMap/Secret 是 K8s 的配置注入方式
|
||||
@@ -138,9 +138,9 @@ http:
|
||||
|
||||
| 能力 | 说明 |
|
||||
|------|------|
|
||||
| **熔断降级** | 下游不可用时自动降级，参见 [[02-服务治理/容错模式/README]] |
|
||||
| **限流** | 保护上游不因过量请求被打垮，参见 [[02-服务治理/容错模式/README]] |
|
||||
| **重试** | 对瞬态故障自动恢复，参见 [[02-服务治理/容错模式/README]] |
|
||||
| **熔断降级** | 下游不可用时自动降级，参见 [[02-服务治理/06-容错模式]] |
|
||||
| **限流** | 保护上游不因过量请求被打垮，参见 [[02-服务治理/06-容错模式]] |
|
||||
| **重试** | 对瞬态故障自动恢复，参见 [[02-服务治理/06-容错模式]] |
|
||||
| **黑白名单** | IP 级别访问控制 |
|
||||
| **A/B Testing** | 基于用户分组的长期实验 |
|
||||
|
||||
@@ -159,6 +159,6 @@ http:
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[02-服务治理/API网关/README]] — API Gateway 的路由和权重分发
|
||||
- [[04-可观测性/Metrics监控/README]] — 灰度期间的监控面板设计
|
||||
- [[05-部署运维/SRE实践/README]] — 基于 SLO 的发布决策
|
||||
- [[02-服务治理/01-API网关]] — API Gateway 的路由和权重分发
|
||||
- [[04-可观测性/01-Metrics监控]] — 灰度期间的监控面板设计
|
||||
- [[05-部署运维/04-SRE实践]] — 基于 SLO 的发布决策
|
||||
@@ -29,14 +29,14 @@ graph LR
|
||||
|
||||
| # | 主题 | 核心问题 |
|
||||
|---|------|----------|
|
||||
| 1 | [[02-服务治理/服务发现/README]] | 服务如何找到彼此？注册中心的工作原理是什么？ |
|
||||
| 2 | [[02-服务治理/API网关/README]] | 统一入口承担哪些职责？网关应该瘦还是胖？ |
|
||||
| 3 | [[02-服务治理/服务间通信/README]] | RPC vs RESTful？同步 vs 异步怎么选？ |
|
||||
| 4 | [[02-服务治理/容错模式/README]] | 网络不可靠，故障怎么隔离和恢复？ |
|
||||
| 5 | [[02-服务治理/配置管理/README]] | 上百个服务的配置如何统一管理？ |
|
||||
| 6 | [[02-服务治理/分布式追踪/README]] | 请求穿越多个服务后，如何追踪链路？ |
|
||||
| 7 | [[02-服务治理/流量治理/README]] | 灰度发布如何做？高级路由策略有哪些？ |
|
||||
| 8 | [[02-服务治理/安全机制/README]] | 服务间调用如何认证和授权？mTLS 是什么？ |
|
||||
| 1 | [[02-服务治理/04-服务发现]] | 服务如何找到彼此？注册中心的工作原理是什么？ |
|
||||
| 2 | [[02-服务治理/01-API网关]] | 统一入口承担哪些职责？网关应该瘦还是胖？ |
|
||||
| 3 | [[02-服务治理/05-服务间通信]] | RPC vs RESTful？同步 vs 异步怎么选？ |
|
||||
| 4 | [[02-服务治理/06-容错模式]] | 网络不可靠，故障怎么隔离和恢复？ |
|
||||
| 5 | [[02-服务治理/07-配置管理]] | 上百个服务的配置如何统一管理？ |
|
||||
| 6 | [[02-服务治理/03-分布式追踪]] | 请求穿越多个服务后，如何追踪链路？ |
|
||||
| 7 | [[02-服务治理/08-流量治理]] | 灰度发布如何做？高级路由策略有哪些？ |
|
||||
| 8 | [[02-服务治理/02-安全机制]] | 服务间调用如何认证和授权？mTLS 是什么？ |
|
||||
|
||||
### 学习建议
|
||||
|
||||
|
||||
@@ -194,5 +194,5 @@ db/migration/
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[03-数据一致性/分布式事务/README]] — 拆分后的数据一致性问题
|
||||
- [[03-数据一致性/02-分布式事务]] — 拆分后的数据一致性问题
|
||||
- [[01-基础概念]] — DDD 限界上下文与数据库拆分的对应关系
|
||||
@@ -244,6 +244,6 @@ sequenceDiagram
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[03-数据一致性/数据库拆分/README]] — 数据库拆分是分布式事务的前提
|
||||
- [[02-服务治理/容错模式/README]] — 熔断器和重试在分布式事务中的作用
|
||||
- [[02-服务治理/服务间通信/README]] — 消息投递的一致性保障
|
||||
- [[03-数据一致性/01-数据库拆分]] — 数据库拆分是分布式事务的前提
|
||||
- [[02-服务治理/06-容错模式]] — 熔断器和重试在分布式事务中的作用
|
||||
- [[02-服务治理/05-服务间通信]] — 消息投递的一致性保障
|
||||
@@ -153,5 +153,5 @@ sequenceDiagram
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[03-数据一致性/数据库拆分/README]] — 分库分表场景下的 ID 生成
|
||||
- [[03-数据一致性/分布式事务/README]] — Outbox 消息 ID 也需要全局唯一
|
||||
- [[03-数据一致性/01-数据库拆分]] — 分库分表场景下的 ID 生成
|
||||
- [[03-数据一致性/02-分布式事务]] — Outbox 消息 ID 也需要全局唯一
|
||||
@@ -23,9 +23,9 @@ graph LR
|
||||
|
||||
| # | 主题 | 核心问题 |
|
||||
|---|------|----------|
|
||||
| 1 | [[03-数据一致性/数据库拆分/README]] | 每个服务独立 DB，表大了怎么拆分？跨库查询怎么做？ |
|
||||
| 2 | [[03-数据一致性/分布式事务/README]] | 本地事务 + MQ、Saga、TCC，哪个方案最合适？ |
|
||||
| 3 | [[03-数据一致性/ID生成/README]] | 没有自增主键了，全局唯一 ID 怎么生成？ |
|
||||
| 1 | [[03-数据一致性/01-数据库拆分]] | 每个服务独立 DB，表大了怎么拆分？跨库查询怎么做？ |
|
||||
| 2 | [[03-数据一致性/02-分布式事务]] | 本地事务 + MQ、Saga、TCC，哪个方案最合适？ |
|
||||
| 3 | [[03-数据一致性/03-ID生成]] | 没有自增主键了，全局唯一 ID 怎么生成？ |
|
||||
|
||||
### 学习建议
|
||||
|
||||
|
||||
@@ -155,6 +155,6 @@ flowchart TB
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[04-可观测性/告警管理/README]] — Metrics 是告警的基础数据来源
|
||||
- [[04-可观测性/链路追踪/README]] — Tracing 与 Metrics 互补，定位具体故障
|
||||
- [[05-部署运维/SRE实践/README]] — SLO 基于 Metrics 数据
|
||||
- [[04-可观测性/04-告警管理]] — Metrics 是告警的基础数据来源
|
||||
- [[04-可观测性/03-链路追踪]] — Tracing 与 Metrics 互补，定位具体故障
|
||||
- [[05-部署运维/04-SRE实践]] — SLO 基于 Metrics 数据
|
||||
@@ -144,6 +144,6 @@ DB 慢查询 → 100% 全量采集 → 重点关注
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[04-可观测性/Metrics监控/README]] — Metrics + Logging = 完整的问题定位能力
|
||||
- [[04-可观测性/链路追踪/README]] — trace_id 是日志与追踪的桥梁
|
||||
- [[04-可观测性/告警管理/README]] — 日志可以触发基于模式的告警
|
||||
- [[04-可观测性/01-Metrics监控]] — Metrics + Logging = 完整的问题定位能力
|
||||
- [[04-可观测性/03-链路追踪]] — trace_id 是日志与追踪的桥梁
|
||||
- [[04-可观测性/04-告警管理]] — 日志可以触发基于模式的告警
|
||||
@@ -161,6 +161,6 @@ flowchart TD
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[04-可观测性/Metrics监控/README]] — Tracing 与 Metrics 互补
|
||||
- [[04-可观测性/日志系统/README]] — trace_id 串联日志和追踪
|
||||
- [[04-可观测性/告警管理/README]] — 基于 Trace 数据的异常检测告警
|
||||
- [[04-可观测性/01-Metrics监控]] — Tracing 与 Metrics 互补
|
||||
- [[04-可观测性/02-日志系统]] — trace_id 串联日志和追踪
|
||||
- [[04-可观测性/04-告警管理]] — 基于 Trace 数据的异常检测告警
|
||||
@@ -181,6 +181,6 @@ flowchart LR
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[04-可观测性/Metrics监控/README]] — Metrics 是告警的数据来源
|
||||
- [[05-部署运维/SRE实践/README]] — SLO/Error Budget 的详细方法论
|
||||
- [[02-服务治理/容错模式/README]] — 熔断器状态可以作为告警信号
|
||||
- [[04-可观测性/01-Metrics监控]] — Metrics 是告警的数据来源
|
||||
- [[05-部署运维/04-SRE实践]] — SLO/Error Budget 的详细方法论
|
||||
- [[02-服务治理/06-容错模式]] — 熔断器状态可以作为告警信号
|
||||
@@ -25,10 +25,10 @@ graph LR
|
||||
|
||||
| # | 主题 | 核心问题 |
|
||||
|---|------|----------|
|
||||
| 1 | [[04-可观测性/Metrics监控/README]] | 怎么量化系统的健康度？RED/USE 方法怎么用？ |
|
||||
| 2 | [[04-可观测性/日志系统/README]] | 日志怎么集中收集？结构化日志的最佳实践是什么？ |
|
||||
| 3 | [[04-可观测性/链路追踪/README]] | trace_id 如何贯穿跨服务调用链？OpenTelemetry 怎么用？ |
|
||||
| 4 | [[04-可观测性/告警管理/README]] | 如何设计告警避免疲劳？SLO/Error Budget 怎么做？ |
|
||||
| 1 | [[04-可观测性/01-Metrics监控]] | 怎么量化系统的健康度？RED/USE 方法怎么用？ |
|
||||
| 2 | [[04-可观测性/02-日志系统]] | 日志怎么集中收集？结构化日志的最佳实践是什么？ |
|
||||
| 3 | [[04-可观测性/03-链路追踪]] | trace_id 如何贯穿跨服务调用链？OpenTelemetry 怎么用？ |
|
||||
| 4 | [[04-可观测性/04-告警管理]] | 如何设计告警避免疲劳？SLO/Error Budget 怎么做？ |
|
||||
|
||||
### 为什么需要独立的"可观测性"体系？
|
||||
|
||||
@@ -74,5 +74,5 @@ flowchart LR
|
||||
### 关联笔记
|
||||
|
||||
- [[02-服务治理]] — 熔断器可以触发告警，与监控系统联动
|
||||
- [[05-部署运维/Kubernetes/README]] — K8s Liveness/Readiness Probe 是可观测性的基础
|
||||
- [[05-部署运维/02-Kubernetes]] — K8s Liveness/Readiness Probe 是可观测性的基础
|
||||
- [[hzh/MS/README.md]] — 完整微服务知识索引
|
||||
|
||||
@@ -151,5 +151,5 @@ flowchart LR
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[05-部署运维/Kubernetes/README]] — K8s 以 Pod 为部署单元，镜像来自 Docker
|
||||
- [[05-部署运维/CI-CD与GitOps/README]] — CI/CD 流水线中的镜像构建环节
|
||||
- [[05-部署运维/02-Kubernetes]] — K8s 以 Pod 为部署单元，镜像来自 Docker
|
||||
- [[05-部署运维/03-CICD与GitOps]] — CI/CD 流水线中的镜像构建环节
|
||||
@@ -261,6 +261,6 @@ spec:
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[02-服务治理/服务发现/README]] — K8s Service 是服务端发现模式的代表
|
||||
- [[02-服务治理/流量治理/README]] — Istio VirtualService 在 K8s 上的高级路由
|
||||
- [[05-部署运维/SRE实践/README]] — SLO/Error Budget 在 K8s 中的落地
|
||||
- [[02-服务治理/04-服务发现]] — K8s Service 是服务端发现模式的代表
|
||||
- [[02-服务治理/08-流量治理]] — Istio VirtualService 在 K8s 上的高级路由
|
||||
- [[05-部署运维/04-SRE实践]] — SLO/Error Budget 在 K8s 中的落地
|
||||
@@ -171,6 +171,6 @@ helm upgrade --install order-service ./charts/order-service \
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[05-部署运维/容器化/README]] — Docker 镜像构建是 CI/CD 的第一步
|
||||
- [[05-部署运维/Kubernetes/README]] — K8s 是部署的目标平台
|
||||
- [[05-部署运维/SRE实践/README]] — 错误预算影响发布策略
|
||||
- [[05-部署运维/01-容器化]] — Docker 镜像构建是 CI/CD 的第一步
|
||||
- [[05-部署运维/02-Kubernetes]] — K8s 是部署的目标平台
|
||||
- [[05-部署运维/04-SRE实践]] — 错误预算影响发布策略
|
||||
@@ -155,6 +155,6 @@ groups:
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[04-可观测性/告警管理/README]] — SLO/Error Budget 与告警体系的联动
|
||||
- [[05-部署运维/Kubernetes/README]] — K8s HPA 弹性伸缩支撑 SLO 保障
|
||||
- [[05-部署运维/CI-CD与GitOps/README]] — GitOps 支持安全的持续交付
|
||||
- [[04-可观测性/04-告警管理]] — SLO/Error Budget 与告警体系的联动
|
||||
- [[05-部署运维/02-Kubernetes]] — K8s HPA 弹性伸缩支撑 SLO 保障
|
||||
- [[05-部署运维/03-CICD与GitOps]] — GitOps 支持安全的持续交付
|
||||
@@ -25,10 +25,10 @@ graph LR
|
||||
|
||||
| # | 主题 | 核心问题 |
|
||||
|---|------|----------|
|
||||
| 1 | [[05-部署运维/容器化/README]] | Docker 镜像怎么优化？最佳实践有哪些？ |
|
||||
| 2 | [[05-部署运维/Kubernetes/README]] | K8s 核心概念和资源管理怎么做？ |
|
||||
| 3 | [[05-部署运维/CI-CD与GitOps/README]] | 自动化流水线怎么设计？GitOps 流程怎么走？ |
|
||||
| 4 | [[05-部署运维/SRE实践/README]] | SLI/SLO/Error Budget 如何落地？ |
|
||||
| 1 | [[05-部署运维/01-容器化]] | Docker 镜像怎么优化？最佳实践有哪些？ |
|
||||
| 2 | [[05-部署运维/02-Kubernetes]] | K8s 核心概念和资源管理怎么做？ |
|
||||
| 3 | [[05-部署运维/03-CICD与GitOps]] | 自动化流水线怎么设计？GitOps 流程怎么走？ |
|
||||
| 4 | [[05-部署运维/04-SRE实践]] | SLI/SLO/Error Budget 如何落地？ |
|
||||
|
||||
### 学习建议
|
||||
|
||||
|
||||
@@ -150,12 +150,12 @@ graph LR
|
||||
>
|
||||
> 既然 gRPC 这么多优势，是不是所有场景都应该用 gRPC？什么情况下 HTTP/JSON 仍然更合适？
|
||||
|
||||
答案见 [[02-服务治理/服务间通信]]。对外暴露 API 时，HTTP/JSON 仍然不可替代——因为浏览器的 Native Fetch 无法直接调用 gRPC，第三方接入者也不想安装 Proto 编译器。
|
||||
答案见 [[02-服务治理/05-服务间通信]]。对外暴露 API 时，HTTP/JSON 仍然不可替代——因为浏览器的 Native Fetch 无法直接调用 gRPC，第三方接入者也不想安装 Proto 编译器。
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[02-服务治理/服务间通信]] — gRPC 与 REST 的基础对比及选型建议
|
||||
- [[02-服务治理/容错模式/README]] — 基于此架构的重试、熔断等治理机制
|
||||
- [[02-服务治理/05-服务间通信]] — gRPC 与 REST 的基础对比及选型建议
|
||||
- [[02-服务治理/06-容错模式]] — 基于此架构的重试、熔断等治理机制
|
||||
- [[02-Proto设计]] — Proto 文件设计的进阶实践
|
||||
- [[03-RPC模式]] — 四种 RPC 模式的深度用法
|
||||
- [[04-拦截器]] — 切面编程和上下文传播
|
||||
|
||||
@@ -279,4 +279,4 @@ proto/
|
||||
|
||||
- [[01-协议与架构]] — Proto 文件最终服务于协议栈中的 Generated Stub 层
|
||||
- [[07-最佳实践]] — Buf 代码生成流程和生产配置
|
||||
- [[02-服务治理/服务间通信]] — 不同序列化方案的性能对比
|
||||
- [[02-服务治理/05-服务间通信]] — 不同序列化方案的性能对比
|
||||
|
||||
@@ -156,7 +156,7 @@ conn, _ := grpc.Dial(target,
|
||||
|
||||
> [!keypoint] 为什么需要上下文传播
|
||||
>
|
||||
> 当一个请求穿越 5 个微服务时，如果没有上下文传播，你在日志系统中看到的是 5 条孤立的记录。有了 W3C Trace Context，每层服务自动将 `traceparent` 透传给下一跳——最终汇聚成一条完整的调用链路，这就是 [[02-服务治理/分布式追踪]] 的核心能力。
|
||||
> 当一个请求穿越 5 个微服务时，如果没有上下文传播，你在日志系统中看到的是 5 条孤立的记录。有了 W3C Trace Context，每层服务自动将 `traceparent` 透传给下一跳——最终汇聚成一条完整的调用链路，这就是 [[02-服务治理/03-分布式追踪]] 的核心能力。
|
||||
|
||||
## 拦截器最佳实践
|
||||
|
||||
@@ -172,5 +172,5 @@ conn, _ := grpc.Dial(target,
|
||||
|
||||
- [[01-协议与架构]] — 拦截器位于 gRPC Framework 层，在 HTTP/2 之前处理请求
|
||||
- [[05-错误处理]] — 拦截器经常需要根据错误码决定重试或降级策略
|
||||
- [[02-服务治理/分布式追踪]] — Context 传播是实现分布式追踪的前提
|
||||
- [[02-服务治理/安全机制]] — 鉴权拦截器是安全机制在代码层的落地形式
|
||||
- [[02-服务治理/03-分布式追踪]] — Context 传播是实现分布式追踪的前提
|
||||
- [[02-服务治理/02-安全机制]] — 鉴权拦截器是安全机制在代码层的落地形式
|
||||
|
||||
@@ -174,5 +174,5 @@ default:
|
||||
|
||||
- [[04-拦截器]] — 拦截器根据错误码决定是否触发自动重试
|
||||
- [[07-最佳实践]] — 重试策略中与错误状态的配合配置
|
||||
- [[02-服务治理/容错模式]] — 熔断器在收到特定错误码后触发熔断
|
||||
- [[02-服务治理/分布式追踪]] — 错误链路在追踪系统中的标注方式
|
||||
- [[02-服务治理/06-容错模式]] — 熔断器在收到特定错误码后触发熔断
|
||||
- [[02-服务治理/03-分布式追踪]] — 错误链路在追踪系统中的标注方式
|
||||
|
||||
@@ -151,5 +151,5 @@ Kubernetes 的 DNS 控制器会自动将 Service 的 Endpoints 更新到 DNS 记
|
||||
|
||||
- [[01-协议与架构]] — Name Resolver 是架构图中连接管理层的第一环
|
||||
- [[07-最佳实践]] — Keepalive、负载均衡在生产环境的配合配置
|
||||
- [[02-服务治理/服务发现/README]] — 更深度的服务发现机制对比（Nacos / Consul / K8s）
|
||||
- [[02-服务治理/容错模式/README]] — 负载均衡 + 熔断的组合效果
|
||||
- [[02-服务治理/04-服务发现]] — 更深度的服务发现机制对比（Nacos / Consul / K8s）
|
||||
- [[02-服务治理/06-容错模式]] — 负载均衡 + 熔断的组合效果
|
||||
|
||||
@@ -216,5 +216,5 @@ resp, err := client.GetBigData(
|
||||
- [[04-拦截器]] — 重试策略可以通过 interceptor 实现更复杂的逻辑
|
||||
- [[05-错误处理]] — 重试策略根据错误状态码来决定是否重试
|
||||
- [[06-连接管理]] — Keepalive、负载均衡、Name Resolver 的详细配置
|
||||
- [[02-服务治理/安全机制]] — mTLS 与服务间身份认证的更深内容
|
||||
- [[02-服务治理/容错模式]] — 熔断器、限流器与重试策略的组合配置
|
||||
- [[02-服务治理/02-安全机制]] — mTLS 与服务间身份认证的更深内容
|
||||
- [[02-服务治理/06-容错模式]] — 熔断器、限流器与重试策略的组合配置
|
||||
|
||||
@@ -7,7 +7,7 @@ create time: 2026-05-07 16:30
|
||||
|
||||
## 概述
|
||||
|
||||
本目录系统整理 **gRPC** 的核心知识点，从底层协议到生产实践，由浅入深覆盖 gRPC 的每一个关键领域。与 [[02-服务治理/服务间通信]] 中的入门对比不同，这里聚焦于「用了 gRPC 之后」—— 如何设计 Proto、如何编写拦截器、如何处理流式调用、连接怎么管、出错怎么查。
|
||||
本目录系统整理 **gRPC** 的核心知识点，从底层协议到生产实践，由浅入深覆盖 gRPC 的每一个关键领域。与 [[02-服务治理/05-服务间通信]] 中的入门对比不同，这里聚焦于「用了 gRPC 之后」—— 如何设计 Proto、如何编写拦截器、如何处理流式调用、连接怎么管、出错怎么查。
|
||||
|
||||
```mermaid
|
||||
graph LR
|
||||
@@ -126,8 +126,8 @@ graph LR
|
||||
|
||||
## 关联笔记
|
||||
|
||||
- [[02-服务治理/服务间通信]] — gRPC 与 REST 的基础对比及混合通信模式
|
||||
- [[02-服务治理/服务发现/README]] — Nacos / Consul / K8s Service 深度对比
|
||||
- [[02-服务治理/容错模式/README]] — 重试、熔断、限流、降级的完整治理
|
||||
- [[02-服务治理/分布式追踪/README]] — OpenTelemetry 链路追踪
|
||||
- [[02-服务治理/安全机制/README]] — mTLS、JWT、RBAC
|
||||
- [[02-服务治理/05-服务间通信]] — gRPC 与 REST 的基础对比及混合通信模式
|
||||
- [[02-服务治理/04-服务发现]] — Nacos / Consul / K8s Service 深度对比
|
||||
- [[02-服务治理/06-容错模式]] — 重试、熔断、限流、降级的完整治理
|
||||
- [[02-服务治理/03-分布式追踪]] — OpenTelemetry 链路追踪
|
||||
- [[02-服务治理/02-安全机制]] — mTLS、JWT、RBAC
|
||||
|
||||
+19
-19
@@ -39,40 +39,40 @@ graph LR
|
||||
|
||||
| 子主题 | 核心内容 |
|
||||
|--------|---------|
|
||||
| [[02-服务治理/服务发现/README]] | Nacos / Consul / K8s Service，客户端 vs 服务端发现模式 |
|
||||
| [[02-服务治理/API网关/README]] | 统一入口的职责边界、路由策略、插件体系 |
|
||||
| [[02-服务治理/服务间通信/README]] | gRPC vs REST，同步 vs 异步组合拳 |
|
||||
| [[02-服务治理/容错模式/README]] | 超时 / 重试 / 熔断 / 限流 / 舱壁隔离 / 降级 |
|
||||
| [[02-服务治理/配置管理/README]] | Nacos Config / Apollo，动态刷新与版本管理 |
|
||||
| [[02-服务治理/分布式追踪/README]] | OpenTelemetry，trace/span 概念，采样策略 |
|
||||
| [[02-服务治理/流量治理/README]] | 灰度发布策略，蓝绿 vs 金丝雀，Istio VirtualService |
|
||||
| [[02-服务治理/安全机制/README]] | mTLS, JWT, RBAC/ABAC, 输入防护 |
|
||||
| [[02-服务治理/04-服务发现]] | Nacos / Consul / K8s Service，客户端 vs 服务端发现模式 |
|
||||
| [[02-服务治理/01-API网关]] | 统一入口的职责边界、路由策略、插件体系 |
|
||||
| [[02-服务治理/05-服务间通信]] | gRPC vs REST，同步 vs 异步组合拳 |
|
||||
| [[02-服务治理/06-容错模式]] | 超时 / 重试 / 熔断 / 限流 / 舱壁隔离 / 降级 |
|
||||
| [[02-服务治理/07-配置管理]] | Nacos Config / Apollo，动态刷新与版本管理 |
|
||||
| [[02-服务治理/03-分布式追踪]] | OpenTelemetry，trace/span 概念，采样策略 |
|
||||
| [[02-服务治理/08-流量治理]] | 灰度发布策略，蓝绿 vs 金丝雀，Istio VirtualService |
|
||||
| [[02-服务治理/02-安全机制]] | mTLS, JWT, RBAC/ABAC, 输入防护 |
|
||||
|
||||
### 3. [[03-数据一致性]] — 跨服务数据一致性怎么保证？
|
||||
|
||||
| 子主题 | 核心内容 |
|
||||
|--------|---------|
|
||||
| [[03-数据一致性/数据库拆分/README]] | 垂直拆分 / 水平分片，ShardingSphere，跨库查询方案 |
|
||||
| [[03-数据一致性/分布式事务/README]] | Outbox 模式，Saga，TCC，AT 模式，幂等设计 |
|
||||
| [[03-数据一致性/ID生成/README]] | Snowflake, UUID v7, 号段模式 |
|
||||
| [[03-数据一致性/01-数据库拆分]] | 垂直拆分 / 水平分片，ShardingSphere，跨库查询方案 |
|
||||
| [[03-数据一致性/02-分布式事务]] | Outbox 模式，Saga，TCC，AT 模式，幂等设计 |
|
||||
| [[03-数据一致性/03-ID生成]] | Snowflake, UUID v7, 号段模式 |
|
||||
|
||||
### 4. [[04-可观测性]] — 请求穿越多个服务后如何排查问题？
|
||||
|
||||
| 子主题 | 核心内容 |
|
||||
|--------|---------|
|
||||
| [[04-可观测性/Metrics监控/README]] | Prometheus, RED/USE 方法, Counter/Gauge/Histogram |
|
||||
| [[04-可观测性/日志系统/README]] | JSON 结构化日志, ELK vs Loki, 采集管线, 采样策略 |
|
||||
| [[04-可观测性/链路追踪/README]] | OpenTelemetry, W3C Trace Context, 上下文传播, 采样 |
|
||||
| [[04-可观测性/告警管理/README]] | SLO/Error Budget 告警, 分级降噪, On-Call 最佳实践 |
|
||||
| [[04-可观测性/01-Metrics监控]] | Prometheus, RED/USE 方法, Counter/Gauge/Histogram |
|
||||
| [[04-可观测性/02-日志系统]] | JSON 结构化日志, ELK vs Loki, 采集管线, 采样策略 |
|
||||
| [[04-可观测性/03-链路追踪]] | OpenTelemetry, W3C Trace Context, 上下文传播, 采样 |
|
||||
| [[04-可观测性/04-告警管理]] | SLO/Error Budget 告警, 分级降噪, On-Call 最佳实践 |
|
||||
|
||||
### 5. [[05-部署运维]] — 上百个服务如何容器化编排与发布？
|
||||
|
||||
| 子主题 | 核心内容 |
|
||||
|--------|---------|
|
||||
| [[05-部署运维/容器化/README]] | Dockerfile 最佳实践, 镜像安全, distroless |
|
||||
| [[05-部署运维/Kubernetes/README]] | Pod/Deployment/Service/Ingress, Probe, HPA, 资源配置 |
|
||||
| [[05-部署运维/CI-CD与GitOps/README]] | GitHub Actions Pipeline, GitOps (ArgoCD), Helm |
|
||||
| [[05-部署运维/SRE实践/README]] | SLI/SLO/SLA, Error Budget, Blameless Postmortem, DORA Metrics |
|
||||
| [[05-部署运维/01-容器化]] | Dockerfile 最佳实践, 镜像安全, distroless |
|
||||
| [[05-部署运维/02-Kubernetes]] | Pod/Deployment/Service/Ingress, Probe, HPA, 资源配置 |
|
||||
| [[05-部署运维/03-CICD与GitOps]] | GitHub Actions Pipeline, GitOps (ArgoCD), Helm |
|
||||
| [[05-部署运维/04-SRE实践]] | SLI/SLO/SLA, Error Budget, Blameless Postmortem, DORA Metrics |
|
||||
|
||||
## 学习建议
|
||||
|
||||
|
||||
Reference in New Issue
Block a user