在 Dockerfile 里，PHP 版本和扩展一定要明确锁死，别把这件事交给“默认配置”碰运气。

基础镜像优先选择 php:8.2-fpm-alpine 或 php:8.2-fpm-bookworm。核心扩展用 docker-php-ext-install 来安装。

开发配置要关掉，OPcache 要启用，而且要把配置固定下来。与此同时，服务要拆分，资源要设限，健康检查要写得贴近真实运行状态，卷尽量只读，环境变量与配置解耦，敏感信息交给密钥管理。

到了 CI/CD 环节，则应构建不可变镜像，并完成验证，这才算把整套链路真正收紧。

用 Dockerfile 锁定 PHP 版本与扩展

生产环境最怕“版本漂移”。今天能跑的代码，明天可能因 PHP 小版本升级或扩展缺失直接报 Class not found。

必须在 Dockerfile 中显式声明所有依赖，不能靠运行时动态安装。

常见错误是只写 FROM php:8.2，却没指定镜像变体，如 -fpm-alpine 或 -apache-bullseye。这样很容易导致后续扩展安装失败，或性能差异巨大。

• 优先选 php:8.2-fpm-alpine（轻量、安全）或 php:8.2-fpm-bookworm（兼容性更强）
• 用 docker-php-ext-install 安装核心扩展，如 pdo_mysql、opcache，避免用 pecl install 引入不稳定版本
• 禁用开发扩展：--no-dev 传给 composer install，且删掉 php.ini 中的 display_errors = On
• OPcache 必须启用并固化配置：opcache.validate_timestamps=0（生产）+ opcache.memory_consumption=256

用 docker-compose.yml 编排服务边界

本地能跑，不等于生产能稳。关键不在于堆服务，而在于定义清晰的通信边界和资源约束。

典型坑点是 Nginx 和 PHP-FPM 在同一容器里跑。看似简单，实则无法独立扩缩、日志分离，健康检查也容易失效。

• 拆分服务：nginx、php-fpm、mysql、redis 各自独立容器，通过自定义网络互通
• 限制资源：deploy.resources.limits.memory 防止单个服务吃光主机内存
• 健康检查必须写实：healthcheck.test 不能只测端口，要调 curl -f http://localhost/health.php 真实路径
• 卷挂载只读化：volumes: ["./app:/var/www/html:ro"]，杜绝运行时意外修改代码

用 .env + 环境变量注入配置差异

硬编码数据库密码、API 密钥进代码库，等于把钥匙挂在 GitHub 上。生产配置必须和代码解耦，且不可提交到 Git。

很多人会把 .env 文件直接 commit。结果上线后被 git pull 覆盖，或者误把 APP_DEBUG=true 带到生产。

• .env 只用于本地开发，生产环境通过 docker run --env-file 或 CI/CD 工具注入变量
• 敏感项，如 DB_PASSWORD，绝不走环境变量明文传递，改用 Docker Secrets 或云平台密钥管理服务（如 AWS Secrets Manager）
• PHP 中读取统一用 $_ENV 或 getenv()，别混用 $_SERVER —— FPM 模式下 $_SERVER 不一定包含环境变量
• 配置项要有默认兜底：$_ENV['APP_ENV'] 'production'，避免空值引发逻辑崩溃

用 CI/CD 构建不可变镜像并验证

“本地构建再 scp 到服务器” 是最大反模式。镜像必须在 CI 流水线中构建、测试、打标签，然后原封不动部署。

常见漏洞包括：CI 中跑 composer install，但没锁 composer.lock；或者测试时用 dev 依赖，上线却删了，最终导致 Class 'Mockery' not found 这类错误。

• CI 脚本第一行必须是 composer install --no-dev --optimize-autoloader，且 composer.lock 已提交
• 构建后立即跑冒烟测试：curl -s http://localhost/ping | grep OK，验证容器能响应
• 镜像标签用 Git SHA，如 sha-abc1234，别用 latest —— 否则回滚无依据
• 生产部署命令只能是 docker service update --image myapp:sha-abc1234，禁止任何 docker exec 临时修复

真正难点：每一步都要拒绝侥幸心理

真正的难点，不在写对四步，而在每一步都拒绝“先上线再说”的侥幸心理。

比如 OPcache 关闭时间戳验证后，代码更新必须伴随镜像重建和滚动发布，而不是 reload php-fpm。

后者只会让新旧代码逻辑混跑，问题更难定位。

《夸克》非常好用的免费AI浏览器

下载APP查看