Alpine安装Composer必须先apk add --no-cache git unzip curl，否则因缺依赖导致失败；应采用多阶段构建，构建阶段装Composer并安装依赖，运行阶段用精简PHP镜像仅复制vendor；必须创建非root用户并预设权限，且所有apk命令须带--no-cache。
Alpine里装Composer必须带git和unzip
直接跑curl -sS https://getcomposer.org/installer | php会失败——不是脚本问题，是缺依赖。Alpine默认不带git（Composer拉私有包、解析composer.json里的VCS源都要它），也不带unzip（很多PHP包分发用zip格式，没它就卡在“failed to extract”）。curl倒常被忽略，但https源必须它。
-
apk add --no-cache git unzip curl必须放在安装Composer前，且一定加--no-cache - 别用
php composer.phar install代替全局composer命令：Docker构建中路径错位、shell找不到二进制、后续RUN指令无法复用PATH，全在这儿埋雷 - 验证是否真装上了：进容器跑
composer --version，别只看RUN阶段没报错就以为成
多阶段构建才是瘦身核心，不是删文件能解决的
很多人以为“装完rm -rf /tmp/* && rm -rf /var/cache/apk/*”就瘦了，其实没用——Alpine镜像体积暴增的主因，是第一阶段用了php:8.2-cli-alpine（含完整dev工具链），却把它整个层都复制进了最终镜像。
- 正确做法：用
AS builder阶段装Composer、跑composer install --no-dev --optimize-autoloader；第二阶段切到更小的php:8.2-alpine（不含cli、pear、dev扩展），只COPY --from=builder /app/vendor /app/vendor - 千万别把
composer.json和composer.lockCOPY进最终镜像：它们对运行时零价值，反而可能被误触发composer install覆盖已优化的autoloader - 第二阶段起手先
apk del --purge git unzip curl：这些只是构建期依赖，运行时根本不需要
“Do not run Composer as root”不是警告，是硬限制
在Alpine容器里用root执行composer install，大概率报错退出，尤其当项目含scripts或需要写.composer/缓存时。Musl libc + BusyBox环境下，权限模型比glibc更敏感。
- 解决方案不是加
--no-interaction或--ignore-platform-reqs，而是创建非root用户：adduser -D -u 1001 app，然后USER app - 如果必须用root（比如某些CI环境），加
--no-plugins --no-scripts绕过用户目录初始化，但这是权宜之计，不是常态方案 -
/home/app/.composer目录得提前chown -R app:app /home/app，否则第一次运行仍卡在touch(): Unable to create file /home/app/.composer/config.json
--no-cache对apk不是可选项，是必须项
Alpine的apk默认把索引和下载的.apk包缓存在/var/cache/apk/。这个目录哪怕你在下一层RUN rm -rf /var/cache/apk，只要上一层存在，它就计入镜像体积——Docker层不可变，删不掉历史残留。
- 所有
apk add命令必须带--no-cache，例如：apk add --no-cache git unzip curl - 要换国内源？改
/etc/apk/repositories，别用apk add --update-cache，后者会写缓存 - 验证是否生效：构建完进容器跑
ls -la /var/cache/apk/，输出应为空；如果看到一堆*.apk，说明缓存没关，镜像至少虚胖5–10MB
复杂点在于：你得同时控制好三件事——构建阶段的依赖完整性、运行阶段的最小化、以及用户权限与缓存路径的一致性。少盯住其中任何一个，镜像就悄悄胖起来，而且胖得还查不出原因。
