alpine镜像装composer会变胖，主因是其依赖工具拖入musl libc、busybox冗余文件及apk缓存，且vendor目录混入.git、测试和文档；必须用多阶段构建分离“构建”与“运行”，builder阶段安装并清理，final阶段仅复制精简后的vendor，且所有apk add须带--no-cache。
为什么Alpine里装Composer会悄悄变胖
直接在最终镜像中装Composer，几乎必然导致体积失控——不是因为Composer本身大，而是它依赖的git、unzip、curl等工具会把整个musl libc动态链接库、busybox冗余二进制、APK缓存全拖进来。更糟的是，composer install生成的vendor/里混着.git目录、测试文件、文档，这些默认不会被清理。
多阶段构建必须分清“谁干活、谁上线”
builder阶段用php:8.2-cli-alpine（带完整CLI工具链），final阶段换php:8.2-fpm-alpine（精简无CLI）。关键不在基础镜像名字，而在行为分离：
- builder阶段只做三件事：装
git unzip curl→ 下载composer.phar→ 运行composer install --no-dev --optimize-autoloader --classmap-authoritative - final阶段只
COPY --from=builder /app/vendor ./vendor，不复制composer.json、composer.lock，也不运行任何composer命令 - builder末尾加
rm -rf /root/.composer /tmp/* /var/cache/apk/*，但前提是apk add已带--no-cache
APK缓存不清理=白瘦身
apk add默认把包索引和下载的.apk文件写进/var/cache/apk/，这个目录一旦出现在某层，就永远计入镜像体积——哪怕下一层rm -rf也删不掉。验证很简单：构建完跑docker run --rm your-image ls -la /var/cache/apk/，输出应为空。
- 所有
apk add必须带--no-cache，例如：apk add --no-cache git unzip curl - 别用
apk add --update-cache，它会主动写缓存；需要临时源时用--repository - 如果用了BuildKit，可改用
RUN --mount=type=cache,id=apk-cache,dest=/var/cache/apk，但多数场景--no-cache更稳
最终镜像里藏着Composer就是失败
检查最终容器是否含以下任意一项，说明瘦身没到位：
-
/usr/local/bin/composer或/usr/bin/composer -
/root/.composer目录 -
vendor/bin/下除phpunit外的其他可执行文件（如doctrine、phpcs） -
vendor/*/tests/、vendor/*/docs/、vendor/*/CHANGELOG.md
真正干净的生产镜像，只该有vendor/autoload.php、vendor/composer/（含autoload_*.php）和实际用到的扩展类文件——其余全是干扰项。
