生产环境部署 composer 依赖必须用 composer install --no-dev --optimize-autoloader，禁用 dev 包防冲突、优化 autoloader 提升性能，并确保 lock 文件与代码一致、php 扩展齐全、权限正确。
生产环境部署 Composer 依赖，composer install --no-dev 不是“推荐做法”，而是唯一安全起点。跳过 require-dev 里的包，不是为了省几MB磁盘，而是避免 Class Mockery\Adapter\Phpunit\MockeryTestCase not found 这类运行时错误——它根本不是类没加载，而是测试框架被意外引入后，与生产 autoloader 冲突导致的假性缺失。
为什么不能用 composer update 上线
它会重写 composer.lock，且没有原子回滚机制。一旦更新中途失败（网络抖动、权限不足、PHP 扩展缺失），lock 文件已损坏，vendor/ 处于半安装状态，服务直接不可用。
- CI/CD 流水线里必须把
composer update限制在开发分支或本地，上线只跑composer install -
composer.lock必须随代码一起提交，且和你本地composer install成功后的版本完全一致；否则线上 install 会降级或升级包，破坏可重现性 - 若发现
composer.json和lock不匹配（比如改了name或version字段但没重生成 lock），先在本地composer update --lock（或composer update nothing）修复再推
--optimize-autoloader 不是可选项，是生产必需
不加这个参数，每次请求都得扫描文件系统找类，autoload 性能下降明显。尤其在 Laravel、Symfony 等框架中，类数量多、命名空间深，未优化的 autoloader 会让首字节时间（TTFB）增加 20–50ms。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 它生成
vendor/composer/autoload_classmap.php，把所有类名到文件路径的映射静态固化 - 搭配
--classmap-authoritative更进一步：告诉 autoloader “不在 classmap 里的类就真的不存在”，彻底跳过 PSR-4/PSR-0 的目录遍历 - 注意：
--classmap-authoritative要求所有类都必须能被自动发现（比如不能有运行时动态拼接类名再class_exists()的逻辑），否则会报错
权限、扩展、缓存三个坑最常导致部署卡死
报错不是“网络超时”或“源不可达”，而是底层条件不满足：
-
PHP 扩展缺失：常见卡在
Loading composer repositories with package information，实际是 CLI 模式下ext-zip、ext-openssl、ext-mbstring没启用。查配置：php -i | grep "Loaded Configuration File"，确认对应.ini文件里extension=zip.so等已取消注释；Ubuntu 还要装系统包：apt install php-zip php-xml php-mbstring -
权限混乱：部署用户（如
deploy）和 Web 用户（如www-data）不一致时，vendor/下文件可能被 PHP 进程拒绝读取，报failed to open stream: Permission denied。正确做法是用 Web 用户执行安装：sudo -u www-data composer install --no-dev --optimize-autoloader -
缓存误用：CI 阶段不要缓存
~/.composer/cache并拷到生产机——路径硬编码 + 符号链接平台差异会导致vendor/内部损坏。应缓存整个vendor/目录（--prefer-dist模式下更稳定），或干脆跳过缓存，用--no-cache强制干净安装
真正难的不是命令怎么写，而是部署前是否验证了 PHP CLI 的扩展、权限模型、以及 composer.lock 和代码的版本对齐——这三个点一漏，composer install 就从自动化流程退化成手动救火现场。
