能，Workerman 可稳定运行于 Docker：需手动启用 pcntl/posix 扩展；必须用 CLI 模式启动（php start.php start）；监听地址设为 0.0.0.0 并正确映射端口；单容器建议 count=1。
能，而且很稳——Workerman 不仅能在 Docker 里运行，还是生产级高并发场景下容器化部署的成熟选择。关键不在于“能不能”，而在于“怎么配才不翻车”。
pcntl 和 posix 扩展必须显式安装
Workerman 依赖 pcntl（进程控制）和 posix（系统接口）才能启动多进程、捕获信号、优雅重启。PHP 官方镜像默认不启用这两个扩展，直接运行会报错：
Fatal error: Uncaught Error: Call to undefined function pcntl_signal()
常见错误现象：容器一启动就退出，docker logs 只显示 PHP Fatal 错误；或 Worker::runAll() 根本不执行。
- Alpine 镜像用
apk add --no-cache $PHPIZE_DEPS && pecl install pcntl && docker-php-ext-enable pcntl - Debian/Ubuntu 镜像用
docker-php-ext-install pcntl posix - 别信“PHP 8.1+ 自带”这种说法——CLI 镜像仍需手动编译启用
- 验证方式：
docker run --rm your-image php -m | grep -E "pcntl|posix"
start.php 必须用 CLI 模式启动，不能走 FPM 或 Web 服务器
Workerman 是纯命令行守护进程，php start.php start 是标准入口。如果误用 Nginx + PHP-FPM 模式部署，它根本不会监听端口，也不会响应 WebSocket 或 TCP 请求。
典型误操作：
- 在
docker-compose.yml中把command写成php-fpm或漏掉start参数 - 用
ENTRYPOINT ["php", "start.php"]但没传start，导致进入交互式 CLI - 镜像中
CMD写成["php", "start.php"]，而实际需要的是["php", "start.php", "start"]
正确示例（Dockerfile 片段）：
ENTRYPOINT ["php", "start.php"] CMD ["start"]
这样既支持覆盖启动参数（如加 -d），又避免硬编码。
端口暴露与宿主机映射必须双向对齐
Workerman 在代码里绑定的是容器内网地址（如 tcp://0.0.0.0:2345），但外部访问靠 Docker 的 -p 或 ports: 映射。一旦写反或遗漏，服务就“存在却不可达”。
常见问题：
-
$worker->listen('tcp://127.0.0.1:2345')→ 容器外连不上（只监听本地回环） -
docker-compose.yml写了- "2345:8080"，但代码监听的是:2345→ 端口错位 - WebSocket 场景下只映射了 HTTP 端口（如 80），忘了映射 WS 协议对应端口（如 2346）
- 使用
network_mode: host时未同步调整监听地址，导致端口冲突
建议始终用 0.0.0.0 绑定，并在 compose 中显式列出所有需暴露的端口：
ports: - "2345:2345" - "2346:2346"
最易被忽略的一点：Workerman 的 count 进程数建议设为 1（单进程）配合 Docker 的横向扩缩，而不是在单个容器里开 4–8 个进程——这会让资源限制（如 mem_limit）失效，也违背容器“一个容器一个主进程”的设计原则。
