最近想在服务器上自建一套对象存储，用来承载图床和备份。第一个想到的就是 MinIO——曾经的自建对象存储「明星项目」，S3 兼容、一条 Docker 命令就能跑。部署本身顺利得超出预期，但紧接着就踩进了一连串坑里，最后才发现一个令人意外的事实：开源版 MinIO 已经被官方废弃了。
这篇文章记录完整的踩坑过程，以及最后的替代方案。如果你也在选型对象存储，希望这篇文章能帮你少走弯路。
一、部署：这部分出奇地顺利
先交代部署过程，后面踩的坑都建立在这套部署之上。
1.1 Docker 部署（含数据持久化）
# 服务器执行
mkdir -p /opt/minio/data
cat > /opt/minio/docker-compose.yml <<'EOF'
services:
minio:
image: minio/minio:latest
container_name: minio
restart: unless-stopped
ports:
- "127.0.0.1:9000:9000" # S3 API
- "127.0.0.1:9001:9001" # Web 控制台
environment:
MINIO_ROOT_USER: admin
MINIO_ROOT_PASSWORD: 请替换为强密码
volumes:
- /opt/minio/data:/data
command: server /data --console-address ":9001"
EOF
cd /opt/minio
docker compose up -d到这里一切正常，容器起来了，9000（S3 API）和 9001（控制台）都通了。数据通过 volumes 挂载持久化到 /opt/minio/data。当时心想：这玩意儿果然简单。
1.2 Nginx 反向代理
配好 Nginx 反代，让控制台通过 minio.lyjew.com、S3 API 通过 s3.lyjew.com 对外提供 HTTPS 访问（SSL 用 acme.sh 签发）。配置略，重点是这一步也顺利完成了。
二、踩坑一：控制台里找不到「Access Keys」
部署完，第一件事是想给未来的应用创建独立的访问密钥（Access Key / Secret Key）。打开网页控制台，翻遍了左侧菜单，「Access Keys」这个选项竟然不存在。我以为是 UI 改版换了个名字，又去找「Identity」，结果也没有。
这里我心里已经隐隐觉得不对劲了。正常的对象存储后台，建密钥是最基础的功能，怎么会连入口都找不到？
后来才查清楚：2025 年 5 月，MinIO 从社区版源码里删除了管理控制台（WebUI），账号/权限管理、桶管理、配置这些后台功能，被一次性移除了大约 11 万行代码。社区版用户被逼着只能去用命令行。
三、踩坑二：mc 客户端下载报 410 Gone
网页控制台用不了，那就退而求其次，用官方命令行工具 mc 来管理。按官方文档的地址去下载，结果直接收到一个 410 响应：
410 Gone
The open-source MinIO Server, MinIO Client (mc) and MinIO KES projects are
archived and no longer maintained. MinIO does not provide product support,
security updates, or security advisories for them...到这一步，事情的性质已经变了。这不是「某个功能没了」，而是整个开源项目被官方下架了。
四、踩坑三：桶列表一直「Loading」
用命令行建了桶、传了文件，想着回网页后台看看。结果打开控制台，桶列表一直卡在 Loading…，怎么刷新都加载不出来。
这时候所有线索串起来了：控制台的管理接口没了 → 前端加载了但拿不到数据 → 桶列表永远转圈。三个坑其实是同一个根因。
五、真相：MinIO 开源已死
查证后，MinIO 开源版的「死亡」时间线是这样的：
| 时间 | 事件 |
| 2021 | 许可证从 Apache 2.0 改为 AGPLv3 |
| 2025.05 | 从社区版源码删除管理控制台（WebUI），LDAP/OIDC 等移入企业版 |
| 2025.10 | 停止发布 Docker 镜像和预编译二进制，改为仅源码分发 |
| 2025.12 | 宣布进入「维护模式」，不再接受新功能与 PR |
| 2026.02 | 明确「不再维护」，GitHub 仓库归档 |
官方现在只推付费的企业版 AIStor，社区版彻底被放弃。所以才会出现：控制台被阉割、mc 下载 410、Docker 镜像不再更新这一连串现象。
六、还能怎么用：纯 CLI 苟着
尽管项目死了、控制台没了，但核心存储引擎（S3 API）其实还能用。你部署时设的 MINIO_ROOT_USER / MINIO_ROOT_PASSWORD，就是一对现成的管理员密钥，直接用命令行工具操作即可，不需要那个残缺的控制台。
6.1 用 aws cli（S3 兼容，最通用）
sudo apt install awscli
aws configure set aws_access_key_id admin
aws configure set aws_secret_access_key 你的强密码
aws configure set region us-east-1
# 所有操作加 --endpoint-url 指向 MinIO
aws --endpoint-url http://127.0.0.1:9000 s3 ls
aws --endpoint-url http://127.0.0.1:9000 s3 mb s3://photos
aws --endpoint-url http://127.0.0.1:9000 s3 cp ./a.jpg s3://photos/6.2 用 rclone（迁移/同步更强）
curl https://rclone.org/install.sh | sudo bash
rclone config # 类型选 s3，endpoint 填 http://127.0.0.1:9000，密钥填 admin / 强密码
rclone mkdir minio:photos
rclone copy ./a.jpg minio:photos/这样虽然能用，但体验已经退化成「一个只有 API 的裸服务」：没有网页后台，全靠命令行。
七、结论：换 SeaweedFS 或 Garage
踩完这一串坑，我的结论是：如果是新部署，别再用 MinIO 了。它的开源版已死、控制台被阉割、工具下架，继续用只会越来越别扭。
值得考虑的两个活跃替代：
| 项目 | 许可证 | 语言 | 特点 |
| SeaweedFS | Apache 2.0 | Go | 最接近 MinIO 的直接替代，海量小文件性能好，有完整 Web 控制台，活跃维护 |
| Garage | AGPL-3.0 | Rust | 超轻量单二进制，自托管友好，适合个人/中小规模 |
两者都是 S3 兼容，你现有的 aws cli / rclone 命令可以无缝切换。个人自用的话，我更倾向 SeaweedFS——它有完整的网页后台，建桶、看文件、管密钥都能像以前用 MinIO 那样在浏览器里完成。
八、写在最后
这次踩坑最大的收获，不是学会了怎么部署 MinIO，而是明白了选型时一定要看项目的维护状态和治理方式。一个没有开源治理、被单一厂商攥在手里的项目，再火也可能一夜之间「拔网线」。对象存储如此，其他基础设施项目亦然。
如果你也遇到了同样的坑，欢迎在评论区交流，也期待你分享替代方案的实战经验。
