composer install严格按composer.lock安装确定版本，确保环境一致；update则忽略lock、重算依赖并更新锁文件，仅用于开发阶段主动升级。
别背命令大全，先搞清 install 和 update 的区别——生产环境跑 composer update 等于主动制造故障。
什么时候必须用 composer install
CI/CD 流水线、线上部署、新同事拉代码后首次运行，都得用 composer install。它只读 composer.lock，装的是锁文件里写死的版本号，不解析 composer.json 里的约束符（比如 ^8.0），所以结果可预测、可复现。
常见错误现象：composer install 报错 “Your requirements could not be resolved”，大概率是本地 PHP 版本或扩展缺失，不是依赖冲突——install 不做版本决策，只照单执行。
- 首次运行
composer install时若无composer.lock，它会自动 fallback 到update并生成锁文件，这在团队协作中属于隐患，建议提前git commit一份由负责人生成的composer.lock - 如果 CI 脚本里写了
composer update，上线前就等于把版本控制权交给了 Packagist 的 CDN 延迟和网络抖动 - 想跳过某些平台要求（如 PHP 版本）强行安装？别用
--ignore-platform-reqs，那是临时调试手段，不能进脚本，也不能提交
composer update 只该在明确目的时运行
composer update 是重解析 composer.json、重新计算整个依赖树、更新 composer.lock 的操作。它不该是“日常更新”动作，而是“有目标的升级行为”。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
使用场景：本地开发想验证某包新版兼容性、修复已知安全漏洞、或需升级主框架（如 Laravel 从 10.x 升到 11.x）。
- 裸跑
composer update极易引入子依赖不兼容——比如只升guzzlehttp/guzzle，但它的子依赖psr/http-client还卡在旧版，导致运行时报错 - 只更新一个包？用
composer update monolog/monolog，加--with-dependencies可连带更新其直系依赖 - 升级后出问题？立刻
git checkout composer.lock && composer install，比查 changelog 快十倍
composer require 的参数选错，轻则白装，重则污染生产环境
composer require 不是“下载命令”，而是“声明 + 安装 + 锁定”三合一操作。参数选错，可能让开发工具进生产容器、或让类加载失效。
- 没加
--dev？phpunit/phpunit会被写进require字段，上线时也会被 autoload，徒增内存和启动开销 - 漏写版本约束符？
composer require guzzlehttp/guzzle:7.5等价于"guzzlehttp/guzzle": "7.5.0"，几乎匹配不到任何包；应写成^7.5或~7.5.0 - 只想改
composer.json但不安装？加--no-update，否则可能因当前 lock 文件与新依赖冲突而失败 - 临时绕过平台限制（如 PHP 8.3 环境装只声明支持 8.2 的包）？可用
--ignore-platform-reqs，但装完必须立刻删掉，且绝不能提交composer.lock
composer dump-autoload 不是可选项，是必要刷新动作
加了新类、改了 autoload 配置、或新增了 files 类型的全局函数文件，不跑 composer dump-autoload，PHP 就找不到这些类——这不是缓存问题，是 autoloader 映射根本没更新。
- 开发中频繁增删类？加
-o（即composer dump-autoload -o）生成 classmap，比默认 PSR-4 查找快，尤其适合 CLI 工具类项目 - 用了
"files"autoload（比如src/helpers.php），改了那个文件内容，也得重新 dump，否则不会重载 - 命名空间和目录结构对不上？先确认
composer.json里psr-4映射是否正确，再 dump，别一上来就怀疑自动加载机制
最常被忽略的复杂点：Composer 的行为高度依赖 composer.lock 是否存在、是否干净、是否被 git 跟踪。很多“装不上”“类找不到”“版本不对”的问题，根源不在命令本身，而在 lock 文件状态和团队协作流程是否统一。
