不能在容器启动时执行 composer install，因PHP扩展缺失或版本不一致会导致失败或装入不兼容包；应于Dockerfile构建阶段安装，并用多阶段构建复用vendor，同时通过config.platform.php锁定PHP版本确保环境一致。

为什么不能在 Docker 容器里直接 composer install？

因为容器启动时 PHP 扩展、扩展版本、ext-zip 或 ext-opcache 缺失，composer install 会失败或装出不兼容的包。更常见的是：宿主机和容器内 php -v 或 php --ini 输出不同，导致 composer.lock 生成环境与运行环境不一致。

实操建议：

• 永远在构建镜像阶段执行 composer install，而不是在 docker run 时临时执行
• 确保 Dockerfile 中安装了所有 composer 运行依赖（如 unzip、git）和 PHP 扩展（ext-zip、ext-xml、ext-mbstring）
• 用 --no-dev --optimize-autoloader --classmap-authoritative 参数，避免把开发依赖打进生产镜像

composer install 报错 “Could not open input file: composer.phar” 怎么办？

这是最常被忽略的路径问题：你没把 composer 可执行文件放进 $PATH，或者用了错误的安装方式（比如只下载了 composer.phar 却没设为可执行或没软链）。

实操建议：

• 在 Dockerfile 中用官方推荐方式安装：
  

  curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer

• 检查是否真能执行：composer --version 必须在 RUN 阶段就成功返回
• 别用 php composer.phar install —— 容器里没 php 命令或路径不对时，这行命令比 composer install 更容易静默失败

如何让 vendor/ 不进镜像又不影响运行？

不能靠 .dockerignore 忽略 vendor/ 后再 composer install —— 那样构建时根本没 vendor/，PHP 一启动就报 Class not found。真正的解法是分层构建 + 复用已安装的 vendor。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

实操建议：

• 用多阶段构建：第一阶段用完整 PHP 环境跑 composer install，把 vendor/ 复制到第二阶段精简镜像中
• 别挂载 vendor/ 作为 volume —— 宿主机和容器 PHP 版本稍有差异，opcache 或 apcu 就可能拒绝加载缓存后的类
• 如果必须热重载代码（比如本地开发），用 bind mount 整个项目目录，但明确排除 vendor/ 和 composer.lock，防止覆盖容器内已安装的依赖

PHP 版本不一致导致 composer install 成功但运行时报错

典型现象：composer install 在 PHP 8.2 下通过，但容器用 PHP 8.1 启动时抛出 ParseError: syntax error, unexpected token "readonly" —— 因为 composer.lock 记录的是 8.2 兼容的包版本，而某些包的高版本已弃用 8.1。

实操建议：

• 在 composer.json 的 config.platform.php 显式声明目标 PHP 版本：
  

  "config": { "platform": { "php": "8.1.28" } }

• CI/CD 流水线里，用和容器完全一致的 PHP 版本生成 composer.lock，而不是开发者本地的版本
• 检查 composer show --platform 输出，确认它和容器内 php -v 一致；否则 composer install 会悄悄降级或跳过某些约束

最麻烦的不是命令写不对，而是 composer.lock 生成环境和容器 PHP 环境之间那半个小版本的偏差——它不会报错，只会等你上线后某个凌晨三点抛出一个找不到的类。