根本原因是Docker分层缓存机制导致vendor重建，解决方法包括：提前复制composer.lock、配置国内镜像源、多阶段构建、对齐PHP平台版本、避免挂载冲突及禁用无效插件。
为什么composer install在Docker里总慢得像卡住？
根本原因不是网络差，而是Docker默认的分层缓存机制让composer.lock变更后，整个vendor/目录重建——哪怕只改了一行依赖版本。更糟的是，如果composer install写在RUN指令里且没做缓存优化，每次build都会重装全部包。
实操建议：
- 把
composer.json和composer.lock先复制进镜像，再运行composer install --no-dev --prefer-dist --optimize-autoloader，这样Docker能复用前一次的依赖层 - 避免在
WORKDIR里直接git clone项目后再composer install——这会让所有依赖安装步骤无法被缓存 - 国内环境务必配置国内镜像源，例如在
Dockerfile中加：RUN composer config -g repo.packagist https://packagist.phpcomposer.com（注意：该镜像已停用，应换为https://mirrors.aliyun.com/composer/）
composer install报错“Your requirements could not be resolved”怎么办？
这通常发生在Docker构建时PHP版本或扩展与composer.lock记录的环境不一致。比如本地开发用PHP 8.2，但Docker里用的是PHP 7.4，而某个包在composer.lock里锁定了仅支持8.0+的版本。
实操建议：
- 检查
composer.lock顶部的platform字段，确认它是否显式声明了PHP和扩展版本；若没有，构建前先运行composer update --lock并提交更新后的composer.lock - 在Docker中强制对齐平台信息：
composer install --ignore-platform-reqs只是临时绕过，不推荐用于生产；正确做法是在Dockerfile中提前装好ext-pdo、ext-json等composer.json里声明的必需扩展 - 用
php -m和php -v在容器内验证实际环境，别只信基础镜像名（比如php:8.1-cli不一定自带gd或mbstring）
如何让vendor/不打进最终镜像又不影响运行？
多阶段构建是唯一靠谱解法。很多教程教你在final阶段COPY --from=builder /app/vendor /app/vendor，但漏掉一个关键点：必须确保builder阶段的PHP版本、扩展、composer版本与运行阶段完全一致，否则autoload可能失败或扩展类找不到。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
实操建议：
- 两个阶段使用同一个基础镜像标签，例如都用
php:8.1-cli，不要builder用php:8.1-cli、final用php:8.1-apache——后者可能缺zip扩展，导致某些包的autoloader生成异常 -
builder阶段安装完依赖后，执行composer dump-autoload --optimize，减少运行时解析开销 - 如果应用用到
bin/下可执行脚本（如phpunit、laravel），记得在builder阶段一并COPY进final镜像，否则vendor/bin路径会不存在
Docker Compose里composer install权限被拒或写入失败？
常见于挂载宿主机代码目录（volumes）后，在容器里运行composer install，结果提示Permission denied写vendor/或composer.lock。本质是宿主机用户UID和容器内用户UID不匹配，Linux文件系统认UID不认用户名。
实操建议：
- 不要在
docker-compose.yml的command里直接跑composer install——这会让每次up都重装，且权限问题更难调试 - 改用一次性容器执行安装：
docker run --rm -v $(pwd):/app -w /app php:8.1-cli composer install --no-dev，并在命令前用id -u动态传入UID：docker run --rm -u $(id -u):$(id -g) -v $(pwd):/app -w /app php:8.1-cli composer install - 如果必须在
compose中初始化，用init容器或entrypoint脚本判断vendor/autoload.php是否存在，不存在才运行composer install，并确保脚本以当前挂载用户的UID运行
最易被忽略的一点：Composer插件（如hirak/prestissimo）在Docker里基本无效，因为它的并行下载优势会被镜像层缓存策略覆盖；而composer-plugin-api版本不兼容还会导致静默失败——建议直接禁用插件，靠--prefer-dist和镜像源提速更稳。
