通过多阶段构建和缓存优化可显著减小PHP Docker镜像体积：首先使用builder阶段安装依赖并启用Redis扩展，利用COMPOSER_CACHE_DIR避免缓存污染，COPY composer.json和composer.lock前置以提升层缓存命中率，执行composer install时使用--no-dev和--optimize-autoloader减少vendor大小，随后在最终阶段基于alpine镜像复制vendor和源码，通过find命令或composer钩子清理测试文件、文档和.git目录，确保最终镜像仅包含运行所需内容，从而实现快速构建与最小化体积。
在使用Docker构建PHP应用时，特别是结合Composer管理依赖，镜像体积很容易膨胀。通过多阶段构建和合理的缓存策略，可以显著减小最终镜像的大小。关键在于分离依赖下载与源码构建，并利用Docker的层缓存机制。
利用多阶段构建分离构建与运行环境
多阶段构建允许你在同一个Dockerfile中使用多个FROM指令，每个阶段可以基于不同的基础镜像。你可以用一个阶段专门处理Composer安装，另一个阶段只复制运行所需的文件。
例如：
FROM php:8.3-cli AS builderWORKDIR /app COPY composer.json composer.lock ./ RUN pecl install redis && docker-php-ext-enable redis
RUN curl -sS https://www.php.cn/link/e910517884e11c8a741c3b1da823f47e | php -- --install-dir=/usr/local/bin --filename=composer RUN COMPOSER_CACHE_DIR=/tmp/cache composer install --no-dev --optimize-autoloader
FROM php:8.3-cli-alpine
WORKDIR /app COPY --from=builder /app/vendor /app/vendor COPY . . CMD ["php", "index.php"]
这样，构建依赖的扩展、Composer本身以及临时缓存都留在builder阶段，不会进入最终镜像。
合理利用Composer缓存提升构建速度
Docker默认会缓存每一层，但如果composer.json变化，后续所有层都会失效。通过提前拷贝composer相关文件并单独执行依赖安装，可以让依赖缓存更持久。
技巧包括：
- 先COPY composer.json 和 composer.lock，再RUN composer install。这样只有当这两个文件变化时才重新安装依赖
- 设置COMPOSER_CACHE_DIR指向临时目录，避免缓存污染最终镜像
- 使用--no-dev排除开发依赖，--optimize-autoloader生成静态 autoload 映射
示例：
COPY composer.json composer.lock ./ RUN COMPOSER_CACHE_DIR=/tmp/cache composer install --no-dev --optimize-autoloader
即使后续添加了新的PHP文件，只要composer.json未变，这一层仍可复用缓存。
精简最终镜像：移除不必要的文件
Composer安装后会留下一些非必要文件，如文档、测试用例或VCS信息。可以在安装后清理这些内容。
建议在composer install后执行清理命令：
RUN COMPOSER_CACHE_DIR=/tmp/cache composer install --no-dev --optimize-autoloader \
&& find vendor -type d -name 'test*' -o -name 'Test*' -o -name 'tests*' | xargs rm -rf \
&& find vendor -type f -name '*.md' | xargs rm -f \
&& find vendor -type d -name '.git' | xargs rm -rf
也可以在composer.json中配置钩子自动清理：
"scripts": {
"post-install-cmd": [
"rm -rf vendor/**/tests",
"rm -rf vendor/**/*.md",
"rm -rf vendor/**/.git"
]
}
进一步缩小vendor目录体积。
基本上就这些。通过分阶段构建、精准缓存控制和后期清理，既能加快构建速度，又能有效压缩最终镜像体积。关键是把变动频率低的内容（如依赖）放在上层，高频变动的源码放在下层。不复杂但容易忽略。
