这是一篇关于 S3 协议的教育性探索以及如何使用 Git 作为底层存储机制实现它的实用指南。

• 仓库信息：可在External Link Globe ktunprasert/github-as-s3获取。
• 项目起源：作者因好奇实现类似 S3 协议的东西有多难而开始该项目，因个人 SaaS 数据量小，可将二进制数据存储在私有 GitHub 仓库中，PocketBase 可查看备份数据列表并恢复。
• 使用 Git 的原因：成本效益高，许多 Git 托管平台提供免费存储、版本控制和带宽；有丰富的历史和审计记录；无出口费用；主机独立，大多数 Git 托管平台都可使用；通常无需昂贵的 API 调用。
• 作为 S3 的原因：模拟 S3 API 可访问现有工具和应用的丰富生态系统，如 rclone 和 PocketBase。
• 缺点：S3 协议复杂，难以实现全兼容；Git 设计用于管理源代码，不适合大二进制文件，会使仓库膨胀，操作变慢；Git 模拟性能比原生 Git 命令行工具慢；性能依赖 Git 托管平台和网络条件，可能不如专用对象存储服务快；存在存储限制，大文件需使用 git-lfs 等。
• 概念概述：将 S3 概念映射到 Git 世界，S3 桶对应 Git 仓库，S3 对象对应仓库内的文件/路径，S3 对象版本控制对应 Git 提交。讨论了不使用其他 Git 结构的原因，如使用单个仓库的孤儿分支表示不同“桶”会带来细粒度访问控制问题，而“一个仓库对应一个桶”的模型更安全和易于管理。
• 实现细节：确定实现基本 S3 兼容协议所需的关键 S3 API 路由，如 PutObject、GetObject 等，不同的桶操作路由使用不同的库处理。
• 探索的方法：最初的简单直接方法在处理多个操作时显示出缺陷，如临时目录膨胀和并发问题；后来采用基于队列的协程工作者方法，通过单个本地克隆管理 Git 操作，解决了并发和临时目录问题。
• 注意事项：存在认证签名版本冲突、路径风格访问要求、测试有限（主要测试了 rclone、aws s3、pocketbase 等）、全克隆需优化等问题。
• 未来潜力：可利用 GitHub Actions 实现自动 TTL 清理、使用 Git 标签创建存储桶快照、与 CI/CD 集成、自带 Git 管理 UI 等。
• 结论：这是一次很好的学习经历，发现了 Go 的 time.Timer 在管理异步操作中的多功能性，用 Git 实现功能子集的 S3 兼容 API 很简单，展示了利用熟悉工具进行低成本文件存储的创新方法。
• 致谢：感谢 go-git、go-github 库以及 bkbinary 的视频提供的帮助和灵感。