直接运行composer update不加参数是事故起点，因其会丢弃composer.lock、重算整张依赖图，导致phpunit等开发依赖升至不兼容版本，测试挂掉甚至autoload失效。
Composer 本身不破坏代码，破坏代码的是你没意识到的间接依赖变更、模糊版本约束和未经验证的 composer update 操作。它只是忠实地执行了你写的 composer.json 和当前环境允许的版本组合——而这个组合，很可能在你没注意时悄悄变了。
为什么 composer update 不加参数就是事故起点
它会重算整个依赖图，连 phpunit/phpunit、symfony/var-dumper 这类开发依赖都可能升到不兼容版本，导致测试直接挂掉，甚至 vendor/autoload.php 加载失败。更危险的是，它会连带升级你根本没写进 composer.json 的间接依赖，比如 psr/http-message 从 v1.1 升到 v2.0，而你的中间件还硬调 MessageInterface::getProtocolVersion() —— 这个方法在 v2 里被删了，PHP 运行时才报错。
- 永远显式指定包名和版本：
composer update guzzlehttp/guzzle:^7.5.0 - 升级框架时别只写
laravel/framework，要带上配套：composer update laravel/framework illuminate/* - CI/CD 脚本里禁止出现无参数的
composer update，回滚成本远高于预防
composer outdated --direct 为什么必须加 --direct
不加的话，它会把所有传递依赖（比如 psr/log、symfony/polyfill-php81）全列出来，信息过载；加了才能聚焦你真正声明的依赖，快速识别主版本跳变（如 monolog/monolog 从 2.9.0 → 3.0.0），这类才是高风险点。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先跑
composer outdated --direct，再决定是否动composer update - 如果没输出，检查是否设了
"minimum-stability": "stable"，临时删掉再试一次 - 重点盯带
!标记的包——那是 composer 认为可升但未升的主版本，最容易踩坑
如何提前发现 psr/http-message 这类间接依赖的潜在破坏
它们不显式声明，composer outdated --direct 完全看不到；composer show psr/http-message 只显示当前装的版本，不是“有没有新版本”。真正有效的是组合命令查链路：
- 查谁引入了它：
composer depends psr/http-message - 查它本身是否允许升级：
composer show psr/http-message看 versions 列表和 type 字段 - 模拟升级影响：
composer update psr/http-message:^2.0 --dry-run，看会不会连带升级guzzlehttp/guzzle或触发冲突 - 打开
composer.lock搜psr/http-message，确认锁定的 version 字符串是否仍是1.1.0
生产环境为什么绝不能运行 composer update
它会擅自升级依赖、重写 composer.lock，破坏该文件作为“唯一权威依赖快照”的意义。一旦上线后执行，轻则接口报 Class not found，重则 composer.lock 被意外提交覆盖，团队环境彻底不一致。
- 生产部署只允许：
composer install --no-dev --optimize-autoloader - CI 构建阶段统一执行
composer install --no-interaction并缓存vendor/，部署包里只含vendor/和composer.lock - 用
COMPOSER_NO_INTERACTION和COMPOSER_DISABLE_XDEBUG防误操作
最常被忽略的其实是 composer.lock 文件本身的可信度——它可能被手改、被不同 Composer 版本生成、或因平台配置差异（如 PHP 小版本）导致实际安装行为偏移。每次重大更新前，先 composer validate 确认 lock 文件合法，比什么都实在。
