PHP镜像优化核心在于多阶段构建与精准裁剪：用builder阶段安装依赖并编译，runtime阶段仅复制必要文件和扩展，避免工具链残留；选合适基础镜像（alpine或bullseye-slim），精确COPY运行所需路径，配合.dockerignore排除冗余文件。
PHP 8.5 官方尚未发布（截至 2026 年 7 月），当前稳定版最高为 PHP 8.4；若你实际使用的是 php:8.4-cli-alpine 或自行编译的 PHP 8.5 镜像，优化逻辑完全适用——关键不在版本号，而在构建方式是否“分阶段”和“去冗余”。直接上可落地的实操点。
用多阶段构建分离 build 与 runtime
这是减小体积最有效的一招。很多 PHP 镜像体积爆炸，是因为把 composer、git、pecl、编译工具链全塞进最终镜像里。
- 第一阶段（
builder）用完整镜像（如php:8.4-cli-alpine），只干三件事：装依赖、编译扩展、生成 autoload； - 第二阶段（
runtime）切到更轻的镜像（如php:8.4-fpm-alpine或php:8.4-apache-alpine），只复制/var/www/html、/app/vendor、php.ini和必要扩展（如opcache.so、redis.so）； - 绝对避免在 runtime 阶段
RUN apk add或docker-php-ext-install—— 这会让所有构建工具残留进最终层。
选对基础镜像，别盲目用 alpine
alpine 确实体积小（~15MB），但 musl libc 兼容性有坑：某些 PECL 扩展（如 grpc、sqlsrv）不支持，或运行时报 undefined symbol: clock_gettime。
- 如果项目无特殊扩展依赖，优先用
php:8.4-fpm-alpine； - 若需
pdo_sqlsrv或oci8，改用php:8.4-fpm-bullseye-slim（Debian slim，约 90MB，glibc 兼容性好）； - 千万别用
php:8.4（默认 full Debian，含vim、bash、systemd等，体积常超 400MB）。
COPY --from 要精确，别复制整个 /usr
常见错误是写 COPY --from=builder /usr /usr，结果把 /usr/src、/usr/lib/php 下所有 .a/.o 文件、build cache 全拖进来，白增 30–50MB。
立即学习“PHP免费学习笔记（深入）”；
- 只复制运行必需项：
COPY --from=builder /app/vendor /var/www/html/vendor； - 扩展要单独复制：
COPY --from=builder /usr/lib/php/extensions/no-debug-non-zts-20230831/opcache.so /usr/lib/php/extensions/； - 用
find /usr/lib/php/extensions -name "*.so" -not -name "dev*" | xargs ls -lh在 builder 阶段确认真实路径和文件名； - 删掉
/tmp、/root/.composer、/var/cache/apk—— 它们不会被自动清理。
忽略 .dockerignore 是最常被跳过的一步
没它，COPY . . 会把 node_modules、.git、tests/、vendor/bin 全打进镜像，体积翻倍。
- 确保
.dockerignore至少包含：node_modules、.git、.gitignore、tests、docs、phpunit.xml、composer.lock（如果已 COPY 过）； - 不要写
*再逐条!xxx—— Docker 不支持负向 glob，!vendor/autoload.php无效； - 验证是否生效：
docker build --no-cache -f /dev/null .（空 Dockerfile）+--dry-run不可用，最简办法是tar cf - . | tar t | grep -E "(node_modules|\.git)"看是否真被排除。
真正难的不是写对语法，而是搞清哪些文件 *必须* 留下、哪些 *看似有用* 其实是构建残留。比如 vendor/composer/autoload_*.php 必须留，但 vendor/composer/installed.json 可删；opcache.so 必须留，但 opcache.a 和 opcache.la 绝对不能进 runtime 镜像。
