hyperf 容器应以 bin/hyperf.php start 为 pid 1 直接运行，禁用 supervisor；需确保 swoole 已启用、监听地址为 0.0.0.0、禁用 --watch、参数适配 cpu 限制，并通过 docker-compose 依赖健康检查与端口映射实现可靠部署。
Hyperf 本身是常驻内存的协程框架，Docker 后台运行它并不需要额外守护进程（如 Supervisor），关键在于容器生命周期管理得当、启动命令正确、依赖服务就绪。
用 docker run -d 直接后台启动即可
Hyperf 的 bin/hyperf.php start 命令会启动 Swoole Server 并持续监听请求，属于前台阻塞式长进程。只要容器以 -d 模式运行，且该命令作为 CMD 或 ENTRYPOINT 执行，容器就会稳定常驻：
- 不推荐在容器内再套一层 Supervisor：增加复杂度、多一层故障点、且无法解决 Swoole 进程被误杀后自动拉起的问题（Supervisor 在容器里也受限于 PID 1 语义）
- 推荐做法：让 Hyperf 进程直接作为容器的 PID 1。Docker 会自然接管其生命周期——进程退出，容器就停止；容器重启，服务自动恢复
- 若需崩溃后自动重启，只需在
docker run加--restart=always，或在docker-compose.yml中写restart: always
确保 Swoole 扩展可用且配置合理
容器启动失败常因 Swoole 未加载或配置冲突。必须验证：
- 基础镜像已启用 Swoole（
php -m | grep swoole返回非空） -
server.php中监听地址设为0.0.0.0（而非127.0.0.1），否则容器内无法被外部访问 - 避免使用
--watch或--dev参数（仅开发用），生产环境应禁用文件监听 - 检查
worker_num、max_coroutine等参数是否适配容器 CPU 限制（如cpus: "2"）
配合 docker-compose 实现可靠单机编排
单机部署建议用 docker-compose.yml 统一管理 Hyperf + DB + Redis，重点配置：
-
depends_on配合健康检查（healthcheck），确保 MySQL/Redis 就绪后再启动 Hyperf -
volumes映射日志目录（如runtime/logs:/app/runtime/logs），便于排查 -
environment注入数据库连接、Redis 地址等，避免硬编码 -
ports显式暴露端口（如"9501:9501"），并确认宿主机防火墙放行
验证与日常维护要点
启动后快速确认服务真实就绪：
- 执行
docker-compose logs -f app查看启动日志，确认输出Server started和监听地址 - 用
curl http://localhost:9501/health（或你定义的健康接口）测试响应 - 检查
docker-compose ps，状态应为Up，不是Restarting或Exit - 更新代码后，无需进容器重启：重建镜像 +
docker-compose up -d即可平滑切换
