Alpine 上直接 apk add composer 是个坑，因其包长期滞后、PHP 版本不匹配导致静默失败或 autoloader 错误，且 root 权限引发 vendor 目录权限问题。
为什么 Alpine 上直接 apk add composer 是个坑
Alpine 的 composer 包长期滞后、不更新，且依赖的 PHP 版本常与你用的 php:8.2-fpm-alpine 不一致——比如你镜像里是 PHP 8.2，但 apk 装的 composer 却跑在 PHP 7.4 环境下，composer install 会静默失败或生成错误 autoloader。更糟的是，它默认以 root 运行，挂载宿主机代码后，vendor/ 目录权限错乱，PHP 进程根本读不了。
正确做法：用官方 composer 镜像做多阶段构建
别在运行镜像里装 Composer，而是在构建阶段用 composer:2.7.7（带 PHP 8.2）这种预校验过的镜像，专注装依赖。它内置 json、mbstring、phar，UID 默认为 1001，和多数 Alpine PHP 镜像用户一致，天然避权。
- 第一阶段：
FROM composer:2.7.7 AS vendor，COPY composer.json composer.lock ./，再RUN composer install --no-dev --optimize-autoloader - 第二阶段：
FROM php:8.2-fpm-alpine，COPY --from=vendor /app/vendor ./vendor - 不要复制
composer.phar或/root/.composer到最终镜像——它们既不安全也不必要
如果非得在 Alpine 容器里临时用 Composer（如调试）
那就跳过 apk，用 PHP 自身下载验证安装，确保版本可控、路径干净：
RUN php -r "copy('https://getcomposer.org/installer', 'composer-setup.php');" \
&& php -r "if (hash_file('sha384', 'composer-setup.php') === '55ce33d7678c5a611085589f1f3ddf8b3c52d662cd01d4ba75c0ee0459970c2200a51f492d557530c71c15d8dba01eae' ) { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;" \
&& php composer-setup.php --install-dir=/usr/local/bin --filename=composer \
&& rm composer-setup.php
注意：必须核对官网当前 SHA384 值（上例为 2.7.7 版），不能省略校验；--install-dir 设为 /usr/local/bin 才能全局调用；装完立刻删掉 composer-setup.php。
挂载代码进容器时权限怎么不崩
常见报错：file_put_contents(/app/vendor/autoload.php): failed to open stream: Permission denied。根源不是 Composer，而是宿主机目录属主是 root，挂进容器后 UID 1001 用户没写权。
- 开发时提前运行：
chown -R 1001:1001 ./（假设你用composer:2镜像，默认 UID 1001） - Docker for Mac 用
-v $(pwd):/app:delegated；Podman 用:z；别裸挂-v $(pwd):/app - 容器内执行命令加
--no-interaction --no-progress --optimize-autoloader，减少因 I/O 权限触发的中间失败
真正麻烦的从来不是“怎么装”，而是“谁在哪个目录下以什么身份写哪几个文件”——Alpine 小是小，但 UID/GID 和挂载语义比 Debian 更敏感，一步错，全盘 vendor 不可读。
