官方php:8.3镜像不可直接用于生产，因其默认display_errors=On、OPcache禁用、UTC时区、日志输出到stdout，易致敏感信息泄露、性能下降、时区错乱及日志不可追溯。
直接用 php:8.3-apache 或 php:8.3-fpm 镜像跑 PHP 8.3 是可行的，但生产环境必须控制扩展、OPcache、时区、错误报告级别和日志路径——否则 CI 构建出的镜像在 UAT 和生产上行为不一致，上线后才发现 display_errors=On 暴露了敏感路径。
为什么不能直接用官方 php:8.3 镜像做生产构建
官方镜像默认开启 display_errors、禁用 OPcache、使用 UTC 时区、日志写入 /proc/self/fd/2（即容器 stdout），这些都不符合生产要求：
-
display_errors=On会把堆栈信息直接返回给 HTTP 响应，暴露代码结构和路径 - 没启用 OPcache 会导致每次请求都重编译 PHP 文件，CPU 使用率飙升
- UTC 时区会让
date()、Carbon::now()返回非本地时间，影响日志打点和定时任务 - 日志不落盘、不轮转，CI 流水线里
docker logs看不到完整错误上下文
如何定制 PHP 8.3 的 Dockerfile 实现生产就绪
关键不是“能跑”，而是“可观察、可复现、可审计”。推荐多阶段构建 + 显式配置覆盖：
- 第一阶段用
php:8.3-cli安装依赖、运行测试、生成缓存文件 - 第二阶段用
php:8.3-apache（或php:8.3-fpm+ Nginx）仅复制必要产物 - 通过
COPY --from=0 /usr/local/etc/php/conf.d/zz-production.ini /usr/local/etc/php/conf.d/注入定制 INI - 显式设置
ENV TZ=Asia/Shanghai并RUN ln -sf /usr/share/zoneinfo/$TZ /etc/localtime - 用
RUN docker-php-ext-enable opcache启用扩展，而不是靠镜像默认
示例 zz-production.ini 片段：
立即学习“PHP免费学习笔记（深入）”；
opcache.enable=1 opcache.memory_consumption=256 opcache.max_accelerated_files=20000 opcache.revalidate_freq=60 date.timezone=Asia/Shanghai log_errors=On error_log=/var/log/php/error.log display_errors=Off html_errors=Off memory_limit=512M
GitLab CI 中怎么验证 PHP 配置是否生效
别只信 php -v，得在 CI job 里实际检查运行时行为。建议在 .gitlab-ci.yml 的 test 阶段加一个脚本验证：
- 用
php -i | grep 'opcache.enable'确认 OPcache 已启用 - 用
php -r "echo date_default_timezone_get();"核对时区 - 用
php -r "error_log('ci-test');"+ls -l /var/log/php/检查日志路径是否可写 - 用
curl -s http://localhost/health.php 2>/dev/null | grep -q "OK"调用一个最小健康检查脚本
这个健康脚本（health.php）只需输出 JSON 并检查关键扩展是否存在：
<?php
$required = ['pdo_mysql', 'redis', 'opcache'];
$missing = array_filter($required, fn($ext) => !extension_loaded($ext));
if (!empty($missing)) {
http_response_code(503);
echo json_encode(['status' => 'error', 'missing_extensions' => $missing]);
} else {
echo json_encode(['status' => 'OK']);
}
Runner 执行器选 shell 还是 docker？
选 docker 执行器。原因很实在：
-
shell执行器共享宿主机 PHP 环境，不同项目 PHP 版本/扩展冲突，CI job 之间互相污染 -
docker执行器每个 job 启一个干净容器，image: php:8.3-cli就是那个项目的唯一 PHP 环境 - GitLab Runner 的
docker执行器支持services（如 MySQL、Redis），方便集成测试 - 注意：Runner 宿主机必须已安装 Docker，并且
gitlab-runner用户在docker组里，否则报permission denied while trying to connect to the Docker daemon socket
注册 Runner 时务必指定 --executor docker --docker-image php:8.3-cli，避免 job 默认用 alpine:latest 导致 PHP 命令根本不存在。
最常被忽略的一点：PHP 镜像里的 www-data 用户 UID 在不同基础镜像中可能不一致（比如 Alpine 是 82，Debian 是 33），如果挂载宿主机目录进容器并写日志，权限错乱会导致日志无法写入——这个问题在 CI 构建阶段不会暴露，要等部署到目标服务器才炸。
