Google Drive — 云存储

V1「做个简单的文件收藏夹」

场景

你经常在浏览器上处理一些小文件——截图、文本备忘、小的 PDF。每次关掉浏览器这些临时文件就找不到了。你想做一个浏览器里的文件收藏夹，能把小文件拖进去保存，下次打开浏览器还在。不想装任何软件，也不想搭服务器，就一个 HTML 文件搞定。

你要解决什么

用 localStorage 实现纯前端的文件存取功能，支持拖拽上传和下载。

给 AI 的 Prompt

用纯前端实现一个浏览器文件收藏夹，要求：

1. 拖拽区域：页面中央有虚线框，支持 drag & drop 文件
2. 也支持点击选择文件上传
3. 使用 FileReader API 将文件转为 base64 存入 localStorage
4. 单个文件限制 2MB，总存储限制 4MB（接近 localStorage 上限）
5. 超限时给出明确的错误提示
6. 文件列表显示：文件名、大小、类型图标、上传时间
7. 支持操作：下载文件（base64 还原为 Blob 下载）、删除文件、重命名
8. 显示已用存储空间和剩余空间（进度条）
9. 按文件类型分组显示（图片、文档、其他）
10. 图片文件支持缩略图预览
11. 单个 HTML 文件，不需要后端

输出一个可以直接打开的 HTML 文件。

验证清单

拖拽文件到区域后文件被保存
刷新页面后文件仍然存在
超过 2MB 的文件被拒绝并提示
存储空间满时给出警告
下载的文件和原文件内容一致
删除、重命名功能正常
图片缩略图正确显示
存储空间进度条准确

你学到了什么

FileReader API 和 Blob 操作 → M1
localStorage 的容量限制和序列化策略 → M2
Base64 编码对文件大小的影响（膨胀约 33%） → M9
拖拽上传的浏览器 API → M1
客户端存储的适用场景和天花板 → M2

V2「团队要共享文件，localStorage 放不下大文件」

场景

你做的文件收藏夹被几个同事看到了，觉得挺方便的，但他们有新需求：想在团队之间共享文件，而且文件大小经常超过 10MB（设计稿、PPT）。localStorage 的 5MB 限制完全不够用，而且不同电脑之间数据不互通。团队需要一个能上传大文件、支持文件夹整理、能生成分享链接的文件管理系统。

你要解决什么

搭建后端文件管理服务，支持大文件上传、文件夹结构和链接分享。

给 AI 的 Prompt

用 Go + Gin + SQLite 实现一个团队文件管理系统，要求：

1. 数据模型：
   - File（id, name, path, size, mime_type, folder_id, share_token, created_at, updated_at）
   - Folder（id, name, parent_id, created_at）
2. 文件 API：
   - POST /api/files/upload — 上传文件（指定目标文件夹，限制 100MB）
   - GET /api/files/:id/download — 下载文件
   - DELETE /api/files/:id — 删除文件
   - PUT /api/files/:id/rename — 重命名
   - POST /api/files/:id/share — 生成分享链接（返回 share_token）
   - GET /api/share/:token — 通过分享链接下载（无需登录）
3. 文件夹 API：
   - POST /api/folders — 创建文件夹
   - GET /api/folders/:id — 获取文件夹内容（子文件夹 + 文件列表）
   - GET /api/folders/root — 获取根目录内容
   - DELETE /api/folders/:id — 删除文件夹（级联删除内容）
   - PUT /api/folders/:id/rename — 重命名文件夹
4. 文件存储在 ./storage/files/ 目录，用 UUID 命名避免冲突
5. 分享链接有效期 7 天
6. 前端页面：
   - 文件管理器界面（左侧文件夹树 + 右侧文件列表）
   - 面包屑导航
   - 上传进度条
   - 右键菜单（下载、分享、重命名、删除）
7. 全局搜索文件名

输出完整项目结构和代码。

验证清单

文件上传和下载正常（文件内容一致）
文件夹创建、嵌套、删除正常
面包屑导航路径正确
分享链接生成后可以通过链接下载
分享链接过期后返回 404
100MB 以内文件上传成功
文件名搜索功能正常
级联删除文件夹时所有内容被清理

你学到了什么

文件系统抽象设计（数据库记录 + 物理文件） → M2
文件夹树形结构的数据模型（parent_id 自引用） → M2
分享链接的 Token 设计和过期机制 → M1
大文件传输的服务器配置 → M13
级联删除的实现策略 → M2

V3「两个人同时编辑了同一个文档，后面那个人覆盖了前面的修改」

场景

团队文件系统用起来后，大家开始把协作文档也放上来。问题随之而来：小明上午下载了一份方案文档修改了半天，下午上传覆盖。但小红在中午也下载了同一份文档做了不同修改并上传了。小明下午的上传直接覆盖了小红的修改，小红的工作全丢了。团队已经因为这个问题吵了三次。

你要解决什么

引入版本控制和冲突检测机制，让并发编辑不会丢失数据。

给 AI 的 Prompt

用 Go + Gin + PostgreSQL 实现一个带版本控制的文件管理系统，要求：

1. 数据模型：
   - File（id, name, folder_id, current_version, created_at, updated_at）
   - FileVersion（id, file_id, version_number, size, hash, uploader, change_note, created_at）
   - 物理文件按版本存储：/storage/{file_id}/{version_number}/{filename}
2. 乐观锁冲突检测：
   - 下载文件时返回响应头 X-File-Version: 当前版本号
   - 上传新版本时必须携带 X-Base-Version: 基于的版本号
   - 如果 base_version != current_version，返回 409 Conflict
   - 409 响应中包含冲突信息：谁在什么时候上传了新版本
3. 版本管理 API：
   - POST /api/files/:id/upload — 上传新版本（携带 base_version 和 change_note）
   - GET /api/files/:id/versions — 获取版本历史列表
   - GET /api/files/:id/versions/:version/download — 下载指定版本
   - POST /api/files/:id/revert/:version — 回滚到指定版本（创建新版本）
4. 冲突解决流程：
   - 发生冲突时前端弹窗显示：冲突版本信息、「下载对方版本」和「强制覆盖」两个选项
   - 强制覆盖需要确认（二次弹窗）
5. 文件差异对比：
   - GET /api/files/:id/diff?v1=2&v2=3 — 对比两个版本
   - 文本文件返回逐行 diff（unified format）
   - 非文本文件只返回元数据对比（大小、hash、修改时间）
6. 存储优化：保留最近 20 个版本，超出后自动清理最旧版本的物理文件
7. 前端页面：
   - 文件详情页显示版本时间线
   - 文本文件的 diff 可视化（左右对比视图）
   - 冲突解决弹窗

输出完整项目结构、数据库迁移文件和代码。

验证清单

正常上传新版本成功，版本号递增
基于旧版本上传触发 409 冲突
冲突响应包含正确的冲突信息
版本历史列表按时间倒序排列
下载历史版本内容正确
回滚操作创建新版本而非删除
文本文件 diff 结果正确
超过 20 个版本时旧版本文件被清理
强制覆盖功能正常

你学到了什么

乐观锁与并发控制策略（version column） → M2
HTTP 409 Conflict 状态码的正确使用 → M1
文件版本存储设计（版本号 vs 内容寻址） → M2
Diff 算法和 Unified Diff 格式 → M9
冲突解决的用户体验设计 → M1
存储空间管理和自动清理策略 → M17
从「覆盖写」到「版本化写入」的架构演进 → M8

V4「大文件(>1GB)上传经常断，要重传」

场景

用户量达到 1000 人，越来越多人上传大文件——设计源文件、视频素材、数据备份，动辄超过 1GB。网络稍有波动上传就失败，必须从头再来。一个 2GB 的文件上传了 80% 然后断了，用户崩溃了。另外上传过程中没有任何进度反馈，用户不知道还要等多久。团队需要一套可靠的大文件上传方案。

你要解决什么

实现分片断点续传（Chunked/Resumable Upload），支持上传进度追踪，并行分片上传，MD5 校验确保文件完整性。

给 AI 的 Prompt

在现有文件管理系统基础上，实现大文件分片断点续传，要求：

1. 分片上传协议：
   - POST /api/upload/init — 初始化上传（传入文件名、大小、MD5，返回 upload_id）
   - POST /api/upload/chunk — 上传单个分片（upload_id + chunk_index + chunk_data）
   - POST /api/upload/complete — 完成上传（校验所有分片，合并文件，验证 MD5）
   - GET /api/upload/status/:upload_id — 查询已上传分片列表（用于断点续传）
   - DELETE /api/upload/:upload_id — 取消上传（清理临时分片）
2. 分片策略：
   - 默认分片大小 5MB，支持客户端自定义（1MB-20MB）
   - 分片临时存储在 ./tmp/uploads/{upload_id}/ 目录
   - 每个分片上传后立即校验 MD5（分片级校验）
   - 合并完成后校验整体文件 MD5（文件级校验）
3. 并行分片上传：
   - 前端同时上传 3 个分片（并发控制）
   - 失败的分片自动重试 3 次
   - 所有分片完成后自动调用 complete 接口
4. 断点续传：
   - 页面刷新或网络恢复后，调用 status 接口获取已上传分片
   - 只上传缺失的分片
   - 未完成的上传保留 24 小时，过期自动清理
5. 上传进度追踪：
   - 前端实时显示：总进度百分比、已上传大小/总大小、上传速度、预计剩余时间
   - 每个分片的上传状态（待上传/上传中/已完成/失败）
   - 支持暂停和继续上传
6. 临时文件清理：
   - 定时任务每小时扫描，清理超过 24 小时的未完成上传
   - 合并成功后立即删除临时分片

输出分片上传 API、前端上传组件和清理任务代码。

验证清单

1GB 以上文件分片上传成功
上传中断后刷新页面，断点续传只上传缺失分片
并行上传 3 个分片，速度明显提升
分片级和文件级 MD5 校验通过
上传进度实时显示（百分比、速度、剩余时间）
暂停和继续上传功能正常
分片上传失败自动重试
24 小时过期的临时分片被自动清理
取消上传后临时文件被清理

你学到了什么

分片上传协议设计（init/chunk/complete 三步流程） → M1
断点续传的实现原理（服务端记录已上传分片） → M1
并行上传和并发控制策略 → M13
MD5 校验保证数据完整性（分片级 + 文件级） → M9
临时文件管理和定时清理 → M17
前端上传进度计算（速度、剩余时间） → M1
从单次上传到分片续传的可靠性提升 → M8

V5「存储空间告急，很多重复文件」

场景

用户量增长到 1 万人，存储空间使用了 10TB。分析发现 30% 以上是重复文件——同一个 PPT 模板被上传了几百次，同一份合同文档在不同文件夹里存了十几份。另外所有文件都存在 SSD 上，但 80% 的文件超过 3 个月没被访问过。每个用户存储空间没有限制，有人把整个电脑的文件都传上来了。存储成本每月增长 20%，再不优化要爆预算了。

你要解决什么

实现基于 SHA256 的文件去重（内容寻址存储），存储分层（热/温/冷），用户配额管理，以及孤立文件的后台清理。

给 AI 的 Prompt

在现有文件管理系统基础上，实现存储优化方案，要求：

1. 文件去重（Content-Addressable Storage）：
   - 上传文件时计算 SHA256 哈希值
   - 数据模型拆分：FileRecord（用户看到的文件记录）和 FileBlob（实际物理文件）
   - FileBlob 以 SHA256 命名存储：/storage/blobs/{sha256前2位}/{sha256}
   - 多个 FileRecord 可指向同一个 FileBlob（引用计数）
   - 上传时先查 SHA256，已存在则秒传（只创建 FileRecord，不存物理文件）
   - 删除 FileRecord 时检查引用计数，归零才删除物理文件
2. 存储分层（Hot/Warm/Cold）：
   - Hot（SSD）：最近 30 天访问过的文件
   - Warm（HDD）：30-180 天未访问的文件
   - Cold（对象存储/归档目录）：180 天以上未访问的文件
   - 记录每次文件访问时间（last_accessed_at）
   - 定时任务每天凌晨扫描，自动迁移文件到对应存储层
   - 访问 Cold 文件时自动恢复到 Hot 层（恢复延迟 < 10 秒）
   - 存储层标记在 API 响应中返回
3. 用户配额管理：
   - 每个用户默认配额 10GB，管理员可调整
   - 上传前检查配额，超出拒绝上传并提示剩余空间
   - GET /api/users/:id/storage — 返回已用空间、配额、各类型文件占比
   - 管理后台配额使用排行榜
   - 去重后的文件只计算一次存储（按用户实际占用而非物理大小）
4. 孤立文件清理：
   - 后台任务扫描无 FileRecord 引用的 FileBlob
   - 孤立文件保留 7 天（防止误删），7 天后物理删除
   - 清理日志记录：清理时间、文件数量、释放空间
   - GET /api/admin/storage/report — 存储报告（总量、去重节省、各层占比）

输出数据模型变更、去重逻辑、存储迁移脚本和配额管理代码。

验证清单

你学到了什么

内容寻址存储（CAS）和文件去重原理 → M2
SHA256 哈希和引用计数管理 → M9
存储分层策略（Hot/Warm/Cold） → M17
用户配额系统设计 → M2
后台清理任务和安全删除策略（保留期） → M17
秒传的实现原理（哈希匹配跳过上传） → M1
从全量存储到去重存储的成本优化 → M8

V6「全球办公室要实时协作编辑文档」

场景

公司在全球有多个办公室，超过 10 万用户在线使用文件系统。最大的需求是实时协作编辑——多人同时编辑同一个文档，能看到对方的光标位置和编辑内容，像 Google Docs 一样。目前的版本控制只能「下载-修改-上传」，远远满足不了实时协作场景。另外全球用户访问统一的存储节点延迟很高，需要多区域存储和就近访问。

你要解决什么

实现基于 OT 或 CRDT 的实时协作编辑，通过 WebSocket 同步光标和编辑操作，设计无冲突合并机制，部署多区域存储副本。

给 AI 的 Prompt

在现有文件管理系统基础上，构建实时协作编辑和全球化存储架构，要求：

1. 实时协作编辑（OT/CRDT）：
   - 选择并实现一种协作算法：OT（Operational Transform）或 CRDT（如 Yjs/Automerge）
   - 文本文档支持多人同时编辑，操作实时同步
   - 操作类型：insert(position, text)、delete(position, length)、format(range, style)
   - 服务端维护文档的权威版本，客户端操作先本地应用再发送服务端
   - 冲突自动解决：相同位置的并发编辑通过算法自动合并
   - 离线编辑支持：断网时本地缓存操作，重新连接后自动同步
2. WebSocket 实时同步：
   - 客户端连接：/ws/doc/:doc_id
   - 协议消息类型：
     - join/leave — 加入/离开编辑会话
     - operation — 编辑操作
     - cursor — 光标位置更新
     - awareness — 用户在线状态
   - 服务端广播操作给同一文档的所有客户端（排除发送者）
   - 心跳检测：30 秒无消息发送 ping，超时断开
3. 实时光标和协作感知：
   - 每个在线用户分配一个颜色
   - 显示其他用户的光标位置和选区
   - 显示在线用户列表和每个人正在编辑的位置
   - 用户名标签跟随光标移动
4. 无冲突合并：
   - 编辑历史记录（operation log），支持撤销/重做
   - 版本向量（version vector）追踪每个客户端的操作序号
   - 定期创建文档快照（每 100 次操作或每 5 分钟）
   - 快照用于新用户加入时快速加载，无需回放全部操作
5. 多区域存储副本：
   - 主要区域（亚洲、欧洲、北美）各部署存储节点
   - 写入操作路由到主节点，异步复制到其他区域
   - 读取操作路由到最近的区域节点
   - 复制延迟监控（目标 < 500ms）
   - 区域节点故障时自动 failover 到其他区域
6. 协作管理：
   - 文档权限：所有者、编辑者、查看者
   - 最大同时编辑人数限制（默认 50 人）
   - 编辑会话记录和回放（像录像一样回放编辑过程）

输出协作算法核心代码、WebSocket 服务、前端编辑器组件和多区域部署方案。

验证清单

你学到了什么

OT/CRDT 实时协作算法原理 → M2
WebSocket 长连接管理和消息协议设计 → M13
实时光标同步和协作感知（Awareness） → M1
版本向量和操作日志（Operation Log） → M2
文档快照和增量同步策略 → M2
多区域存储副本和异步复制 → M3
读写分离：写主读从的路由策略 → M3
从版本控制到实时协作的架构飞跃 → M8