webman容器化部署关键在于pcntl和posix扩展必须显式启用，否则start.php start -d会静默失败；需在dockerfile中run docker-php-ext-install pcntl posix，并配对使用，缺一不可。
Webman 容器化部署的关键不在“会不会”，而在“pcntl 和 posix 扩展有没有真正生效”——没启用这两个扩展，start.php start -d 会静默失败或退回到 CLI 模式，容器看似运行实则无服务。
docker build 构建时 pcntl/posix 扩展未加载的典型表现
容器启动后 php start.php start -d 没报错但访问 http://localhost:8787 超时；docker logs -f 看不到 Workerman 启动日志（如 “Workerman start success”）；ps aux | grep php 在容器内查不到 worker 进程。根本原因是 PHP 镜像默认不启用这两个扩展，必须显式安装。
构建镜像时务必在 Dockerfile 中加入：
RUN docker-php-ext-install pcntl posix
注意：pcntl 和 posix 必须一起装，缺一不可；Alpine 镜像需额外装 gcc 和 make，否则编译失败；PHP 8.2+ 的 cli 镜像比 fpm 更适配 Webman，因后者依赖命令行长期驻留能力。
docker-compose.yml 中端口与守护模式的匹配陷阱
Webman 默认监听 0.0.0.0:8787，但若 docker-compose.yml 写成 "8787:8080" 或漏掉 0.0.0.0: 前缀，会导致端口映射错位或绑定失败。
正确写法应明确容器内端口与宿主机端口一致：
ports: - "8787:8787"
同时确保启动命令为：
command: php start.php start -d
常见错误包括：
- 用
start -g（调试模式）上线，导致进程随终端退出而终止 - 忘记
-d参数，容器以前台模式启动后立即退出 - 在
command中写绝对路径但WORKDIR未设对，导致找不到start.php
生产环境必须禁用的开发配置项
本地能跑 ≠ 生产能用。以下三项不清理，上线后大概率触发内存泄漏或安全风险：
-
APP_DEBUG=true：必须设为false，否则异常堆栈直接暴露在响应体中 -
composer install --no-dev --optimize-autoloader：构建镜像时漏掉--no-dev，会带入phpunit、symfony/var-dumper等非运行时依赖，增大镜像体积且可能引入漏洞 - 未删除
runtime/log目录挂载或日志轮转配置：容器重启后日志丢失，或因写满临时文件系统导致服务僵死
建议在 Dockerfile 末尾加一句 RUN rm -rf runtime/log/*，日志统一走 stdout 由 Docker 捕获。
多实例健康检查与服务发现的最小可行配置
单容器跑通只是起点。要支持自动扩缩容，docker-compose.yml 必须定义可探测的健康状态：
healthcheck: test: ["CMD", "curl", "-f", "http://localhost:8787/health"] interval: 30s timeout: 10s retries: 3
这个 /health 路由需在 Webman 中手动实现，返回 HTTP 200 即可，不要查 DB 或 Redis——否则健康检查本身会成为瓶颈。Consul/Nacos 注册依赖此状态，K8s HPA 伸缩也靠它判断实例是否就绪。
容易被忽略的一点是：多个 Webman 实例共享 redis 或 mysql 连接池时，必须确认连接数上限（如 max_connections=200）足以支撑所有副本，否则扩容后反而出现连接拒绝。
