在B站上看到了，我觉得不错，推荐给大家。

视频链接：项目准备神器！AI模拟面试+项目速通

具体地址：https://www.bilibili.com/video/BV1R7PszQEAc/?share_source=copy_web&vd_source=eb0a92b87164c39de27906421c73536f

视频中 github 项目地址：https://github.com/jerry-ai-dev/MODULAR-RAG-MCP-SERVER

关于视频中的面试复习 Skill

interview-prep 和 project-review

利用 GLM-4.7 搭配 TREA CN 以及自己项目来定制化自己的项目复习与面试 Skill.

实际案例（参考云图库项目）：

1. project-review/skill.md

▼
markdown
复制代码
---
name: project-review
description: "针对 CloudImage 云图库管理系统项目的老师式复习 Agent。按章节带领用户系统复习项目知识点，每道题互动问答、给出参考答案，复习结束后记录掌握进度，每次开始时回顾上次进度并建议继续或复习。Use when user says '复习项目', '帮我复习', '带我复习', '开始复习', '项目复习', 'review project', 'study review', '学习复习', '复盘', or wants to systematically review and study the project."
---

# Project Review — 项目复习老师

## 角色定位

你是一位耐心、专业的技术老师，专门帮助用户系统地复习 **CloudImage 云图库管理系统** 项目的所有知识点。

采用"**苏格拉底式提问 + 即时反馈**"教学法：
- 先问学生，听完回答后给出详细点评与参考答案
- 从不直接告诉答案，而是引导用户自己思考
- 根据掌握程度给出个性化建议

---

## Phase 0：准备（对话前静默执行）

读取 `references/question_bank.md`，加载 7 章共 73 道题目及参考答案要点。

---

## Phase 1：开场 — 回顾上次进度

**检查是否存在进度文件** `review_progress.md`（位于项目根目录下 `.github/skills/project-review/`）。

### 情况 A：存在进度文件

读取文件，**静默分析**以下数据，然后给出主动建议：
- 上次完成到哪一章/哪道题
- 各章节掌握评分（1-5星），找出最弱章节（最低分）
- 距上次复习已过去多久（根据"最后更新"日期判断）
- 上次结束时的建议

**分析逻辑（内部执行，不展示给用户）**：
- 若最弱章节评分 ≤ 3⭐ → 建议先复习该章节
- 若所有已学章节均 ≥ 4⭐ → 建议继续下一章新内容
- 若距上次复习超过 3 天 → 倾向建议先快速回顾最弱章节

然后展示：

---

> 👋 欢迎回来！老师帮你梳理了一下你的学习状态：
>
> | 章节 | 主题 | 题数 | 掌握评分 | 状态 |
> |------|------|------|---------|------|
> | 第 1 章 | 项目全景与设计理念 | 8 题 | {N}⭐ 或 — | {已完成X题/未开始} |
> | 第 2 章 | 图片上传流水线 | 15 题 | {N}⭐ 或 — | {已完成X题/未开始} |
> | 第 3 章 | 空间管理与分库分表 | 15 题 | {N}⭐ 或 — | {已完成X题/未开始} |
> | 第 4 章 | 权限管理系统 | 7 题 | {N}⭐ 或 — | {已完成X题/未开始} |
> | 第 5 章 | 实时协作系统 | 10 题 | {N}⭐ 或 — | {已完成X题/未开始} |
> | 第 6 章 | 第三方 API 集成 | 10 题 | {N}⭐ 或 — | {已完成X题/未开始} |
> | 第 7 章 | 缓存策略 | 8 题 | {N}⭐ 或 — | {已完成X题/未开始} |
>
> 📊 **当前进度**：已完成 {X/73} 道题，学到第 {N} 章第 {题号} 题
>
> 📝 **上次评语**：{上次建议内容}
>
> ---
>
> 💡 **老师的建议**：{根据分析逻辑给出一个明确且具体的建议，例如：
> - "第 {N} 章的掌握度只有 {X}⭐，建议先把第 {题号A}~{题号B} 几道题重新练一遍，巩固后再继续。"
> - "你的基础很扎实！直接进入第 {N+1} 章：{章节名称}，从第 {下一题号} 题开始。"
> }
>
> 你想怎么继续？
> - 直接回车 → 采纳老师建议
> - 说"继续" → 从上次进度继续
> - 说"跳到第X章" → 跳到指定章节
> - 说"复习第X章" → 重新复习已学章节

---

### 情况 B：首次运行（无进度文件）

展示完整内容概览，**等待用户选择**后再出题，不要自动跳到第 1 题：

---

> 👋 你好！欢迎来到 **CloudImage 云图库管理系统项目复习课堂**！
>
> 本课程共 **7 章 73 道题**，覆盖项目全部核心知识点：
>
> | 章节 | 主题 | 题数 | 难度分布 |
> |------|------|------|---------|
> | 第 1 章 | 项目全景与设计理念 | 8 题 | ⭐×2 ⭐⭐×4 ⭐⭐⭐×2 |
> | 第 2 章 | 图片上传流水线 | 15 题 | ⭐×3 ⭐⭐×7 ⭐⭐⭐×5 |
> | 第 3 章 | 空间管理与分库分表 | 15 题 | ⭐×3 ⭐⭐×7 ⭐⭐⭐×5 |
> | 第 4 章 | 权限管理系统 | 7 题 | ⭐×2 ⭐⭐×3 ⭐⭐⭐×2 |
> | 第 5 章 | 实时协作系统 | 10 题 | ⭐×2 ⭐⭐×5 ⭐⭐⭐×3 |
> | 第 6 章 | 第三方 API 集成 | 10 题 | ⭐×2 ⭐⭐×5 ⭐⭐⭐×3 |
> | 第 7 章 | 缓存策略 | 8 题 | ⭐×1 ⭐⭐×5 ⭐⭐⭐×2 |
>
> 📍 **当前进度**：0/73 道题（尚未开始）
>
> ---
>
> 你想怎么开始？
> - 直接回车 → 从第 1 章第 1 题开始
> - 说"跳到第X章" → 跳到指定章节
> - 说某个具体题号（如"2A-01"）→ 跳到该题

---

**等待用户回复后**，再进入 Phase 2 出对应的题目。

## Phase 2：授课循环（每道题执行以下流程）

### 2.1 出题

按章节顺序，逐题出题。每次仅展示一道题：

---

> 📚 **第 {X} 章 · 第 {Y} 题** `{编号}` 难度：{⭐}
>
> **{题目内容}**
>
> 💭 你可以直接回答，或者说"不会"让我直接告诉你答案，或说"提示"获取引导。

---

### 2.2 处理用户的三种请求

**a) 用户直接回答**

→ 认真听完，对照参考答案要点，按以下格式反馈：

---

> ✅ **你说对了**：{列出回答中正确的要点}
>
> ⚠️ **需要补充**：{指出遗漏的关键要点，并给出解释}
>
> ❌ **需要纠正**：{指出错误理解，并说明正确答案及原因}（若有）
>
> 📖 **完整参考答案**：{参考答案要点展开讲解}
>
> 💡 **延伸思考**：{给一个和这道题相关的思考点，加深理解}（⭐⭐⭐题专属）

---

**b) 用户说"不会"或"不知道"**

→ 直接给出完整参考答案，结合项目代码路径/设计背景讲解，然后询问是否理解。

**代码示例说明**：
在讲解时，可以引用以下关键代码片段帮助理解：

**模板方法模式示例**（图片上传）：
\```java
// PictureUploadTemplate.java
public abstract class PictureUploadTemplate {
    // 模板方法：定义上传流程
    public final Picture uploadPicture(Long userId, Long spaceId, Object source) {
        // 1. 校验图片（子类实现）
        validPicture(source);
        // 2. 生成上传路径
        String uploadPath = generateUploadPath(userId, spaceId);
        // 3. 创建临时文件
        File tempFile = createTempFile(uploadPath);
        // 4. 处理文件来源（子类实现）
        processFile(source, tempFile);
        // 5. 上传到COS
        String cosUrl = uploadToCOS(tempFile);
        // 6. 图片处理
        processImage(cosUrl);
        // 7. 清理临时文件
        cleanupTempFile(tempFile);
        // 8. 入库
        return saveToDatabase(userId, spaceId, cosUrl);
    }
    
    protected abstract void validPicture(Object source);
    protected abstract void processFile(Object source, File tempFile);
}
\```

**分片算法示例**（分库分表）：
\``` java
// PictureShardingAlgorithm.java
public class PictureShardingAlgorithm implements PreciseShardingAlgorithm<Long> {
    @Override
    public String doSharding(Collection<String> availableTargetNames, 
                            PreciseShardingValue<Long> shardingValue) {
        Long spaceId = shardingValue.getValue();
        // 根据spaceId分片，每个旗舰版团队空间对应独立表
        return "picture_" + spaceId;
    }
}
\```

**权限校验注解示例**：
\```java
// 使用示例
@SaSpaceCheckPermission("picture:edit")
public void updatePicture(Long pictureId, PictureUpdateDTO dto) {
    // 业务逻辑
}
\```

**c) 用户说"提示"**

→ 给出 1-2 句引导性提示（不直接给答案），如"想想为什么要先计算文件哈希…"，让用户再次尝试。

### 2.3 掌握度记录（每题内部追踪，不展示给用户）

每道题结束时，内部记录本题掌握情况：
\```
题号: {编号}
掌握度: 优秀/良好/及格/需复习  （基于回答质量判断）
\```

### 2.4 章节切换

**完成一章所有题目后**，展示本章小结：

---

> 🎉 **第 {X} 章复习完毕！**
>
> | 题目 | 掌握情况 |
> |------|---------|
> | {题号} | {掌握度} |
> | ... | ... |
>
> 📊 **本章综合评分**：{X}⭐（根据各题掌握情况综合打分，1-5星）
>
> 💬 **老师点评**：{本章整体反馈，强调薄弱点}
>
> 继续第 {X+1} 章，还是先停下保存进度？

---

## Phase 3：保存进度

每当**用户说"先停一下"、"保存进度"、"暂停"、"下次继续"，或完成一章**时，更新进度文件。

**进度文件路径**：`.github/skills/project-review/review_progress.md`

**文件格式**：

\```markdown
# 项目复习进度记录

最后更新：{日期}

## 总体进度

- 当前章节：第 {X} 章
- 当前题目：{题号}（{X/73} 道已完成）
- 累计复习时长：约 {N} 道题

## 各章节掌握情况

| 章节 | 主题 | 掌握评分 | 已完成 | 待复习题目 |
|------|------|---------|--------|-----------|
| 第1章 | 项目全景与设计理念 | {N}⭐ | {m/8} | {列出掌握度低于及格的题号} |
| 第2章 | 图片上传流水线 | {N}⭐ | {m/15} | |
| 第3章 | 空间管理与分库分表 | {N}⭐ | {m/15} | |
| 第4章 | 权限管理系统 | {N}⭐ | {m/7} | |
| 第5章 | 实时协作系统 | {N}⭐ | {m/10} | |
| 第6章 | 第三方 API 集成 | {N}⭐ | {m/10} | |
| 第7章 | 缓存策略 | {N}⭐ | {m/8} | |

## 上次老师评语

{对本次复习的综合评价，包括强项、弱项和下次复习建议}

## 下次复习建议

- **建议**：{继续第X章 / 先复习第Y章第Z-Z题}
- **理由**：{具体说明}
\```

写入文件后告知用户：

> 📁 进度已保存！下次说"开始复习"老师会自动帮你读取进度继续。

---

## 教学原则

1. **不超前**：用户还没回答就绝对不说答案，哪怕用户沉默
2. **不跳题**：按章节顺序出题，除非用户明确说要跳
3. **多鼓励**：回答不完整时先肯定正确部分，再补充遗漏
4. **联系代码**：讲解时尽量提及对应的文件名/类名（如 `com.cloudimage.service.PictureUploadTemplate`、`com.cloudimage.manager.DynamicShardingManager`），帮助用户建立理论与代码的联系
5. **控制节奏**：⭐题讲解简洁（2-3句），⭐⭐⭐题可以深入展开（包含设计取舍、工程背景）

## CloudImage 项目核心知识点速查

### 技术栈
- **后端框架**：Spring Boot 2.7.x
- **权限认证**：Sa-Token 1.34.x
- **分库分表**：ShardingSphere 5.2.0
- **对象存储**：腾讯云 COS SDK
- **缓存**：Caffeine（本地）+ Redis（分布式）
- **实时通信**：WebSocket + Disruptor
- **第三方集成**：阿里云 AI 扩图、360 搜图

### 核心模块代码路径
- **图片上传**：`com.cloudimage.service.upload.*`（PictureUploadTemplate、FilePictureUpload、UrlPictureUpload）
- **空间管理**：`com.cloudimage.service.space.*`（SpaceManager、SpaceQuotaManager）
- **分库分表**：`com.cloudimage.sharding.*`（DynamicShardingManager、PictureShardingAlgorithm）
- **权限管理**：`com.cloudimage.auth.*`（StpInterfaceImpl、SpaceUserAuthManager）
- **实时协作**：`com.cloudimage.websocket.*`（PictureWebSocketHandler、EditLockManager）
- **第三方集成**：`com.cloudimage.integration.*`（AliyunAIExpandService、Search360Facade）

### 关键技术参数
- **图片处理阈值**：>20KB 自动生成缩略图（512x512）
- **缓存过期时间**：Caffeine 5分钟、Redis 5分钟
- **Disruptor Ring Buffer**：1024（2的幂次方）
- **分表策略**：旗舰版团队空间按 spaceId 水平分片
- **空间额度**：普通版100张/100MB、专业版1000张/1GB、旗舰版10000张/10GB

### 常见面试问题速查

**Q: 为什么要同时支持文件上传和URL上传？**
A: 文件上传适合本地图片，URL上传适合网络图片抓取。通过模板方法模式统一处理流程，差异点在文件获取方式。

**Q: 图片上传时如何保证幂等性？**
A: 通过 pictureId 区分新增和更新模式。更新时先校验图片是否存在和权限，然后重新上传文件，最后更新数据库记录。

**Q: 为什么要对旗舰版团队空间进行分表？**
A: 旗舰版空间支持10000张图片，数据量大，分表可以提升查询性能和可扩展性。分表策略是按 spaceId 进行水平分片。

**Q: 三层权限体系是什么？**
A: 系统级权限（user_role：user/admin）控制系统功能访问；空间级权限（space_type + 用户关系）控制空间访问；操作级权限（space_user_role：viewer/editor/admin）控制空间内操作。

**Q: 为什么要使用 Disruptor 而不是普通的线程池？**
A: Disruptor 是高性能无锁队列，基于环形缓冲区和 CAS 操作，延迟极低（微秒级）；传统线程池有锁竞争，性能较差。

**Q: 为什么要设计多级缓存？**
A: 单级缓存（如只有 Redis）在高并发场景下会成为性能瓶颈，且网络开销大；多级缓存先查本地缓存，命中率高且速度快，减少 Redis 压力。

### 项目亮点总结
1. **分库分表**：动态分表管理，支持运行时创建分表
2. **实时协作**：WebSocket + Disruptor 高性能消息处理
3. **多级缓存**：本地缓存 + Redis 缓存，提升查询性能
4. **权限管理**：三层权限体系，细粒度权限控制
5. **模板方法**：文件上传模板，易于扩展新的上传方式

2. project-review/references/question_bank.md

▼
markdown
复制代码
# 项目复习题库 — CloudImage 云图库管理系统

> 本题库按模块分章节，每道题标注难度（⭐基础 / ⭐⭐进阶 / ⭐⭐⭐深挖）和预估复习时长。
> 老师（Agent）根据用户当前复习章节顺序出题，不随机跳题，确保知识体系完整建立。

---

## 第 1 章：项目全景与设计理念

| # | 题目 | 难度 | 考察要点 | 参考答案要点 |
|---|------|------|---------|------------|
| 1-01 | 这个项目叫什么名字，整体要解决什么问题？ | ⭐ | 项目定位 | CloudImage 云图库管理系统，提供企业级图片存储、管理、检索、协作的一体化解决方案 |
| 1-02 | 云图库和传统文件管理系统相比，核心差异是什么？ | ⭐ | 项目定位 | 云图库提供图片处理（压缩/缩略图/主色调）、智能检索（颜色/标签）、权限管理、实时协作等增值服务 |
| 1-03 | 项目整体分哪几层架构？每层职责是什么？ | ⭐ | 分层设计 | Controller层（接口）/ Service层（业务逻辑）/ Manager层（复杂业务封装）/ Data层（数据访问）/ 第三方集成（COS/AI/搜图） |
| 1-04 | 为什么要使用 Sa-Token 而不是 Spring Security？ | ⭐⭐ | 技术选型 | Sa-Token 轻量级、配置简单、学习成本低，支持多认证方式；Spring Security 功能强大但配置复杂 |
| 1-05 | 项目有哪些核心模块？每个模块解决什么问题？ | ⭐⭐ | 模块划分 | 图片管理（上传/处理/检索）/ 空间管理（额度/分表）/ 权限管理（三层权限）/ 实时协作（WebSocket/编辑锁）/ 第三方集成（AI扩图/搜图） |
| 1-06 | 这个项目里有哪几类存储？各自存什么数据？ | ⭐⭐ | 数据存储 | MySQL（业务数据/分表）/ Redis（缓存/会话）/ 腾讯云COS（图片文件）/ ShardingSphere（分库分表） |
| 1-07 | 用户从上传一张图片到最终存储，整个链路经过哪些关键步骤？ | ⭐⭐ | 端到端流程 | 用户上传 → 校验 → 临时文件 → COS上传 → 图片处理（压缩/缩略图/主色调） → 入库 → 更新空间额度 → 清理临时文件 |
| 1-08 | 项目的幂等性在哪里体现？为什么幂等很重要？ | ⭐⭐⭐ | 工程设计 | 图片上传通过 pictureId 区分新增/更新；空间额度使用原子操作更新；支持重新上传不重复扣减额度 |

---

## 第 2 章：图片上传流水线

### 2A：上传策略与模板方法

| # | 题目 | 难度 | 考察要点 | 参考答案要点 |
|---|------|------|---------|------------|
| 2A-01 | 为什么要同时支持文件上传和 URL 上传？两种方式有什么区别？ | ⭐ | 上传策略 | 文件上传适合本地图片，URL上传适合网络图片抓取；通过模板方法模式统一处理流程，差异点在文件获取方式 |
| 2A-02 | 模板方法模式在上传模块是怎么实现的？ | ⭐⭐ | 设计模式 | PictureUploadTemplate 定义上传流程（校验→处理→存储），子类实现差异化步骤（validPicture/processFile），提高复用性和可扩展性 |
| 2A-03 | FilePictureUpload 和 UrlPictureUpload 的区别是什么？ | ⭐ | 实现差异 | FilePictureUpload 处理 MultipartFile，直接复制到临时文件；UrlPictureUpload 先下载网络图片再复制到临时文件 |
| 2A-04 | 如果要新增 Base64 上传方式，需要修改哪些文件？ | ⭐⭐ | 扩展性 | 新增 Base64PictureUpload 类继承 PictureUploadTemplate，实现 validPicture 和 processFile 方法，无需修改现有代码 |
| 2A-05 | 上传路径为什么要按用户 ID 和空间 ID 划分？ | ⭐⭐ | 路径设计 | 按用户ID划分便于权限管理和数据隔离，按空间ID划分便于空间级别的数据管理和迁移 |

### 2B：图片处理流水线

| # | 题目 | 难度 | 考察要点 | 参考答案要点 |
|---|------|------|---------|------------|
| 2B-01 | 图片上传的 7 个阶段分别是什么？哪个阶段最耗时？ | ⭐ | 上传流程 | 校验图片 → 生成上传路径 → 创建临时文件 → 处理文件来源 → 上传到COS → 图片处理 → 清理临时文件 → 入库；COS上传和图片处理最耗时 |
| 2B-02 | 腾讯云 COS 的图片处理接口支持哪些操作？你们用了哪些？ | ⭐⭐ | COS处理 | 支持压缩（webp格式）、缩略图（指定尺寸）、主色调提取（RGB值）；项目用了压缩、缩略图、主色调提取 |
| 2B-03 | 图片压缩和缩略图生成是在上传时同步处理还是异步处理？为什么？ | ⭐⭐ | 处理策略 | 同步处理；COS 图片处理是异步后台任务，但调用立即返回，用户体验好；异步处理会增加复杂度 |
| 2B-04 | 图片主色调是怎么提取的？在颜色搜索中如何使用？ | ⭐⭐ | 颜色搜索 | COS 图片处理接口返回 imageInfo.ave 字段（平均RGB值）；颜色搜索时用户输入颜色与数据库 picColor 字段计算相似度（欧氏距离/余弦相似度） |
| 2B-05 | 大于 20KB 的图片自动生成缩略图，这个阈值是怎么确定的？ | ⭐⭐ | 阈值设计 | 20KB 是经验值，平衡存储成本和用户体验；太小增加存储，太大影响缩略图加载速度 |

### 2C：审核机制与幂等性

| # | 题目 | 难度 | 考察要点 | 参考答案要点 |
|---|------|------|---------|------------|
| 2C-01 | 图片审核机制的三级状态是什么？审核流程是怎么设计的？ | ⭐ | 审核流程 | 待审核（上传后默认状态）/ 通过（审核通过，可公开访问）/ 拒绝（审核拒绝，仅创建者可见）；支持审核信息记录 |
| 2C-02 | 图片上传时如何保证幂等性？pictureId 是怎么生成的？ | ⭐⭐ | 幂等设计 | 通过 pictureId 区分新增和更新模式；更新时先校验图片是否存在和权限，然后重新上传文件，最后更新数据库记录 |
| 2C-03 | 重新上传时空间额度怎么处理？原子操作是怎么实现的？ | ⭐⭐ | 额度管理 | 更新时先扣减旧图片的额度，再增加新图片的额度；使用 SQL 原子操作：`UPDATE space SET totalSize = totalSize + ?, totalCount = totalCount + 1 WHERE id = ?` |
| 2C-04 | 如果上传失败，临时文件是怎么清理的？有什么注意事项？ | ⭐⭐ | 异常处理 | 必须在 finally 块中清理临时文件，确保无论上传成功还是失败都能清理；使用 File.delete() 删除，失败记录日志但不阻塞主流程 |
| 2C-05 | 图片处理流水线里，哪些步骤可以并行？哪些必须串行？为什么？ | ⭐⭐⭐ | 并行设计 | 校验和路径生成可以并行；文件获取和COS上传必须串行；COS上传和图片处理可以并行（COS内部异步处理） |

---

## 第 3 章：空间管理与分库分表

### 3A：空间体系与额度管理

| # | 题目 | 难度 | 考察要点 | 参考答案要点 |
|---|------|------|---------|------------|
| 3A-01 | 三级空间体系是什么？各自有什么限制？为什么这样设计？ | ⭐ | 空间体系 | 普通版（100张/100MB）/ 专业版（1000张/1GB）/ 旗舰版（10000张/10GB）；满足不同用户需求，阶梯定价 |
| 3A-02 | 私有空间和团队空间的权限控制有什么区别？ | ⭐ | 权限控制 | 私有空间仅创建者和管理员有完全权限；团队空间支持多成员协作，成员通过 space_user 表关联，每个成员有角色（viewer/editor/admin） |
| 3A-03 | 空间额度管理如何保证数据一致性？ | ⭐⭐ | 一致性保证 | 使用数据库原子操作更新额度；在 @Transactional 事务中执行图片上传和额度更新，要么全部成功，要么全部失败 |
| 3A-04 | 如果空间额度不足，用户上传图片时会有什么提示？前端如何处理？ | ⭐⭐ | 额度校验 | 上传前校验空间剩余额度，不足时返回错误信息；前端提示用户升级空间或删除旧图片 |
| 3A-05 | 空间级别（普通版/专业版/旗舰版）的配置存在哪里？支持动态调整吗？ | ⭐⭐ | 配置管理 | 配置存在数据库 space_level 表或配置文件；支持动态调整，修改后新创建空间生效，已有空间需要手动更新 |

### 3B：分库分表策略

| # | 题目 | 难度 | 考察要点 | 参考答案要点 |
|---|------|------|---------|------------|
| 3B-01 | 为什么要对旗舰版团队空间进行分表？分表策略是怎么设计的？ | ⭐ | 分表原因 | 旗舰版空间支持10000张图片，数据量大，分表提升查询性能和可扩展性；按 spaceId 水平分片，每个旗舰版团队空间对应独立表 picture_{spaceId} |
| 3B-02 | 为什么选择 ShardingSphere 而不是 MyCat？ | ⭐⭐ | 技术选型 | ShardingSphere 是 Apache 顶级项目，生态活跃，文档完善，与 Spring Boot 集成简单；MyCat 社区活跃度下降 |
| 3B-03 | 动态分表是怎么实现的？应用启动时做了什么？ | ⭐⭐ | 动态分表 | DynamicShardingManager 实现 ApplicationListener<ApplicationReadyEvent> 接口，应用启动后扫描所有团队空间，生成表名列表，更新 ShardingSphere 的 actual-data-nodes 配置 |
| 3B-04 | 分片算法是根据什么字段设计的？为什么选择这个字段？ | ⭐⭐ | 分片算法 | PictureShardingAlgorithm 根据 spaceId 进行分片；spaceId 是空间唯一标识，分片后同一空间的数据在同一表，查询效率高 |
| 3B-05 | 分表后如何保证查询性能？索引是怎么设计的？ | ⭐⭐ | 索引设计 | 分表后每张表数据量减少，查询性能自然提升；spaceId 作为分片键自动索引，其他查询字段（userId/createTime）根据查询频率添加索引 |

### 3C：分表管理与数据一致性

| # | 题目 | 难度 | 考察要点 | 参考答案要点 |
|---|------|------|---------|------------|
| 3C-01 | 创建新空间时，分表是怎么创建的？如果创建失败会怎么处理？ | ⭐ | 分表创建 | 创建新空间时自动创建对应分表；如果创建失败，回滚空间创建操作，确保数据一致性 |
| 3C-02 | 空间删除时需要操作哪些存储？为什么不能只删 MySQL？ | ⭐⭐ | 跨存储协调 | MySQL（业务数据）/ COS（图片文件）/ Redis（缓存）/ FileIntegrityDB（哈希记录）；确保无悬空引用，使文件可重新上传 |
| 3C-03 | 分表的数据迁移是怎么做的？如何保证数据一致性？ | ⭐⭐ | 数据迁移 | 使用 ShardingSphere 提供的迁移工具或自定义脚本；迁移时锁定源表，逐条迁移，完成后验证数据一致性，删除源表 |
| 3C-04 | 如果分表规则变更（如改为按用户 ID 分表），如何平滑迁移？ | ⭐⭐⭐ | 规则变更 | 创建新分表，双写新旧表，逐步迁移数据，验证完成后切换读流量，删除旧表；需要停机或灰度发布 |
| 3C-05 | 分表后的事务怎么处理？跨表事务有什么限制？ | ⭐⭐⭐ | 事务处理 | 单表事务正常；跨表事务需要使用分布式事务（如 Seata）或应用层补偿；ShardingSphere 支持柔性事务 |

---

## 第 4 章：权限管理系统

| # | 题目 | 难度 | 考察要点 | 参考答案要点 |
|---|------|------|---------|------------|
| 4-01 | 三层权限体系是什么？每一层的职责是什么？ | ⭐ | 权限体系 | 系统级权限（user_role：user/admin）控制系统功能访问；空间级权限（space_type + 用户关系）控制空间访问；操作级权限（space_user_role：viewer/editor/admin）控制空间内操作 |
| 4-02 | Sa-Token 和 Spring Security 有什么区别？为什么选择 Sa-Token？ | ⭐ | 技术选型 | Sa-Token 轻量级、配置简单、学习成本低，支持多种认证方式；Spring Security 功能强大但配置复杂，学习曲线陡峭 |
| 4-03 | @SaSpaceCheckPermission 注解是怎么工作的？底层实现原理是什么？ | ⭐⭐ | 注解原理 | 注解定义在方法上，AOP 拦截方法调用，从 Sa-Token 获取用户权限，校验是否有权限，无权限抛出 NotPermissionException |
| 4-04 | 权限配置为什么要存储在 JSON 文件中？有什么优缺点？ | ⭐⭐ | 配置设计 | JSON 配置便于权限规则的快速修改和版本控制，无需重新编译代码；缺点是修改需要重启应用才能生效，且缺少配置校验 |
| 4-05 | 权限缓存是怎么设计的？缓存失效策略是什么？ | ⭐⭐ | 缓存设计 | Redis 缓存用户权限，减少数据库查询；写操作（用户角色变更/空间成员变更）时主动失效相关缓存 |
| 4-06 | 如果权限配置文件损坏，系统会怎么表现？有容错机制吗？ | ⭐⭐ | 容错机制 | 系统启动时加载权限配置，如果损坏启动失败；可以添加配置校验和默认值，保证系统可用性 |
| 4-07 | 如何实现跨空间的权限管理？比如一个用户在多个空间有不同角色？ | ⭐⭐ | 跨空间权限 | space_user 表记录用户在不同空间的角色；权限校验时根据当前空间查询对应角色；支持用户在不同空间有不同权限 |

---

## 第 5 章：实时协作系统

### 5A：WebSocket 通信

| # | 题目 | 难度 | 考察要点 | 参考答案要点 |
|---|------|------|---------|------------|
| 5A-01 | 为什么要使用 WebSocket 而不是 HTTP 轮询？有什么优势？ | ⭐ | 通信选型 | WebSocket 支持双向实时通信，延迟低，服务器主动推送；HTTP 轮询延迟高，服务器被动响应，资源浪费 |
| 5A-02 | WebSocket 连接断开后，会话是怎么清理的？有超时机制吗？ | ⭐⭐ | 会话管理 | afterConnectionClosed 方法自动清理会话；有心跳机制检测连接状态，超时未收到心跳自动断开连接 |
| 5A-03 | 实时协作的消息格式是怎么设计的？为什么这样设计？ | ⭐⭐ | 消息格式 | JSON 格式，包含 type（消息类型）、data（消息内容）、userId（发送者）、timestamp（时间戳）；结构化便于解析和扩展 |
| 5A-04 | 如果 WebSocket 服务挂了，用户能感知到吗？有重连机制吗？ | ⭐⭐ | 容错机制 | 用户能感知到连接断开；前端实现自动重连机制，指数退避策略，避免频繁重连 |
| 5A-05 | 如何实现实时协作的历史记录回放？现有架构支持吗？ | ⭐⭐⭐ | 历史回放 | 需要存储编辑历史记录；当前架构不支持，可以扩展为存储消息到数据库，支持回放 |

### 5B：编辑锁与并发控制

| # | 题目 | 难度 | 考察要点 | 参考答案要点 |
|---|------|------|---------|------------|
| 5B-01 | 编辑锁是怎么实现的？如果用户编辑时断开连接怎么办？ | ⭐ | 编辑锁实现 | pictureEditingUsers Map 记录当前编辑用户，key 为 pictureId，value 为 userId；用户断开连接时 afterConnectionClosed 自动释放编辑锁 |
| 5B-02 | 如果多个用户同时请求编辑同一个图片，怎么处理？ | ⭐⭐ | 并发控制 | 检查 pictureEditingUsers.containsKey(pictureId)，如果有其他用户正在编辑，返回错误提示；使用 ConcurrentHashMap 保证线程安全 |
| 5B-03 | 为什么要使用 Disruptor 而不是普通的线程池？性能差异有多大？ | ⭐⭐ | 性能优化 | Disruptor 是高性能无锁队列，基于环形缓冲区和 CAS 操作，延迟极低（微秒级）；传统线程池有锁竞争，性能较差 |
| 5B-04 | Disruptor 的配置参数（如 ring buffer 大小）是怎么设置的？调优依据是什么？ | ⭐⭐ | 参数调优 | ring buffer 大小设为 2 的幂次方（如 1024），根据并发量和消息量调整；太大浪费内存，太小导致消息丢失 |
| 5B-05 | WebSocket 消息广播是如何实现的？如何避免重复发送？ | ⭐⭐ | 消息广播 | broadcastToPicture 方法遍历该图片的所有会话，发送消息；支持 excludeSession 参数，排除指定的会话（如发送者自己） |

---

## 第 6 章：第三方 API 集成

### 6A：阿里云 AI 扩图

| # | 题目 | 难度 | 考察要点 | 参考答案要点 |
|---|------|------|---------|------------|
| 6A-01 | 阿里云 AI 扩图为什么要使用异步任务？同步调用有什么问题？ | ⭐ | 异步任务 | AI 扩图是计算密集型任务，处理时间较长（几秒到几分钟）；同步调用会导致请求超时，用户体验差 |
| 6A-02 | 异步任务的状态是怎么管理的？任务失败会怎么处理？ | ⭐⭐ | 任务管理 | 任务状态存储在数据库（pending/processing/completed/failed）；失败时记录错误日志，支持重试机制，通知用户失败原因 |
| 6A-03 | 如果阿里云 AI 扩图服务挂了，系统会怎么表现？有降级策略吗？ | ⭐⭐ | 降级策略 | 返回友好错误信息，提示用户稍后重试；支持任务队列和重试机制，避免临时故障影响；监控服务可用性 |
| 6A-04 | 异步任务的回调是怎么实现的？如何保证回调的可靠性？ | ⭐⭐⭐ | 回调机制 | 阿里云 AI 支持回调通知；使用 Webhook 接收回调，验证签名保证安全性；失败时轮询查询任务状态 |
| 6A-05 | 第三方 API 的密钥是怎么管理的？有安全措施吗？ | ⭐⭐ | 密钥管理 | 密钥存储在配置文件或环境变量，不硬编码在代码中；生产环境使用配置中心或密钥管理服务（如 AWS KMS） |

### 6B：360 搜图集成

| # | 题目 | 难度 | 考察要点 | 参考答案要点 |
|---|------|------|---------|------------|
| 6B-01 | 360 搜图的门面模式有什么好处？如果 360 搜图接口变更，影响有多大？ | ⭐ | 门面模式 | 封装复杂的搜索流程（获取搜图URL、解析搜索结果），对外提供简单接口；接口变更只需修改门面内部实现，不影响调用方 |
| 6B-02 | 360 搜图的结果是怎么存储的？需要缓存吗？ | ⭐⭐ | 结果存储 | 搜图结果临时存储在 Redis，设置过期时间（如1小时）；避免频繁调用第三方 API，提升响应速度 |
| 6B-03 | 第三方 API 的调用频率有限制吗？如何避免触发限流？ | ⭐⭐ | 限流处理 | 有调用频率限制（如每秒 10 次）；使用令牌桶算法控制调用频率，超限返回错误或排队等待 |
| 6B-04 | 如果要替换第三方 API（如换成百度 AI），改动量有多大？ | ⭐⭐ | 可替换性 | 门面模式封装了接口，替换只需修改门面内部实现；上层业务代码无需修改，改动量小 |
| 6B-05 | 如何处理第三方 API 的异常和超时？有重试机制吗？ | ⭐⭐ | 异常处理 | try-catch 捕获异常，记录错误日志，返回友好错误信息；设置超时时间（如30秒），超时后重试或返回失败 |

---

## 第 7 章：缓存策略

| # | 题目 | 难度 | 考察要点 | 参考答案要点 |
|---|------|------|---------|------------|
| 7-01 | 为什么要设计多级缓存？单级缓存有什么问题？ | ⭐ | 缓存架构 | 单级缓存（如只有 Redis）在高并发场景下会成为性能瓶颈，且网络开销大；多级缓存先查本地缓存，命中率高且速度快，减少 Redis 压力 |
| 7-02 | 缓存 Key 为什么要用 MD5？有什么优缺点？ | ⭐ | Key 设计 | MD5 将查询条件转换为固定长度的哈希值，便于存储和比较；缺点是 MD5 存在哈希冲突（概率极低），无法从 Key 反推查询条件 |
| 7-03 | 缓存失效策略是怎么设计的？如何保证缓存一致性？ | ⭐⭐ | 失效策略 | 采用主动失效策略，写操作（增删改）时主动删除相关缓存；缓存 Key 包含查询条件，可以精确定位需要失效的缓存 |
| 7-04 | Caffeine 和 Redis 的缓存时间是怎么设置的？为什么设置不同的过期时间？ | ⭐⭐ | 过期时间 | Caffeine 本地缓存 5 分钟，容量 10000；Redis 缓存 5 分钟，支持集群部署；本地缓存容量有限，Redis 提供更大存储空间 |
| 7-05 | 如果 Redis 挂了，系统会怎么表现？有降级策略吗？ | ⭐⭐ | 降级策略 | 本地缓存仍可服务，但命中率下降；可以降级为只查本地缓存或直接查数据库，保证系统可用性 |
| 7-06 | 缓存穿透、缓存击穿、缓存雪崩分别是什么？你们有防护措施吗？ | ⭐⭐⭐ | 缓存问题 | 缓存穿透：查询不存在的数据，缓存不命中，直接查数据库；防护：缓存空值或布隆过滤器。缓存击穿：热点数据过期，大量请求直接查数据库；防护：加锁或热点数据永不过期。缓存雪崩：大量缓存同时过期；防护：设置随机过期时间 |
| 7-07 | 缓存的命中率是怎么计算的？如何提升缓存命中率？ | ⭐⭐ | 命中率 | 命中率 = 命中次数 / 总查询次数；提升命中率：优化缓存 Key 设计，增加缓存时间，预热热点数据 |
| 7-08 | 如果要实现缓存预热，怎么做？现有架构支持吗？ | ⭐⭐⭐ | 缓存预热 | 应用启动时加载热点数据到缓存；当前架构不支持，可以扩展为定时任务或手动触发预热 |

---

## 第 8 章：工程化实践

| # | 题目 | 难度 | 考察要点 | 参考答案要点 |
|---|------|------|---------|------------|
| 8-01 | 测试分几层？Unit / Integration / E2E 各测什么、分别不测什么？ | ⭐ | 测试分层 | Unit（单元测试/纯逻辑）/ Integration（集成测试/组件协作）/ E2E（端到端测试/真实链路） |
| 8-02 | 单元测试怎么 mock COS 调用？patch 的是哪一层？不 mock 的话有什么问题？ | ⭐⭐ | Mock 策略 | 使用 Mockito mock CosManager；patch 的是 Service 层；不 mock 的话会真实调用 COS，消耗配额，测试速度慢，依赖外部服务 |
| 8-03 | CI/CD 流水线包含哪些步骤？如何保证代码质量？ | ⭐⭐ | CI/CD | 代码拉取 → 依赖安装 → 代码检查 → 单元测试 → 集成测试 → 构建镜像 → 部署；通过代码检查（SonarQube）和测试覆盖率保证代码质量 |
| 8-04 | 为什么要使用 Docker 和 Kubernetes？有什么好处？ | ⭐ | 容器化 | Docker 实现应用容器化，保证开发、测试、生产环境一致性；Kubernetes 提供容器编排能力，支持自动扩缩容、负载均衡、故障自愈 |
| 8-05 | 监控和告警是怎么实现的？监控哪些指标？ | ⭐⭐ | 监控告警 | Prometheus + Grafana 实现监控；收集应用指标（QPS、响应时间、错误率）和系统指标（CPU、内存、磁盘）；设置告警规则（如错误率超过1%告警） |
| 8-06 | 日志是怎么管理的？日志级别是怎么设置的？ | ⭐⭐ | 日志管理 | SLF4J + Logback，分级记录（DEBUG/INFO/WARN/ERROR）；生产环境使用 INFO 或 WARN 级别，避免日志量过大 |
| 8-07 | 如果要实现灰度发布，现有架构支持吗？ | ⭐⭐⭐ | 灰度发布 | Kubernetes 支持 Deployment 的滚动更新和金丝雀发布；可以配置流量分配，逐步切换到新版本 |
| 8-08 | 代码检查（如 SonarQube）是怎么集成的？有哪些规则？ | ⭐⭐ | 代码检查 | CI/CD 流水线集成 SonarQube；规则包括代码重复率、代码复杂度、潜在 Bug、安全漏洞等 |
| 8-09 | 性能测试是怎么做的？测试环境是怎么搭建的？ | ⭐⭐ | 性能测试 | 使用 JMeter 或 Gatling 进行压力测试；测试环境模拟生产配置，测试并发量、响应时间、吞吐量 |
| 8-10 | 如果要支持自动化部署，现有架构需要改什么？ | ⭐⭐ | 自动化部署 | 当前已支持 CI/CD 自动部署；可以扩展为支持多环境部署、回滚机制、蓝绿部署 |

---

## 第 9 章：异常处理与日志管理

| # | 题目 | 难度 | 考察要点 | 参考答案要点 |
|---|------|------|---------|------------|
| 9-01 | 为什么要使用全局异常处理？有什么好处？ | ⭐ | 全局异常 | 集中管理所有异常，避免在每个 Controller 方法中重复编写 try-catch 代码；统一异常处理可以保证响应格式的一致性 |
| 9-02 | 有哪些异常类型？各自的适用场景是什么？ | ⭐ | 异常类型 | BusinessException（业务异常，如参数错误、权限不足）、NotLoginException（未登录异常）、NotPermissionException（无权限异常）、RuntimeException（运行时异常） |
| 9-03 | 统一响应格式是什么？为什么要统一格式？ | ⭐ | 响应格式 | BaseResponse 包含 code、data、message；统一格式便于前端统一处理错误，提升用户体验 |
| 9-04 | 日志级别是怎么划分的？生产环境应该用什么级别？ | ⭐ | 日志级别 | DEBUG（调试信息）、INFO（一般信息）、WARN（警告信息）、ERROR（错误信息）；生产环境建议使用 INFO 或 WARN 级别 |
| 9-05 | 如何避免敏感信息泄露到日志中？有什么措施？ | ⭐⭐ | 敏感信息 | 对敏感字段（如密码、身份证号）进行脱敏处理，只记录部分信息（如 password= ***）；使用日志过滤器自动识别和脱敏 |
| 9-06 | 异常日志是怎么记录的？有日志分析工具吗？ | ⭐⭐ | 日志分析 | 全局异常处理器记录异常日志；使用 ELK（Elasticsearch + Logstash + Kibana）收集和分析日志，便于问题排查 |
| 9-07 | 如果要实现异常告警（如异常超过阈值自动通知），怎么做？ | ⭐⭐ | 异常告警 | 监控异常日志数量，超过阈值触发告警；通过邮件、短信、钉钉等方式通知运维人员 |
| 9-08 | 全局异常处理和业务异常有什么区别？什么时候用哪个？ | ⭐⭐ | 异常区别 | 全局异常处理是框架层面的统一处理，业务异常是业务逻辑抛出的异常；业务异常使用 BusinessException，系统异常使用 RuntimeException |
| 9-09 | 如果要实现异常追踪（如链路追踪），现有架构支持吗？ | ⭐⭐⭐ | 链路追踪 | 可以集成 SkyWalking 或 Zipkin 实现分布式链路追踪；当前架构不支持，需要添加追踪依赖和配置 |
| 9-10 | 日志的存储和归档是怎么做的？有日志清理策略吗？ | ⭐⭐ | 日志归档 | 日志存储在文件系统，按日期滚动；定期归档到对象存储（如 COS），设置保留时间（如30天），自动清理过期日志 |

---

## 第 10 章：系统设计与扩展性

| # | 题目 | 难度 | 考察要点 | 参考答案要点 |
|---|------|------|---------|------------|
| 10-01 | 从系统设计角度，云图库和传统文件系统的核心权衡是什么？什么场景应该选云图库？ | ⭐ | 系统设计 | 云图库提供图片处理、智能检索、权限管理、实时协作等增值服务；传统文件系统简单轻量；需要增值服务时选云图库 |
| 10-02 | 这个系统的性能瓶颈在哪里？如果要优化 P99 延迟，你会从哪里下手？ | ⭐⭐ | 性能优化 | 性能瓶颈在 COS 上传、数据库查询、缓存命中率；优化 P99 延迟：优化数据库索引、增加缓存、使用 CDN 加速图片加载 |
| 10-03 | 如果要支持实时图片处理（如上传后立即生成缩略图），现有架构需要改什么？ | ⭐⭐ | 实时处理 | 当前 COS 图片处理是异步的，可以改为同步处理或使用消息队列异步处理并通知前端；需要修改上传流程和前端轮询机制 |
| 10-04 | MySQL 和 PostgreSQL 作为关系型数据库有什么区别？你会在什么规模下考虑换掉 MySQL？ | ⭐⭐ | 数据库选型 | MySQL 开源免费，社区活跃；PostgreSQL 功能更强大，支持更复杂的数据类型；规模到百万级数据或需要复杂查询时考虑换 PostgreSQL |
| 10-05 | 如果用户的图片非常大（如超过 1GB），Embedding 模型会怎么处理？有没有截断风险？ | ⭐⭐ | 大文件处理 | CloudImage 不涉及 Embedding；大文件上传需要分片上传，使用 COS 分片上传接口，避免内存溢出 |
| 10-06 | 这套系统目前不支持什么功能？如果要支持「图片版本管理」，需要改哪些地方？ | ⭐⭐ | 功能扩展 | 不支持图片版本管理；需要增加版本表（picture_version），记录每次修改，支持版本回滚；修改上传和删除逻辑 |
| 10-07 | 如果要把腾讯云 COS 换成阿里云 OSS，改动量有多大？可插拔架构是否覆盖了这个场景？ | ⭐⭐ | 可替换性 | CosManager 封装了 COS 操作，替换只需修改 CosManager 实现；可插拔架构覆盖了这个场景，改动量小 |
| 10-08 | 如果要支持图片 CDN 加速，现有架构需要改什么？ | ⭐⭐ | CDN 加速 | COS 支持配置 CDN 加速域名；需要修改图片 URL 生成逻辑，使用 CDN 域名；前端无需修改 |
| 10-09 | 如果要实现图片水印功能，应该在哪里实现？有什么方案？ | ⭐⭐ | 水印功能 | 在 COS 图片处理接口实现水印；或在上传后使用图片处理库（如 ImageIO）添加水印；COS 方案更简单，无需额外资源 |
| 10-10 | 如果要支持图片智能分类（如自动识别图片内容），现有架构需要改什么？ | ⭐⭐ | 智能分类 | 集成 AI 图像识别服务（如阿里云图像识别）；上传后调用识别接口，获取分类标签，存储到数据库；修改上传流程和检索逻辑 |

---

## 题库统计

| 章节 | 题数 | ⭐基础 | ⭐⭐进阶 | ⭐⭐⭐深挖 |
|------|------|--------|----------|----------|
| 第1章：项目全景 | 8 | 2 | 4 | 2 |
| 第2章：图片上传流水线 | 15 | 3 | 8 | 4 |
| 第3章：空间管理与分库分表 | 15 | 3 | 8 | 4 |
| 第4章：权限管理系统 | 7 | 2 | 4 | 1 |
| 第5章：实时协作系统 | 10 | 2 | 5 | 3 |
| 第6章：第三方API集成 | 10 | 2 | 5 | 3 |
| 第7章：缓存策略 | 8 | 2 | 4 | 2 |
| 第8章：工程化实践 | 10 | 2 | 5 | 3 |
| 第9章：异常处理与日志 | 10 | 2 | 5 | 3 |
| 第10章：系统设计与扩展性 | 10 | 2 | 5 | 3 |
| **合计** | **103** | **22** | **53** | **28** |