Webman用docker-compose up -d启动失败主因是PHP镜像缺失pcntl/posix扩展，导致start.php无法守护运行；须定制Dockerfile安装扩展、执行composer install、设runtime权限、固定CMD命令。
Webman 项目直接用 docker compose up -d 启动失败，八成是 PHP 扩展缺失或镜像没装 pcntl/posix —— 这两个扩展不是可选项，是 Webman 常驻运行的硬性门槛。
为什么官方 docker-compose.yml 启动后立刻退出？
根本原因：容器内 PHP 缺少 pcntl 或 posix 扩展，导致 start.php start -d 无法进入守护进程模式，执行完就退出。这不是配置问题，是镜像构建缺陷。
- 用
php -m | grep -E "pcntl|posix"进入容器验证（docker compose exec webman sh） - 官方预置的
docker-compose.yml默认基于php:8.2-cli，但该镜像不自带pcntl/posix，必须显式安装 - Alpine 镜像需用
apk add+docker-php-ext-install组合；Debian/Ubuntu 镜像用apt install+docker-php-ext-install - Windows 用户若用 WSL2 外的 Docker Desktop，别依赖宿主机 PHP 环境 —— 容器内环境完全独立
如何改写 Dockerfile 保证 Webman 稳定常驻？
不能直接复用通用 PHP 镜像，必须定制化构建。关键动作是「装扩展 → 清依赖 → 设权限 → 固命令」。
- 基础镜像选
php:8.2-cli（非-fpm，Webman 不走 FPM） - 必须执行：
docker-php-ext-install pcntl posix（顺序无关，但缺一不可） -
composer install --no-dev --optimize-autoloader要在容器内执行，而非宿主机；否则vendor/权限或架构可能错乱 -
RUN chmod -R 777 /app/runtime，否则日志、session、cache 写入失败，start.php启动时静默报错 - 入口命令固定为：
CMD ["php", "/app/start.php", "start", "-d"]，别加sh -c包裹，会干扰信号传递
docker-compose.yml 里哪些配置动不得？
端口映射、健康检查、卷挂载这三项一旦配错，服务就不可达或状态误判。
立即学习“PHP免费学习笔记（深入）”；
-
ports: ["8787:8787"]是默认约定，改端口可以，但必须同步改config/server.php中的'port' => 8787 -
healthcheck必须用curl -f http://localhost:8787/ping，不能用/或其他路径 —— Webman 默认只在/ping暴露健康端点 -
volumes只挂载代码目录（如./:/app），别挂载整个宿主机/var/www—— 容器内/app/runtime必须可写，挂载粒度太粗会导致权限冲突 - 别加
restart: always在开发环境 —— 启动失败时无限重启会掩盖真实错误，先确保单次启动成功再加
Windows 下访问不到 8787 端口？查三件事
Docker Desktop 的网络模型和 Linux 不同，127.0.0.1 不等于容器 localhost。
- 先确认容器 IP：
docker inspect <container_id> | grep IPAddress</container_id>，看到的是类似172.19.0.2的内网地址 - 宿主机浏览器不能输
http://127.0.0.1:8787，得输http://localhost:8787（Docker Desktop 自动做了端口转发） - 如果仍打不开，检查 Windows 防火墙是否拦截了 8787 端口 —— Docker Desktop 不自动放行自定义端口
- 别用
host网络模式，它在 Windows 上行为不稳定，bridge是唯一可靠选择
最易被忽略的是 runtime/ 目录权限和 pcntl 扩展的编译完整性 —— 它们不出错不报错，但会让 Webman 表现为“启动即消失”，连日志都不留一行。
