当6万星开源项目归档后，我们造了个更小的S3

一个被拉取超10亿次的开源项目，从社区宠儿到数字墓碑需要多久？MinIO的答案是9个月。而当它最终归档时，Centro Labs的工程师们已经写好了自己的替代方案。

MinIO之死：开源世界的又一次震荡

2025年5月，MinIO社区版移除了管理控制台。10月，二进制文件和Docker镜像停止分发。12月，项目进入"维护模式"。2026年2月，minio/minio仓库被设为只读——6万星标、超10亿次Docker拉取，就此冻结。

Centro Labs的团队曾是重度用户。"我们用它跑副业项目、内部工具、家庭实验室，"他们回忆，"它是'文件放哪'的默认答案，而且一直很好用。然后突然就不行了。"

这场崩塌并非无迹可寻。一篇题为《MinIO如何从开源宠儿沦为警示案例》的文章详细记录了完整时间线：从开源明星到商业策略剧变，社区版功能被系统性剥离，最终彻底闭源。

但对依赖它的开发者来说，归档通知邮件仍是当头一棒。

正方：我们需要一个更简单的S3

MinIO的复杂架构本是设计特性，却成了小型团队的负担。它是分布式存储——纠删码、多节点集群、企业级功能。Centro Labs的工程师们意识到：这些我们全都不需要。

真实需求被重新拆解：单服务器、S3兼容接口、能跑起来就行。没有Redis，没有Kafka，没有独立数据库服务器。一个二进制文件，一个SQLite文件，零外部依赖。

这就是ObjeX的起点。任何S3客户端（aws-cli、boto3、rclone）直接指向它就能工作。启动只需一条命令：

docker run -d -p 9001:9001 -p 9000:9000 -v objex-data:/data ghcr.io/centrolabs/objex:latest

打开http://localhost:9001，用admin/admin登录，就是一个带管理界面的可用对象存储。生产环境配置从仓库拿docker-compose.yml。

技术栈选择透露了设计哲学：.NET 10 + Blazor Server UI。单一进程同时服务S3 API（9000端口）和Web界面（9001端口）。没有独立前端部署，没有构建步骤。

功能范围被刻意收窄。ObjeX实现了大多数客户端实际使用的S3操作：桶的增删改查、对象的增删改查、分段上传、预签名URL、批量删除、服务端复制。而版本控制、生命周期策略、桶ACL等操作返回501 Not Implemented——它们在路线图上，但"不会在实现前就列为功能"。

这种诚实罕见。开源项目常把"计划中"包装成"已拥有"，ObjeX选择反向操作。

反方：重复造轮子值得吗？

质疑的声音同样直接：S3兼容层已经被解决太多次了。Ceph、SeaweedFS、Garage，甚至云厂商的MinIO替代方案都在竞争。为什么再写一个？

Centro Labs的回应聚焦于"恰好够用"与"过度设计"的鸿沟。现有方案要么保留分布式架构的复杂性，要么在功能完整性上妥协太多。ObjeX赌的是中间地带：对单服务器场景，S3协议子集+极简部署，比全功能替代方案更有生命力。

安全风险是另一质疑点。对象存储是基础设施底座，漏洞代价极高。ObjeX的应对体现在架构细节：每个对象键用SHA256哈希，存入两级目录树（65536个子目录）。逻辑键永不接触文件系统，路径遍历攻击被结构性杜绝。

上传原子性通过"临时文件+File.Move"实现。进程崩溃导致的中断写入，在下次启动时清理。没有复杂的分布式一致性协议，因为不需要。

最大的工程挑战是AWS Signature V4。规范请求、HMAC密钥派生链、时间戳新鲜度检查、负载哈希验证——团队从零实现，并用aws-cli交叉验证。这是S3兼容性的真正门槛，也是多数"轻量替代"项目偷工减料之处。

判断：基础设施的"去规模化"趋势

ObjeX的价值不在技术突破，而在精准卡位。它识别出一个被忽视的用户群