必须用 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 在同一容器里跑，看似简单，实则无法独立扩缩、日志分离、健康检查失效。
立即学习“PHP免费学习笔记（深入）”；
- 拆分服务：
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 —— 后者只会让新旧代码逻辑混跑，问题更难定位。
