如果你部署 Coze 时看到 `coze-server` 一直重启，别先把锅甩给模型。公开 issue 里，这类问题很常见的根因其实是 MinIO、bucket、账号密码或者对象存储初始化没过。官方开源仓库还是 coze-dev/coze-studio，从它的 `docker-compose.yml` 也能看出，MinIO 是整套服务链路里很关键的一环。
换句话说，coze-server 的重启很多时候不是“它自己想重启”，而是它启动时依赖的基础服务没准备好。等它去连 MinIO、查 bucket、读配置时一旦失败，就会直接卡住或退出，看起来像反复拉起。
先看报错里最关键的一句
如果日志里出现类似 init minio client failed、check bucket opencoze exist failed 这样的内容，优先检查的不是工作流，也不是模型管理，而是 MinIO 本身。社区里也有人遇到过类似情况，最后发现是 MinIO 没正常起来，或者配置的 MINIO_ROOT_USER、MINIO_ROOT_PASSWORD 和实际容器里不一致。
再回到官方 compose 文件
官方 docker-compose.yml 里能看到 coze-server 依赖了 MySQL、Redis、Elasticsearch、MinIO、Milvus 等服务。这个结构本身就在提醒你：server 重启往往只是表象，真正的问题在前置依赖服务里。尤其是对象存储和 bucket 初始化，只要有一步没对上，后面就会连锁失败。
- 先确认 MinIO 容器是不是 healthy。
- 再确认 bucket 是否按预期创建，比如默认的 `opencoze`。
- 再检查 `.env` 里的账号密码是否和容器环境一致。
- 最后再看 `coze-server` 的启动日志，而不是只盯着重启现象。
社区里最实用的处理顺序
很多人第一反应是重启整套 Docker，但更有效的做法是从依赖链往上排：对象存储、数据库、缓存、搜索引擎都正常后，再看 coze-server。如果你一上来就重启 server，本质上只是重复触发同一个失败。
另外，docker-compose.yml 里还把 ./.env 挂进了容器，说明有些问题不是“容器里改一下就行”，而是配置文件本身就要统一。这个细节在本地部署时特别容易被忽略。
一句话结论
coze-server 一直重启，大概率先去查 MinIO、bucket 和环境变量。把基础服务修正后，再看 server 日志，通常比盲目重启更快。
