880 lines
34 KiB
Markdown
880 lines
34 KiB
Markdown
---
|
||
tags:
|
||
- 后端
|
||
- Go
|
||
- GORM
|
||
- ORM
|
||
- 测试
|
||
- 自我考察
|
||
create time: 2026-04-29 15:30
|
||
---
|
||
|
||
# GORM 框架自测题
|
||
|
||
## 概述
|
||
|
||
这是一份 **GORM 框架**的自测试卷，覆盖核心机制 → 查询技巧 → 工程实践全链路知识点。通过选择题、填空题、代码补全、主观题四种题型帮助你检验对 GORM 的理解程度，找到知识盲区后回到对应笔记重新学习。
|
||
|
||
---
|
||
|
||
## 正文
|
||
|
||
## 一、选择题（每题 3 分，共 30 分）
|
||
|
||
> 每题只有一个正确答案。
|
||
|
||
### Q1.【软删除的设计】
|
||
|
||
为什么 GORM 的软删除使用 `DeletedAt` 时间戳而不是 `IsDeleted BOOLEAN`？以下原因**最全面**的是：
|
||
|
||
A. BOOLEAN 无法区分"未删除"和"误删恢复"两种场景
|
||
B. 时间戳记录精确的删除时刻便于审计；NULL 表示未删除语义更清晰
|
||
C. BOOLEAN 在 MySQL 中占 1 byte，时间戳占 8 bytes，浪费存储空间
|
||
D. BOOLEAN 会导致唯一约束检查变慢
|
||
|
||
> [!tip]- Q1 答案
|
||
> **B — 时间戳提供审计信息 + NULL 语义清晰**
|
||
>
|
||
> **解析：**
|
||
> `gorm.DeletedAt`（本质是 `time.Time`）相比 BOOLEAN 的优势在于：
|
||
>
|
||
> 1. **精确时间**：记录了确切的删除时刻，方便后续审计和问题排查
|
||
> 2. **NULL = 未删除**：Go 中零值 `time.Time{}` 不等于 nil，GORM 用 `nil` 指针表示"未删除"——这与 BOOLEAN 的 `false = 正常` 相比，语义更不容易混淆
|
||
> 3. **时间排序**：可以按删除时间排序，做定时清理策略时更方便
|
||
>
|
||
> **为什么不是其他选项：**
|
||
> - ❌ A：BOOLEAN 也能通过业务逻辑区分恢复，这不是核心原因
|
||
> - ❌ C：这是缺点而非设计理由——软删除本身就比物理删除多占空间
|
||
> - ❌ D：BOOLEAN 和时间戳在唯一约束上的行为差异取决于数据库实现，不是 GORM 的考量
|
||
>
|
||
> 💡 **拓展：** `DeletedAt` 的类型是 `*time.Time`（指针），这样就能用 `nil` 表示未删除。如果用的是非指针 `time.Time`，零值也会被误判为已删除。
|
||
|
||
### Q2.【Preload vs Joins】
|
||
|
||
关于 `Preload` 和 `Joins` 的区别，以下说法**正确**的是：
|
||
|
||
A. `Preload` 只执行一条 SQL，`Joins` 执行多条 SQL
|
||
B. `Preload` 默认对关联数据加软删除过滤，`Joins` 不会自动加
|
||
C. `Joins` 返回的数据会自动填充嵌套 struct，`Preload` 需要手动映射
|
||
D. `Joins` 会产生行膨胀（笛卡尔积），`Preload` 不会产生
|
||
|
||
> [!tip]- Q2 答案
|
||
> **D — Joins 会产生行膨胀，Preload 不会**
|
||
>
|
||
> **解析：**
|
||
>
|
||
> | 特性 | Preload | Joins |
|
||
> |------|---------|-------|
|
||
> | SQL 数量 | N+1 条（先查主表，再批量 IN 查关联） | 通常 1 条复杂 JOIN SQL |
|
||
> | 行重复 | ❌ 不会产生 | ✅ 一对多关系会产生重复行（一个用户有多个订单会返回多行 User） |
|
||
> | 关联过滤 | 容易（WHERE 作为第二参数） | 需写在 JOIN 子句中，控制不够灵活 |
|
||
> | 内存占用 | 适中 | JOIN 膨胀时较高 |
|
||
>
|
||
> **逐项分析：**
|
||
> - ❌ A：反了——Preload 是多条 SQL，Joins 是一条
|
||
> - ❌ B：两者都会自动加软删除过滤，GORM 内部都对关联查询附加 `deleted_at IS NULL`
|
||
> - ❌ C：两者都能自动填充嵌套 struct，不需要手动映射
|
||
> - ✅ D：正确！LEFT JOIN 时若 OneToMany 关系会返回多条相同主记录的行（行膨胀），而 Preload 分两次查询完全避免了这个问题
|
||
>
|
||
> 💡 **经验法则：** "优先 Preload，必要时 Joins"——除非确定关联数据量极小，否则 Preload 更安全可控。
|
||
|
||
### Q3.【First vs Take vs Last】
|
||
|
||
三个方法都要求带条件，关于它们的行为差异，以下说法**正确**的是：
|
||
|
||
A. `First` 和 `Take` 都会按主键排序后取第一条
|
||
B. `Take` 是无序的，适合随机抽奖或推荐场景
|
||
C. `Last` 不按主键排序，而是按创建时间倒序
|
||
D. 三者不带 Where 都能正常工作
|
||
|
||
> [!tip]- Q3 答案
|
||
> **B — Take 无序，适合随机场景**
|
||
>
|
||
> **解析：**
|
||
>
|
||
> | 方法 | 排序方式 | 结果确定性 | 是否需要 Where |
|
||
> |------|---------|-----------|---------------|
|
||
> | `First` | 主键升序（ORDER BY PK ASC LIMIT 1） | ✅ 确定性 | ✅ 必须 |
|
||
> | `Take` | **不指定任何排序** | ❌ 任意一条 | ✅ 必须 |
|
||
> | `Last` | 主键降序（ORDER BY PK DESC LIMIT 1） | ✅ 确定性 | ✅ 必须 |
|
||
>
|
||
> **逐项分析：**
|
||
> - ❌ A：`Take` 不带排序，数据库返回哪条就是哪条——这恰恰是关键区别
|
||
> - ✅ B：正确。`Take` 等同于 `SELECT * FROM table LIMIT 1`，没有 ORDER BY，所以每次拿到的可能不同，正好适合"随机"语义
|
||
> - ❌ C：`Last` 是按主键倒序，不是创建时间
|
||
> - ❌ D：文档明确写了三者都需要至少一个 Where 条件
|
||
>
|
||
> 💡 **实际选择：** 要"最新的记录"用 `First`；要"随便来一条"用 `Take`；要"最后一条"用 `Last`。
|
||
|
||
### Q4.【Updates 的 zero value 陷阱】
|
||
|
||
以下代码的输出结果是？
|
||
|
||
```go
|
||
user := User{Name: "Alice", Age: 25}
|
||
db.Model(&user).Updates(User{Name: "", Status: "active"})
|
||
```
|
||
|
||
A. UPDATE SET name='', status='active' —— Name 被更新为空字符串
|
||
B. UPDATE SET status='active' —— Name 跳过了，因为空串是零值
|
||
C. UPDATE SET name='', status='active' —— struct 方式的 Updates 不会跳过零值
|
||
D. 报错，因为不能传入零值
|
||
|
||
> [!tip]- Q4 答案
|
||
> **B — struct 方式跳过了零值字段**
|
||
>
|
||
> **解析：**
|
||
> GORM 的 `Updates` 有两种传参方式，处理方式截然不同：
|
||
>
|
||
> | 方式 | 零值处理 | 生成的 SQL |
|
||
> |------|---------|-----------|
|
||
> | `Updates(struct)` | **跳过零值字段**（Zero Value Skipped） | `UPDATE users SET status='active' WHERE ...` |
|
||
> | `Updates(map[string]any)` | **写入所有 key**（包含零值） | `UPDATE users SET name='', status='active' WHERE ...` |
|
||
>
|
||
> 在上面的例子中，`Name: ""` 是 string 类型的零值，所以 `Updates(User{Name: "", Status: "active"})` 只会生成 `SET status='active'`。
|
||
>
|
||
> **真实踩坑案例：** 用户想把昵称清空，调用了 `Updates(User{Nickname: ""})`，结果什么 SQL 都没生成——数据完全没有变化！
|
||
>
|
||
> 💡 **解决方案：** 需要更新零值时用 map 方式：`Updates(map[string]any{"name": ""})`。
|
||
|
||
### Q5.【事务回调的错误返回值】
|
||
|
||
```go
|
||
err := db.Transaction(func(tx *gorm.DB) error {
|
||
var account Account
|
||
if err := tx.First(&account, 1).Error; err != nil {
|
||
return err
|
||
}
|
||
account.Balance -= 100
|
||
tx.Save(&account)
|
||
return nil
|
||
})
|
||
```
|
||
|
||
如果 `tx.First` 找不到账户（返回 `ErrRecordNotFound`），会发生什么？
|
||
|
||
A. 错误被静默吞掉，继续执行 Save
|
||
B. 函数 return err → GORM 自动 Rollback，最终 `err == ErrRecordNotFound`
|
||
C. 函数 panic，因为 error 没有包装
|
||
D. GORM 自动把错误转换为 HTTP 404 响应
|
||
|
||
> [!tip]- Q5 答案
|
||
> **B — Transaction() 回调返回 error 自动回滚**
|
||
>
|
||
> **解析：**
|
||
> `db.Transaction()` 是 GORM 提供的便捷事务 API，它的核心机制是：
|
||
>
|
||
> 1. **内部自动 Begin**：进入回调前开启事务
|
||
> 2. **return nil → Commit**：回调返回 nil 说明一切正常，GORM 自动提交
|
||
> 3. **return non-nil error → Rollback**：回调返回任何非 nil error，GORM 自动回滚
|
||
> 4. **panic → Rollback**：回调内 panic，GORM 捕获后也回滚
|
||
>
|
||
> **在这个例子中：**
|
||
> - `tx.First` 找不到记录 → 返回 `ErrRecordNotFound`
|
||
> - `return err` → GORM 检测到非 nil → 自动 `Rollback()`
|
||
> - 外层 `err` 拿到的是包装后的 `ErrRecordNotFound`
|
||
>
|
||
> **为什么要这样设计？** 避免了手动写 `Begin/Rollback/Commit` 的大量样板代码，且天然防止"事务泄漏"——出了闭包就拿不到 tx 实例了。
|
||
>
|
||
> 💡 **限制：** 回调内不能再调用 `Transaction()`，否则 panic——因为此时已经处于事务中了。
|
||
|
||
### Q6.【WHERE vs HAVING】
|
||
|
||
以下 GORM 查询语句的错误原因是：
|
||
|
||
```go
|
||
db.Model(&Order{}).Where("COUNT(*) > 5").Group("user_id").Find(&result)
|
||
```
|
||
|
||
A. GORM 不支持 GROUP BY
|
||
B. WHERE 不能在 GROUP BY 之前执行聚合函数
|
||
C. Find 不能和 Group 连用
|
||
D. COUNT 必须配合 Select 才能使用
|
||
|
||
> [!tip]- Q6 答案
|
||
> **B — WHERE 在分组前执行，无法使用聚合函数**
|
||
>
|
||
> **解析：**
|
||
> SQL 的标准执行顺序是：
|
||
> ```
|
||
> FROM → WHERE → GROUP BY → HAVING → SELECT → ORDER BY
|
||
> ```
|
||
>
|
||
> **关键理解：** `WHERE` 发生在 `GROUP BY` 之前——此时还没有分组，`COUNT(*)` 毫无意义。SQL 引擎会在解析 WHERE 时就报语法错误。
|
||
>
|
||
> **正确写法：** 把聚合条件放到 `HAVING` 中：
|
||
> ```go
|
||
> db.Model(&Order{}).
|
||
> Group("user_id").
|
||
> Having("COUNT(*) > ?", 5). // ✅ HAVING 才能用聚合函数
|
||
> Find(&result)
|
||
> ```
|
||
>
|
||
> **如果想先用 WHERE 缩小范围再做聚合：**
|
||
> ```go
|
||
> db.Model(&Order{}).
|
||
> Where("created_at > ?", cutoff). // 先用 WHERE 过滤单行
|
||
> Group("user_id").
|
||
> Having("COUNT(*) > ?", 5). // 再用 HAVING 过滤聚合结果
|
||
> Find(&result)
|
||
> ```
|
||
>
|
||
> 💡 **记忆口诀：** "WHERE 筛行，HAVING 筛组"。
|
||
|
||
### Q7.【钩子与操作的关系】
|
||
|
||
如果一个模型包含 `DeletedAt` 字段并嵌入了 `gorm.Model`，当调用 `db.Delete(&user)`（软删除）时，哪个钩子**会被调用**？
|
||
|
||
A. `BeforeDelete` 和 `AfterDelete`
|
||
B. `BeforeUpdate` 和 `AfterUpdate`
|
||
C. `BeforeDelete` 和 `AfterUpdate`
|
||
D. 没有任何钩子被调用
|
||
|
||
> [!tip]- Q7 答案
|
||
> **B — BeforeUpdate 和 AfterUpdate**
|
||
>
|
||
> **解析：**
|
||
> 这是软删除最常见的误区之一。虽然名字叫 `Delete()`，但在软删除模式下它发送的是 **UPDATE 语句**：
|
||
> ```sql
|
||
> UPDATE users SET deleted_at = NOW() WHERE id = ?
|
||
> ```
|
||
>
|
||
> **因此触发的是 UPDATE 钩子链：**
|
||
> ```
|
||
> BeforeDelete（❌ 不会被调用）
|
||
> ↓
|
||
> BeforeUpdate （✅ 被调用）→ SQL: UPDATE ... SET deleted_at=...
|
||
> ↓
|
||
> AfterUpdate （✅ 被调用）
|
||
> ↓
|
||
> AfterDelete （❌ 不会被调用）
|
||
> ```
|
||
>
|
||
> **如果想触发 BeforeDelete / AfterDelete：** 需要用 `Unscoped().Delete()` 执行真正的 DELETE 语句。
|
||
>
|
||
> 💡 **工程影响：** 如果你在 `BeforeDelete` 里做了级联清理（如删除 Redis Session），软删除时这些逻辑**不会执行**——需要额外处理。
|
||
|
||
### Q8.【DryRun vs Debug】
|
||
|
||
关于 DryRun 模式，以下说法**错误**的是：
|
||
|
||
A. DryRun 会构建完整 SQL 但**不执行**，零网络开销
|
||
B. DryRun 的参数占位符会保持为 `?`，不会展开为实际值
|
||
C. `Debug()` 方法会修改全局 Logger 配置，影响后续所有查询
|
||
D. 可以用 DryRun 在 CI Pipeline 中校验 struct tag 变更是否合法
|
||
|
||
> [!tip]- Q8 答案
|
||
> **C — Debug() 不影响全局配置**
|
||
>
|
||
> **解析：**
|
||
>
|
||
> | 特性 | DryRun | Debug() |
|
||
> |------|--------|---------|
|
||
> | 是否执行 SQL | ❌ 不执行 | ✅ 执行 |
|
||
> | 性能开销 | 零（无网络 IO） | 正常查询开销 |
|
||
> | 参数占位符 | 保持 `?` | 展开为实际值 |
|
||
> | 全局影响 | 无 | 无——返回新 `*gorm.DB` 实例 |
|
||
>
|
||
> **逐项分析：**
|
||
> - ✅ A：正确。DryRun 只做 SQL 构建，不走网络
|
||
> - ✅ B：正确。预编译语句的参数化就是安全的体现
|
||
> - ❌ C：**错误！** `Debug()` 返回一个新的 `*gorm.DB` 实例，原 DB 不受影响。这是函数式编程的思想
|
||
> - ✅ D：正确。可以在 CI 中跑 DryRun 验证迁移脚本不会引入破坏性变更
|
||
>
|
||
> 💡 **实战用法：** `db.Session(&gorm.Session{DryRun: true}).First(&user, 1)` 可以用于审计复杂的链式调用生成的最终 SQL。
|
||
|
||
### Q9.【Preload 与 N+1 问题】
|
||
|
||
以下代码中提到了 **N+1 问题**，请问这里的 N 指的是：
|
||
|
||
```go
|
||
var users []User
|
||
db.Preload("Orders").Find(&users)
|
||
```
|
||
|
||
A. 用户的总数
|
||
B. Orders 的总行数
|
||
C. 预处理阶段执行的次数
|
||
D. 数据库连接数
|
||
|
||
> [!tip]- Q9 答案
|
||
> **A — 用户总数**
|
||
>
|
||
> **解析：**
|
||
> Preload 的工作方式是"两步走"：
|
||
>
|
||
> ```
|
||
> SQL 1: SELECT * FROM users; ← 获取 N 个用户
|
||
> SQL 2: SELECT * FROM orders WHERE user_id IN (1,2,...); ← 一次性批量查询所有关联订单
|
||
> ```
|
||
>
|
||
> 这里的"N+1"名称来源于另一种**懒加载**（手动循环查关联）的模式：
|
||
> ```go
|
||
> var users []User
|
||
> db.Find(&users) // SQL 1: 查用户
|
||
> for _, u := range users {
|
||
> db.Where("user_id = ?", u.ID).Find(&u.Orders) // SQL 2~N+1: 每个用户一条 SQL
|
||
> }
|
||
> ```
|
||
>
|
||
> Preload 把 N+1 优化成了**恰好 2 条**（无论用户多少），因为第二条 SQL 用的是 `IN (...)` 批量查询。
|
||
>
|
||
> 💡 **延伸：** Preload 的深度是层级维度——`Preload("Orders.Products")` 变成 3 条 SQL（Users + Orders + Products），每层各一次批量 IN 查询。
|
||
|
||
### Q10.【连接池配置】
|
||
|
||
生产环境中连接池的配置，以下做法**正确**的是：
|
||
|
||
A. `SetMaxOpenConns(0)` 不设上限，让 Go 自己决定最大连接数
|
||
B. `SetConnMaxLifetime(8 * time.Hour)` 匹配 MySQL 默认的 wait_timeout
|
||
C. `SetMaxIdleConns(50)` 设为 MaxOpenConns 的一半以应对突发流量
|
||
D. `SetConnMaxLifetime(5 * time.Minute)` 小于数据库侧的 wait_timeout
|
||
|
||
> [!tip]- Q10 答案
|
||
> **D — ConnMaxLifetime 必须小于数据库 wait_timeout**
|
||
>
|
||
> **解析：**
|
||
>
|
||
> | 参数 | 常见错误 | 正确做法 |
|
||
> |------|---------|---------|
|
||
> | `MaxOpenConns` | 设为 0（无上限） | 显式设置，不超过 MySQL max_connections |
|
||
> | `MaxIdleConns` | 设得过大浪费资源 | CPU 核数或 10~20，约为 MaxOpenConns 的 10%~25% |
|
||
> | `ConnMaxLifetime` | 设为 8h 匹配 MySQL 默认 | **设为 5~10 分钟**，远小于 MySQL 的 8h wait_timeout |
|
||
> | `ConnMaxIdleTime` | 不设置 | 设为 5 分钟，减少闲置连接占用 |
|
||
>
|
||
> **关键原理：** MySQL 默认 `wait_timeout = 8h`——空闲连接超过 8 秒务端主动断开。如果 Go 的连接池不知道这一点（即 `ConnMaxLifetime >= 8h`），它会从池中取出已经断开的旧连接，导致 `server has gone away` 错误。
|
||
>
|
||
> **正确的参数关系：** `IdleTime < Lifetime << wait_timeout`
|
||
>
|
||
> 💡 **经验公式：** `MaxOpenConns = CPU核心数 × 2 + 磁盘数`。例如 4 核 2 盘 → 10（I/O 密集型可放宽到 20~50）。
|
||
|
||
---
|
||
|
||
## 二、填空题（每题 3 分，共 24 分）
|
||
|
||
> 根据知识填写空缺的代码或概念。
|
||
|
||
### Q11.【建表与表名推导】
|
||
|
||
```go
|
||
type Article struct {
|
||
ID uint
|
||
Title string
|
||
}
|
||
|
||
// GORM 推断的表名是 _________
|
||
db.AutoMigrate(&Article{})
|
||
|
||
// 显式指定表名的方法是实现 _________ 方法
|
||
```
|
||
|
||
> [!tip]- Q11 答案
|
||
> **`articles`** ； **`TableName() string`**
|
||
>
|
||
> **解析：**
|
||
> GORM 的默认命名策略是将 struct 名转为蛇形复数形式：
|
||
> - `User` → `users`
|
||
> - `Article` → `articles`
|
||
> - `OrderItem` → `order_items`
|
||
>
|
||
> `TableName()` 是 model 级别的约定，GORM 会优先使用其返回值作为表名。用值接收者 `(Article)` 而非指针 `(Article)` 是因为 GORM 内部先尝试值接收者，找不到再试指针接收者——值接收者兼容性更好。
|
||
>
|
||
> 💡 **注意：** `db.Table("custom_name")` 只在当前链式调用中生效，不会修改模型的 `TableName()` 返回值。
|
||
|
||
### Q12.【批量插入参数含义】
|
||
|
||
```go
|
||
users := make([]User, 350)
|
||
db.CreateInBatches(&users, 100).Error
|
||
```
|
||
|
||
上面代码总共执行 _____ 批 INSERT，每批最多 _____ 条记录。
|
||
|
||
> [!tip]- Q12 答案
|
||
> **4** ； **100**
|
||
>
|
||
> **解析：**
|
||
> `CreateInBatches(slice, batchSize)` 将 slice 拆分为多个批次：
|
||
>
|
||
> ```
|
||
> 350 ÷ 100 = 3.5 → 向上取整为 4 批
|
||
> 第 1 批：100 条 → INSERT INTO users VALUES (...), (...), ...
|
||
> 第 2 批：100 条
|
||
> 第 3 批：100 条
|
||
> 第 4 批：50 条 ← 剩余的不足一批的数据单独执行
|
||
> ```
|
||
>
|
||
> 如果 `batchSize = 200`：350 ÷ 200 = 1.75 → 2 批（200 + 150）
|
||
>
|
||
> 💡 **底层机制：** GORM 内部的 `Create` 也会自动拆批（约 256 条/批），但不可自定义。需要精确控制时请用 `CreateInBatches`。
|
||
|
||
### Q13.【关联查询的外键位置】
|
||
|
||
```go
|
||
type User struct {
|
||
ID uint
|
||
Name string
|
||
}
|
||
|
||
type Order struct {
|
||
ID uint
|
||
UserID uint
|
||
User User `gorm:"_________"` // 空1：声明关联类型
|
||
}
|
||
```
|
||
|
||
`Order` **属于** `User`，应使用的关联类型是 ____________（填关联类型名）；该关联的外键位于 ____________（填"当前方"或"被关联方"）的表中。
|
||
|
||
> [!tip]- Q13 答案
|
||
> **`belongsTo`** ； **当前方**
|
||
>
|
||
> **解析：**
|
||
> GORM 四种关联的核心区别在于**外键在哪张表上**：
|
||
>
|
||
> | 关联类型 | 描述 | 外键位置 | 示例 |
|
||
> |---------|------|---------|------|
|
||
> | HasOne | 一对一 | 被关联方 | User → Profile |
|
||
> | HasMany | 一对多 | 被关联方 | User → Orders |
|
||
> | BelongsTo | 多对一 | **当前方** | Order → User |
|
||
> | ManyToMany | 多对多 | 中间表 | Order ↔ Product |
|
||
>
|
||
> `BelongsTo` 表示"属于"关系——订单属于某个用户。外键 `UserID` 定义在 `Order` 表（当前方），而不是 `User` 表。
|
||
>
|
||
> 💡 **判断口诀：** "谁 belongs to 谁，外键就在谁这边"——Order belongs to User，外键在 Order 表。
|
||
|
||
### Q14.【错误判断方式】
|
||
|
||
GORM 的错误应该通过 _______________ 来判断是否等于 `gorm.ErrRecordNotFound`，而不能直接用 `==` 比较。
|
||
|
||
> [!tip]- Q14 答案
|
||
> **`errors.Is(err, gorm.ErrRecordNotFound)`**
|
||
>
|
||
> **解析：**
|
||
> GORM 的哨兵错误（如 `ErrRecordNotFound`）内部会用 `fmt.Errorf("%w", ...)` 进行包装，形成错误链。标准库的 `errors.Is()` 能逐层识别哨兵错误，而直接 `==` 比较在复杂场景中可能漏判。
|
||
>
|
||
> ```go
|
||
> result := db.First(&user, 1)
|
||
> if errors.Is(result.Error, gorm.ErrRecordNotFound) {
|
||
> // 正确处理
|
||
> }
|
||
> ```
|
||
>
|
||
> 💡 **最佳实践：** 统一使用 `errors.Is()` 做哨兵错误判断，`errors.As()` 做具体错误类型的类型断言。
|
||
|
||
### Q15.【Upsert 冲突策略】
|
||
|
||
MySQL 中 ON DUPLICATE KEY UPDATE 的等效 GORM 写法：
|
||
|
||
```go
|
||
db.Clauses(clause.OnConflict{
|
||
Columns: []clause.Column{{Name: "email"}},
|
||
DoUpdates: clause._________("last_login"), // 空1：填入方法名
|
||
}).Create(&users)
|
||
```
|
||
|
||
> [!tip]- Q15 答案
|
||
> **`AssignmentColumns`**
|
||
>
|
||
> **解析：**
|
||
> `clause.OnConflict` 支持多种冲突策略：
|
||
>
|
||
> | 方法 | 作用 | 生成 SQL |
|
||
> |------|------|---------|
|
||
> | `DoNothing` | 冲突时不做任何事 | `ON CONFLICT DO NOTHING` |
|
||
> | `AssignmentColumns(["col"])` | 冲突时更新指定列 | `ON CONFLICT DO UPDATE SET col = excluded.col` |
|
||
> | `Assignments(gorm.Expr(...))` | 自定义表达式 | `ON CONFLICT DO UPDATE SET col = expr` |
|
||
>
|
||
> 对于 PostgreSQL，同样的写法生成 `ON CONFLICT (email) DO UPDATE SET last_login = excluded.last_login;`。
|
||
>
|
||
> 💡 **进阶：** 冲突时递增计数器：
|
||
> ```go
|
||
> DoUpdates: clause.Assignments(gorm.Expr("count = count + 1"))
|
||
> ```
|
||
|
||
### Q16.【游标分页参数计算】
|
||
|
||
传统 OFFSET 分页中，第 5 页、每页 20 条数据的 Offset 值为 ________；对应的计算公式是 ________________（用变量表达）。
|
||
|
||
> [!tip]- Q16 答案
|
||
> **80** ； **`(page - 1) * pageSize`**
|
||
>
|
||
> **解析：**
|
||
>
|
||
> | 页码 | 每页数 | Offset | 结果 |
|
||
> |------|--------|--------|------|
|
||
> | 第 1 页 | 20 | (1-1)×20 = **0** | 第 1-20 条 |
|
||
> | 第 3 页 | 20 | (3-1)×20 = **40** | 第 41-60 条 |
|
||
> | 第 5 页 | 20 | (5-1)×20 = **80** | 第 81-100 条 |
|
||
>
|
||
> ```go
|
||
> offset := (page - 1) * pageSize
|
||
> db.Limit(pageSize).Offset(offset).Find(&items)
|
||
> ```
|
||
>
|
||
> 💡 **深度翻页问题：** OFFSET 80000 时数据库仍需扫描并跳过前面 80000 行。百万级数据下应改用游标分页（Keyset Pagination）。
|
||
|
||
### Q17.【批量更新字段控制】
|
||
|
||
```go
|
||
// 只更新白名单中的字段（忽略 email）
|
||
db.Model(&User{}).
|
||
Where("status = ?", "trial").
|
||
________("status", "plan"). // 空1：白名单控制
|
||
Updates(map[string]any{
|
||
"status": "active",
|
||
"plan": "pro",
|
||
"email": "should_not_change@test.com",
|
||
})
|
||
```
|
||
|
||
> [!tip]- Q17 答案
|
||
> **`Select`**
|
||
>
|
||
> **解析：**
|
||
>
|
||
> | 方法 | 类型 | 效果 |
|
||
> |------|------|------|
|
||
> | `Select("col1", "col2")` | **白名单** | 只更新指定的字段 |
|
||
> | `Omit("col1")` | **黑名单** | 除了指定字段外的其他字段全部更新 |
|
||
>
|
||
> ```go
|
||
> // 黑名单方式（排除 password）
|
||
> db.Model(&User{}).
|
||
> Omit("password", "secret_key").
|
||
> Updates(map[string]any{
|
||
> "name": "new name",
|
||
> "password": "new pass", // 被忽略
|
||
> })
|
||
> ```
|
||
>
|
||
> 两者可以组合：`Select("a", "b").Omit("b")` = 只更新 a。
|
||
>
|
||
> 💡 **注意：** `Select` 和 `Omit` 只对 `Updates` 有效，对 `Save` 和 `UpdateColumn` 等全量写入方法无效。
|
||
|
||
### Q18.【PrepareStmt 缓存机制】
|
||
|
||
开启 PrepareStmt 缓存后，GORM 使用 ____________ 存储已编译的 SQL 语句。这对 ____________ 类查询有显著的性能提升。
|
||
|
||
> [!tip]- Q18 答案
|
||
> **`sync.Map`** ； **固定模式 / 重复执行**（或"热点查询"）
|
||
>
|
||
> **解析：**
|
||
> `PrepareStmt: true` 的工作原理：
|
||
>
|
||
> 1. 第一次执行 `SELECT * FROM users WHERE id = ?` → GORM 预编译 SQL，存入 `sync.Map`
|
||
> 2. 第二次执行相同的 SQL → 直接从缓存取预编译语句，跳过解析和计划编译
|
||
>
|
||
> **适用场景：** 固定的查询模式（如按 ID 查询用户、按状态查询列表）
|
||
> **不适用场景：** 大量参数不同的动态 SQL → 缓存命中率低，徒增内存消耗
|
||
>
|
||
> ```go
|
||
> db, _ := gorm.Open(mysql.Open(dsn), &gorm.Config{
|
||
> PrepareStmt: true,
|
||
> })
|
||
> ```
|
||
>
|
||
> 💡 **重要提醒：** PrepareStmt 的缓存是**独立于连接池**的，但它仍然依赖底层连接。高并发下仍需合理配置连接池大小。
|
||
|
||
---
|
||
|
||
## 三、代码补全（每题 6 分，共 30 分）
|
||
|
||
> 补充代码中空缺的部分。有些题目有多个空。
|
||
|
||
### Q19.【级联创建与关联追加】
|
||
|
||
```go
|
||
// 创建用户的同时创建 Profile 并关联商品
|
||
user := User{
|
||
Name: "Alice",
|
||
Profile: Profile{AvatarURL: "https://example.com/avatar.png"},
|
||
Orders: []Order{
|
||
{Amount: 99.9, Products: []Product{{Name: "Book", Price: 29}}},
|
||
},
|
||
}
|
||
if err := db._________(&user).Error; err != nil { // 空1：方法名
|
||
log.Fatal(err)
|
||
}
|
||
|
||
// 给已有订单添加商品（追加，不覆盖）
|
||
product := Product{Name: "New Book", Price: 39}
|
||
db.Model(&order).Association("Products")._________(&product) // 空2：方法名
|
||
```
|
||
|
||
> [!tip]- Q19 答案
|
||
> **`Create`** ； **`Append`**
|
||
>
|
||
> **解析：**
|
||
>
|
||
> **空 1：** `db.Create(&user)` 会自动级联写入关联数据——先生成 INSERT INTO users，再 INSERT INTO profiles，最后 INSERT INTO orders。这是 GORM 的"递归保存"特性。
|
||
>
|
||
> **空 2：** Association API 提供了五个核心操作：
|
||
>
|
||
> | 方法 | 行为 | 适用场景 |
|
||
> |------|------|---------|
|
||
> | `Append` | 追加（新增不删除旧的） | 累积添加 |
|
||
> | `Replace` | 替换全部（先删旧再加新） | 重新赋值 |
|
||
> | `Delete` | 删除指定关联 | 移除单项 |
|
||
> | `Clear` | 清空所有关联 | 批量移除 |
|
||
> | `Count` | 统计关联数量 | 计数 |
|
||
>
|
||
> 💡 **Append 的 SQL 效果：** 只是向中间表 INSERT 新记录，不会影响已有的关联关系。
|
||
|
||
### Q20.【事务中的锁行读取】
|
||
|
||
```go
|
||
func TransferMoney(fromID, toID uint, amount float64) error {
|
||
return db.Transaction(func(tx *gorm.DB) error {
|
||
// 转出账户需要悲观锁，防止并发扣款超余额
|
||
var fromAccount Account
|
||
if err := tx._______("gorm:query_option", "FOR UPDATE").
|
||
First(&fromAccount, fromID).Error; err != nil { // 空1：设置查询选项的方法
|
||
return fmt.Errorf("查询转出账户失败: %w", err)
|
||
}
|
||
|
||
if fromAccount.Balance < amount {
|
||
return errors.New("余额不足")
|
||
}
|
||
|
||
fromAccount.Balance -= amount
|
||
if err := tx.________(&fromAccount).Error; err != nil { // 空2：更新账户的方法
|
||
return fmt.Errorf("扣款失败: %w", err)
|
||
}
|
||
|
||
var toAccount Account
|
||
if err := tx.First(&toAccount, toID).Error; err != nil {
|
||
return fmt.Errorf("查询入账账户失败: %w", err)
|
||
}
|
||
toAccount.Balance += amount
|
||
if err := tx.Save(&toAccount).Error; err != nil {
|
||
return fmt.Errorf("入账失败: %w", err)
|
||
}
|
||
|
||
return nil // 返回 nil → 自动 Commit
|
||
})
|
||
}
|
||
```
|
||
|
||
> [!tip]- Q20 答案
|
||
> **`Set`** ； **`Save`**
|
||
>
|
||
> **解析：**
|
||
>
|
||
> **空 1：** `tx.Set("key", value)` 用于在查询中携带额外的 session 级选项。`"gorm:query_option"` 是一个内置键名，GORM 会将其原样拼接到 SQL 末尾——`SELECT ... FOR UPDATE` 就是在数据库层面加排他锁，防止其他事务同时读取并修改同一行。
|
||
>
|
||
> **空 2：** `Save` 是全量更新，无视零值全部写回。这里用 `Save` 是因为需要确保 `Balance` 字段的最新值被持久化。
|
||
>
|
||
> ```go
|
||
> // FOR UPDATE 的效果对比：
|
||
> // ❌ 无锁：两个并发请求同时读到 Balance=100，都扣 60，结果 Balance=-20（超卖）
|
||
> // ✅ 有锁：第二个请求必须等待第一个事务结束后才能读，保证原子性
|
||
> ```
|
||
>
|
||
> 💡 **延伸：** PostgreSQL 同样使用 `SELECT ... FOR UPDATE`；SQLite 默认串行执行事务，不需要显式加锁。
|
||
|
||
### Q21.【条件预加载 + 排序】
|
||
|
||
```go
|
||
// 加载用户及其订单，但只加载金额大于 100 的订单，并按金额降序排列
|
||
db.Preload("Orders", func(db *gorm.DB) *gorm.DB {
|
||
return db._______("amount > ?", 100).
|
||
_________("amount DESC")
|
||
}).Find(&users)
|
||
```
|
||
|
||
> [!tip]- Q21 答案
|
||
> **`Where`** ； **`Order`**
|
||
>
|
||
> **解析：**
|
||
> `Preload` 的第二个参数可以是函数形式的条件构造器：
|
||
>
|
||
> ```go
|
||
> db.Preload("AssociationName", func(db *gorm.DB) *gorm.DB {
|
||
> return db.Where("condition").Order("field")
|
||
> }).Find(&parent)
|
||
> ```
|
||
>
|
||
> 这个函数的签名固定为 `func(*gorm.DB) *gorm.DB`——接收 DB 实例，返回修饰后的 DB 实例。可以在里面自由链式调用 `Where`、`Order`、`Limit`、`Select` 等方法。
|
||
>
|
||
> 💡 **注意：** 函数形式的条件只适用于 Preload，不适用于 Joins。Joins 的条件需要写在 `Joins("Table", "condition")` 的第二个参数中。
|
||
|
||
### Q22.【JSON 自定义类型的 Scanner】
|
||
|
||
```go
|
||
type JSONMap map[string]interface{}
|
||
|
||
// Scan 方法负责从数据库读出数据（DB → Go）
|
||
func (j *JSONMap) Scan(value interface{}) error {
|
||
if value == nil {
|
||
*j = nil
|
||
return nil
|
||
}
|
||
str, ok := value._________ // 空1：类型断言
|
||
if !ok {
|
||
str = []byte(fmt.Sprintf("%v", value))
|
||
}
|
||
return json.Unmarshal(str, j) // 空2：反序列化的目标
|
||
}
|
||
```
|
||
|
||
> [!tip]- Q22 答案
|
||
> **`([]byte)`** ； **`j`**（指针接收者本身）
|
||
>
|
||
> **解析：**
|
||
> `sql.Scanner` 接口定义了 `Scan(value interface{}) error` 方法，由 GORM 在查询后调用，将数据库读出的原始值转换为 Go 类型。
|
||
>
|
||
> ```go
|
||
> type Scanner interface {
|
||
> Scan(value interface{}) error
|
||
> }
|
||
> ```
|
||
>
|
||
> **流程分解：**
|
||
> 1. `value` 是从数据库来的原始字节数组 `[]byte`
|
||
> 2. 类型断言 `value.([]byte)` 提取字节切片
|
||
> 3. `json.Unmarshal(str, j)` 将 JSON 反序列化到 `*JSONMap`（指针接收者，这样才能修改外部结构体）
|
||
>
|
||
> 💡 **为什么用指针接收者？** `Scan` 需要将反序列化后的内容**写回**目标对象。如果用值接收者 `(j JSONMap)`，修改的只是副本，原始结构体不会被改变。同理 `Value()` 用值接收者 `(j JSONMap)` 是因为只需读不需写。
|
||
|
||
### Q23.【事务内的条件检查与日志输出】
|
||
|
||
```go
|
||
func ExecTx(db *gorm.DB, fn func(tx *gorm.DB) error) error {
|
||
tx := db.Begin()
|
||
defer func() {
|
||
if r := recover(); r != nil {
|
||
tx._________ // 空1：出错时回滚
|
||
panic(r)
|
||
}
|
||
}()
|
||
|
||
if err := fn(tx); err != nil {
|
||
tx.Rollback()
|
||
return err
|
||
}
|
||
return tx.__________.Error // 空2：提交事务的方法
|
||
}
|
||
```
|
||
|
||
> [!tip]- Q23 答案
|
||
> **`Rollback()`** ； **`Commit()`**
|
||
>
|
||
> **解析：**
|
||
> 这是一个通用的事务封装函数 `ExecTx`，消除了每个业务函数里重复的 Begin/Rollback 样板代码。
|
||
>
|
||
> ```go
|
||
> // 使用方式
|
||
> err := ExecTx(db, func(tx *gorm.DB) error {
|
||
> // 业务逻辑...
|
||
> return nil // 成功 → ExecTx 自动 Commit
|
||
> }) // 失败 → ExecTx 自动 Rollback
|
||
> ```
|
||
>
|
||
> **关键点：**
|
||
> 1. `defer` 只在 panic 分支中执行 `Rollback()`，正常路径不调用——避免 Commit 后再 Rollback 报错
|
||
> 2. `tx.Commit()` 返回 `*gorm.DB`（和大多数 GORM 方法一样），`.Error` 获取最终结果
|
||
>
|
||
> 💡 **对比：** 简单场景直接用 `db.Transaction(callback)` 即可，代码更简洁。复杂业务（如跨包传递 tx）才需要 `ExecTx` 这样的封装。
|
||
|
||
---
|
||
|
||
## 四、主观题（每题 4 分，共 16 分）
|
||
|
||
> 简要回答即可，不需要长篇大论。关键是说出你的理解。
|
||
|
||
### Q24.【何时不该用事务？】
|
||
|
||
以下场景中哪些**不需要**用事务？请给出理由。
|
||
|
||
① 单条 `INSERT` 记录
|
||
② 转账：扣 A 加 B
|
||
③ COUNT / SUM 统计查询
|
||
④ 下单：减库存 + 创建订单 + 生成流水
|
||
|
||
> [!tip]- Q24 参考答案
|
||
>
|
||
> ① **不需要**——单条 INSERT 本身就是原子操作，数据库层面保证了要么全成功要么全失败，无需额外的事务包裹。
|
||
>
|
||
> ② **必须用事务**——涉及两笔以上的资金变动，如果没有事务，可能出现"A 扣了钱但 B 没到账"的数据不一致。
|
||
>
|
||
> ③ **不需要**——只读查询不涉及数据修改，不存在一致性问题。可以使用普通查询 + 缓存来减轻数据库压力。
|
||
>
|
||
> ④ **必须用事务**——三步操作具有业务原子性要求：如果减库存成功但创建订单失败，会导致库存少了但没有对应订单。
|
||
>
|
||
> **总结：** 涉及多步数据写入且要求原子性的场景才需要事务。单条写入、只读查询都可以免去事务开销。
|
||
|
||
### Q25.【软删除 + 唯一索引冲突】
|
||
|
||
某电商系统中 `Product.SKU` 设置了 `uniqueIndex`。现有记录 SKU="ABC-123" 已被软删除。此时还能再次创建 SKU="ABC-123" 的新产品吗？MySQL 和 PostgreSQL 的行为是否一致？说明原因和你的解决方案。
|
||
|
||
> [!tip]- Q25 参考答案
|
||
>
|
||
> **不一致！**
|
||
>
|
||
> - **MySQL（InnoDB）：** ✅ 可以插入。InnoDB 在处理软删除行的唯一约束时有历史缺陷——已软删除的行不参与唯一约束检查，所以允许两条 SKU 相同的记录存在（一条被删，一条未删）。但这意味着可能出现"同一 SKU 多条有效记录"的数据不一致。
|
||
> - **PostgreSQL：** ❌ 不能插入。PG 的正确行为是唯一约束包含软删除行，会报 duplicate key 错误。
|
||
>
|
||
> **解决方案：**
|
||
> 1. **方案一（PG）：** 用部分唯一索引 `CREATE UNIQUE INDEX ... WHERE deleted_at IS NULL`，只约束未删除行
|
||
> 2. **方案二（通用）：** 加版本字段 `SlugVersion uint`，保证同一 SKU 不会同时出现在两条未删除记录中
|
||
> 3. **方案三：** 应用层校验——插入前先检查是否有未删除的同 SKU 记录
|
||
>
|
||
> 💡 **核心教训：** 不要依赖单一数据库的行为一致性，应在应用层做好校验。
|
||
|
||
### Q26.【BeforeUpdate Changed 的最佳实践】
|
||
|
||
```go
|
||
func (u *User) BeforeUpdate(tx *gorm.DB) error {
|
||
if tx.Statement.Changed("Password") {
|
||
hashed, _ := bcrypt.GenerateFromPassword([]byte(u.Password), bcrypt.DefaultCost)
|
||
u.Password = string(hashed)
|
||
}
|
||
return nil
|
||
}
|
||
```
|
||
|
||
为什么要用 `Changed("Password")` 判断，而不直接在 `BeforeUpdate` 里无条件哈希？这样做有什么优势？
|
||
|
||
> [!tip]- Q26 参考答案
|
||
>
|
||
> 核心原因是**避免重复哈希**。
|
||
>
|
||
> 如果无条件哈希，每次 UPDATE 操作（即使改的是名字或邮箱）都会重新对密码做 bcrypt 哈希。bcrypt 故意很慢（计算密集型），频繁调用会带来不必要的性能开销。
|
||
>
|
||
> 此外，如果用户修改了其他字段但未修改密码，数据库执行的是 `Updates(struct)`——`Password` 字段不在 struct 中参与更新，但前面的哈希操作仍然白白浪费了 CPU。
|
||
>
|
||
> `Changed("Password")` 的作用：只有当 `Updates(map)` 的 map 中确实包含了 `password` 键时才执行哈希。这样既保证了安全性（密码改了就加密），又避免了不必要的计算。
|
||
>
|
||
> 💡 **注意：** `Changed` 只对 `Updates` 方法有效，`Save` 是全量写入不会追踪变化。
|
||
|
||
### Q27.【AutoMigrate 的局限性与替代方案】
|
||
|
||
为什么生产环境不推荐仅靠 `AutoMigrate` 管理数据库迁移？请至少列举三条原因，并简述推荐的替代方案。
|
||
|
||
> [!tip]- Q27 参考答案
|
||
>
|
||
> **三条原因：**
|
||
>
|
||
> 1. **不可回滚：** AutoMigrate 只能"加"不能"减"。当代码回退到旧版本时，它无法撤销已添加的列或索引——只会跳过已存在的部分。版本化迁移方案通过 Down 脚本可以轻松应对回退场景。
|
||
>
|
||
> 2. **不可预测：** GORM 内部决定迁移的执行顺序和具体 ALTER 语句，不同数据库方言的行为可能不一致。版本化迁移用手写 SQL，完全可控。
|
||
>
|
||
> 3. **团队协作困难：** 每个人改了 model 就 auto migrate，容易产生冲突和不一致。版本化迁移通过文件合并可以更好地管理多人协作。
|
||
>
|
||
> **推荐替代方案：** 本地开发用 `AutoMigrate + DryRun` 快速迭代，生产环境用专门的迁移工具（如 Goose 或 golang-migrate），手写版本化的 Up/Down SQL 脚本。这样既享受了开发便利，又保证了生产环境的可控性和可回滚能力。
|
||
|
||
---
|
||
|
||
## 评分参考
|
||
|
||
| 题目类型 | 满分 | 权重 |
|
||
|---------|------|------|
|
||
| 选择题（Q1-Q10） | 30 分 | 30% |
|
||
| 填空题（Q11-Q18） | 24 分 | 24% |
|
||
| 代码补全（Q19-Q23） | 30 分 | 30% |
|
||
| 主观题（Q24-Q27） | 16 分 | 16% |
|
||
| **总计** | **100 分** | **100%** |
|
||
|
||
**及格线：** ≥70 分
|
||
**优秀线：** ≥85 分
|