alpine中安装composer必须用curl方式而非apk，因3.16+已移除该包；需多阶段构建分离安装与运行环境，并全局配置阿里云镜像源——三者缺一不可。
直接在 Alpine 镜像里装 Composer 并不能“加速运行”，反而极易因缺依赖、权限错、缓存残留导致构建失败或镜像臃肿；真正有效的做法是：用多阶段构建隔离安装过程，只把 vendor/ 和优化后的 autoloader 复制进最终镜像，同时全局配置阿里云镜像源——这三步缺一不可。
为什么 apk add composer 在 Alpine 3.16+ 会报错
Alpine 官方从 3.16 起已移除 composer 包，错误信息通常是 ERROR: unable to select packages。这不是网络或权限问题，而是仓库策略变更：维护者认为 Composer 属于 PHP 应用层工具，不该作为系统包分发，且其自身对 git、unzip 的版本要求与 Alpine 不一致。
- 别再写
RUN apk add composer，它在当前主流 Alpine（3.18/3.19）中必然失败 - 必须改用官方推荐方式：
curl -sS https://getcomposer.org/installer | php - 但该命令前置条件硬性依赖
git、unzip、curl—— 缺任一个都会卡在 “failed to extract” 或 “Cloning into…”
多阶段构建中怎么安全装 Composer 并完成 install
关键不是“能不能装”，而是“装在哪、装完留不留”。builder 阶段要完整，runtime 阶段要干净，中间不能混用用户、路径或缓存。
- builder 阶段用
php:8.3-cli-alpine（含docker-php-ext-install和apk），而非alpine:latest自建 PHP - 安装前必须跑：
apk add --no-cache git unzip curl；装完立刻删掉：apk del --purge git unzip curl - 执行
composer install --no-dev --optimize-autoloader --no-interaction，避免交互卡住或 dev 包污染 - 务必加
--no-interaction，否则遇到私有包或 prompt 会挂起；不加--no-dev会导致 vendor 体积翻倍
如何让 composer install 真正变快（不是假快）
换源不是锦上添花，是解决 90% 卡顿的刚性前提。直连 packagist.org 在国内多数场景下等同于无限等待。
- 全局配置（builder 阶段内执行）：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，注意末尾必须有/ - 验证是否生效：
composer config -g repo.packagist输出应为完整 JSON：{"type":"composer","url":"https://mirrors.aliyun.com/composer/"} - 别信
composer diagnose显示 “Repo packagist.org is default”——它可能只是没读到全局配置，实际请求已走镜像 - 已有
composer.lock的项目首次切镜像，大概率报 hash mismatch；稳妥做法是RUN rm -f composer.lock vendor && composer install
最终镜像里绝对不能出现的三样东西
很多人以为“删了 /tmp 就瘦了”，其实最占体积的是被误带进 runtime 阶段的构建期残留物。这些文件不仅增大体积，还可能引发安全扫描告警或运行时覆盖风险。
-
composer.json和composer.lock：运行时完全无用，且一旦存在，CI 或运维手抖执行composer install会覆盖已优化的 autoloader -
/home/app/.composer/目录：builder 阶段生成的缓存和配置，runtime 阶段既不需要也不该存在；保留它会暴露用户家目录结构 - root 用户 + 未设 UID：Musl libc 下
composer对/home/root/.composer写权限极敏感，不显式创建非 root 用户（如adduser -D -u 1001 app）并USER app，第一次运行必报touch(): Unable to create file
