必须用官方脚本安装composer，因alpine 3.16+已移除该包；需显式启用phar/openssl/zlib扩展，并通过多阶段构建仅复制vendor和优化autoloader，同时全局配置阿里云镜像源。
别用 apk add composer，它在 Alpine 3.16+ 中必然失败，且装出来的版本不可信、不兼容现代 PHP。真正可行的路径只有一条：用官方安装脚本 + 显式补全依赖 + 多阶段构建隔离，三者缺一不可。
为什么 apk add composer 在 Alpine 3.16+ 一定失败
错误信息通常是 ERROR: unable to select packages，这不是网络或权限问题，而是 Alpine 官方从 3.16 起彻底移除了 composer 包。维护者明确将其归类为“PHP 应用层工具”，不再纳入系统包管理范畴。即使你临时启用 community 源，查到的也多是过时的 php7-composer 或根本不存在。更危险的是：若侥幸装上，composer --version 可能报 Class 'Phar' not found——因为默认 Alpine 镜像没启用 phar 扩展。
curl | php 安装前必须确保的三个扩展
官方安装脚本依赖 PHP 运行时能力，缺一不可：
-
php-phar：用于加载和执行.phar文件，否则composer.phar直接无法运行 -
php-openssl：校验 HTTPS 下载内容、验证包签名，缺失会导致composer install报SSL certificate problem -
php-zlib：解压 ZIP 包（Packagist 大部分包为 ZIP 格式），没有它会卡在failed to extract
在 Dockerfile 中应显式安装（注意 PHP 版本号对齐）：
apk add --no-cache php83-phar php83-openssl php83-zlib
验证是否生效：php -m | grep -E "^(phar|openssl|zlib)$" 必须有三行输出。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
多阶段构建中如何安全安装并剥离 Composer
目标不是“让容器里有 composer 命令”，而是“只把运行时需要的东西复制进去”。builder 阶段负责安装与构建，runtime 阶段只保留代码和 vendor/。
- builder 阶段用
php:8.3-cli-alpine（含完整 CLI 工具链），而非alpine:latest自建 PHP - 安装前先跑：
apk add --no-cache git unzip curl；安装完立刻删：apk del --purge git unzip curl -
composer install必须加三个参数：--no-dev --optimize-autoloader --no-interaction - 最终镜像禁止保留
composer.json、composer.lock和/root/.composer缓存目录
典型复制逻辑：
COPY --from=builder /app/vendor /app/vendor<br>COPY --from=builder /app/src /app/src
换源不是可选项，是解决 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 install 仍会尝试走境外源，哪怕你本地 curl 能通。
最易被忽略的点：所有 apk add 必须带 --no-cache，否则 /var/cache/apk/ 会被计入镜像体积——这个目录在 Docker 层中不会因后续 rm -rf 而消失。
