必须用容器镜像固化 php 运行时，因本地与线上环境差异（php/扩展/系统库/glibc 版本）导致配置不一致；优先用 docker-php-ext-install 安装官方扩展，避免 pecl 的构建环境依赖问题；php.ini 配置应拆分为 conf.d 下的独立文件并用环境变量动态覆盖；敏感信息严禁写入 dockerfile env，须通过 run-time 方式注入；启动前须验证 php -m 和 php --ini 确保配置生效。
必须用容器镜像固化 PHP 运行时，而不是靠“手动对齐配置”。 本地和线上 PHP 配置不一致的根源，从来不是 php.ini 写得不对，而是底层环境（PHP 版本、扩展版本、系统库、甚至 glibc 版本）根本不同。你改了 upload_max_filesize，却没发现线上缺 openssl 扩展，或者本地用的是 opcache.enable=1、线上因为 PHP 版本低根本不支持该指令——这类问题没法靠人肉比对解决。
为什么 docker-php-ext-install 比 pecl install 更可靠
很多团队在 Dockerfile 里用 pecl install redis，结果线上构建失败或扩展行为异常。这是因为 pecl 安装的扩展依赖当前系统的编译工具链和头文件，而不同基础镜像（比如 php:8.1-fpm-alpine 和 php:8.1-fpm-debian）的构建环境差异很大。
-
docker-php-ext-install是官方镜像预置的脚本，它会自动适配当前镜像的构建路径、头文件位置和编译参数，安装的扩展与 PHP ABI 兼容性有保障 - 它只支持 PHP 官方扩展（如
pdo_mysql、zip、opcache），不支持第三方扩展（如swoole），这点要提前确认项目依赖 - 若必须用
pecl，务必在RUN步骤中显式安装对应构建依赖，例如 Alpine 下要先apk add --no-cache $PHPIZE_DEPS
php.ini 配置不能 COPY，要用 conf.d + 环境变量覆盖
直接 COPY php.ini /usr/local/etc/php/php.ini 看似简单，但会导致两个问题：一是覆盖了镜像中其他扩展自带的 .ini 文件加载顺序；二是无法按环境动态调整，比如开发要 display_errors=On、生产必须关。
- 把自定义配置拆成单独文件，例如
COPY custom.ini /usr/local/etc/php/conf.d/99-custom.ini，利用 PHP 加载conf.d目录的顺序机制 - 敏感或可变配置（如
memory_limit、max_execution_time）改用环境变量注入，PHP 启动时通过ini_set()或启动脚本动态覆盖 - 检查最终生效值用
php -i | grep 'upload_max_filesize'，别只看配置文件内容
环境变量注入必须区分 build-time 和 run-time
很多人把数据库密码、API Key 写进 Dockerfile 的 ENV 指令，这会让密钥硬编码进镜像层，一推到 registry 就泄露。
-
ENV只用于 build-time 固定值（如COMPOSER_HOME），绝不能放敏感信息 - run-time 配置必须通过
docker-compose.yml的environment或env_file注入，Kubernetes 则必须用Secret挂载 - PHP 中统一用
getenv('DB_HOST') ?: $_SERVER['DB_HOST']获取，避免依赖$_ENV（默认可能未启用） - 验证是否注入成功：进容器执行
printenv | grep DB，再对比php -r "var_dump(getenv('DB_HOST'));"
最常被忽略的一点是：PHP 镜像的 entrypoint 或 cmd 脚本是否真正 reload 了配置。有些自定义启动脚本会跳过 php-fpm -t 校验，导致配置语法错误却无提示，容器静默降级为默认值运行。上线前务必进容器跑一次 php -m 和 php --ini，眼见为实。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
