Docker 构建中 composer install 失败的根本原因是网络、缓存与用户权限未对齐，常见表现为 packagist 连接超时或非 root 用户无法写入 vendor 目录。
Composer install 为什么在 Docker 构建时总失败
根本原因不是 Composer 本身有问题，而是构建阶段的网络、缓存和用户权限三者没对齐。最常见的是 composer install 卡在 https://repo.packagist.org 连接超时，或因非 root 用户运行导致 vendor/ 写入失败。
- 别在
Dockerfile里用curl -sS https://getcomposer.org/installer | php—— 官方镜像已预装，手动装反而容易版本错乱 - 构建时加
--no-interaction --optimize-autoloader --no-progress，避免交互阻塞和进度条干扰日志 - 若用多阶段构建，
composer install必须在 builder 阶段完成，且要COPY . /app后再执行，否则找不到composer.json - 国内环境务必配镜像源：在
RUN composer config -g repo.packagist composer https://packagist.phpcomposer.com（注意这是旧镜像，现推荐https://mirrors.aliyun.com/composer/）
vendor 目录该不该 COPY 进最终镜像
不该。把整个 vendor/ 打包进生产镜像，会显著增大体积、拖慢拉取速度，还可能混入 dev-only 依赖（比如 phpunit）。
- 正确做法是：builder 阶段执行
composer install --no-dev --optimize-autoloader，然后只COPY --from=builder /app/vendor /app/vendor - 如果项目用了
composer install --prefer-dist（默认），下载的是 zip 包，解压后无 .git 元数据；而--prefer-source会克隆仓库，导致镜像里残留大量 .git 文件，体积翻倍 - 注意
autoload.php路径是否硬编码了绝对路径——某些插件生成的 autoloader 会写死/var/www/html/vendor/autoload.php，但容器内路径可能是/app/vendor/autoload.php，运行时报Class not found
如何让 Composer 在容器内读取本地配置文件
容器默认不继承宿主机的 ~/.composer/auth.json 或 config.json，私有包认证、自定义 repo 就会失效。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 构建时用
BUILDKIT的 secret 功能最安全：RUN --mount=type=secret,id=composer-auth,target=/tmp/auth.json composer config --auth github-oauth.github.com xxx - 开发场景下可临时挂载：
docker run -v $(pwd)/.composer:/root/.composer php:8.2-cli composer install，但禁止用于生产 - 不要把
auth.json直接COPY进镜像——密钥会留在某一层，即使后续RUN rm也删不干净 - 若用 GitLab CI，通过
CI_JOB_TOKEN访问私有包，需在composer.json中显式声明："repositories": [{"type": "composer", "url": "https://gitlab.example.com/api/v4/groups/mygroup/-/composer"}]
PHP 版本不一致导致 Composer 报错 Class 'Composer\Xxx' not found
这不是 autoload 问题，而是 Composer 自身版本与 PHP 运行时不兼容。例如用 PHP 8.2 构建，却在 PHP 7.4 容器中运行 composer dump-autoload，就会因反射 API 差异崩溃。
- 检查
composer --version输出的最低 PHP 要求，和容器内php -v对齐；官方镜像标签如composer:2.5默认要求 PHP ≥ 7.2.5 - 不要在宿主机跑
composer update然后把composer.lock提交进去就完事——lock 文件里的platform字段可能锁定错误的 PHP 版本，需手动校验或用composer update --ignore-platform-reqs（仅限调试） - CI/CD 中建议统一用
composer self-update --2显式指定大版本，避免自动升级到 v3 后与旧项目不兼容
最麻烦的其实是 lock 文件里隐含的平台约束和插件兼容性，改一行 php 版本号，可能触发整条依赖链重算——这时候别硬扛，先 composer why-not php:8.2 看谁在卡脖子。
