composer install严格按composer.lock安装确切版本，确保环境一致；composer update忽略lock文件，重新解析composer.json并更新依赖及lock文件，仅用于开发阶段主动升级。
别记命令缩写，先搞清 install 和 update 的语义边界——用错一个，线上就可能挂。
composer install 和 composer update 什么时候该用哪个
不是手快慢的问题，是环境是否可控的问题。
-
composer install只读composer.lock，装里面记录的**确切版本号**，适合 CI/CD、生产部署、新同事拉代码后启动项目 -
composer update忽略composer.lock，按composer.json重新解析依赖树，会改composer.lock——只应在本地调试兼容性、升级主包或验证安全补丁时运行 - 首次执行
composer install时若无composer.lock，它会自动 fallback 到update并生成锁文件，这等于绕过团队约定；建议初始化后立即git add composer.lock - CI 脚本里出现
composer update，等于把构建结果交给网络延迟和上游包发布时间，凌晨告警大概率由此而来
加依赖必须用 composer require，但参数选错等于埋雷
手写 composer.json 再 install 是低效且易出错的路径。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 开发工具类（如
phpunit/phpunit、phpstan/phpstan）必须加--dev，否则进require区，上线也会加载 - 指定版本要带约束符：
composer require guzzlehttp/guzzle:^7.5（推荐），而不是7.5（会被解释为严格等于 7.5.0，基本匹配不到） - 只想改
composer.json不安装？加--no-update，比如composer require symfony/console --no-update，后续可单独composer update symfony/console - 遇到
Your requirements could not be resolved且确认是 PHP 版本限制（如本地 PHP 8.3，但包声明只支持 8.2），可临时加--ignore-platform-reqs强装——但别提交，CI 禁用
autoload 不生效？先跑 composer dump-autoload
90% 的 Class not found 报错，不是命名空间或路径错了，而是 autoloader 没刷新。
- Composer 不监听文件增删，新增 PSR-4 目录、改了
autoload配置、或加了files类型的全局函数文件，都必须手动运行composer dump-autoload - 开发中频繁加类又不想每次
update，加-o生成 classmap：composer dump-autoload -o，比默认 PSR-4 查找更快 - 用了
filesautoload（比如src/functions.php），改了那个文件也得重dump，否则不会生效
composer global require 装的命令为什么找不到
不是没装上，是 shell 找不到它的可执行文件位置。
-
composer global require laravel/installer装的是全局工具，但它不等于系统级命令——它依赖 Composer 自己管理的 bin 目录是否在$PATH里 - 查路径：
composer global config bin-dir --absolute，然后确认该路径已加入$PATH - Mac/Linux 常见路径是
~/.composer/vendor/bin，Windows 是%USERPROFILE%\AppData\Roaming\Composer\vendor\bin - 装完记得新开终端，或执行
source ~/.zshrc（或对应 shell 配置）让$PATH生效
最常被忽略的其实是 composer.lock 的生命周期管理：它不是生成一次就一劳永逸的文件，每次 update 后必须提交，每次 install 前必须确保它存在且最新——否则协作和部署就失去了确定性基础。
