composer install --dry-run 不存在，官方从未支持，直接使用会报“Unrecognized option”错误；真正支持该参数的是 composer update 和 composer require（2.2+ 稳定支持）。
composer install 时怎么预览但不真正安装？
直接用 --dry-run 参数就行。它会让 Composer 解析依赖、计算操作步骤，但跳过所有文件写入和脚本执行。这是验证变更安全性的最常用手段，尤其在 CI/CD 或生产环境部署前。
-
composer install --dry-run只对composer.lock已存在的情况生效；如果 lock 文件缺失，它会先生成 lock 再模拟，但不会写入磁盘 - 输出里出现
Installing vendor/package (1.2.3)并不表示真的装了——这只是模拟日志，实际vendor/目录内容完全不变 - 若依赖冲突或平台要求不满足（比如 PHP 版本太低），
--dry-run仍会报错，这点和真实执行一致
composer update 怎么做“只看不动”？
composer update --dry-run 是等效方案，但它更敏感：只要 composer.json 有变动（哪怕只是调整了 require-dev），就会触发依赖树重算，并列出所有将被升级/降级/移除的包。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 默认只模拟 root 包声明的依赖；加
--with-all-dependencies才会递归模拟整个依赖图变化 - 如果用了
platform配置（如"php": "8.1"），--dry-run会严格按该配置校验兼容性，避免本地 PHP 版本误导判断 - 注意：某些插件（如
hirak/prestissimo）可能绕过 dry-run 机制，建议临时禁用再测试
为什么 --dry-run 有时不输出任何内容？
常见于两种情况：一是当前 vendor/ 已完全匹配 composer.lock，Composer 认为无需任何操作；二是你运行的是 composer require xxx --dry-run，但该命令本身不支持 --dry-run 参数（会静默忽略）。
- 确认是否真有变更：用
git status看composer.lock是否已修改，或手动删掉vendor/后再试composer install --dry-run -
composer require和composer remove不支持--dry-run，必须改用composer update --dry-run vendor/package来模拟单包变更 - 输出为空时别误以为“没问题”，应结合
composer show --outdated和锁文件 diff 综合判断
CI 中用 --dry-run 要注意什么？
CI 环境常因缓存或权限问题导致行为偏差，--dry-run 的结果未必代表本地或生产环境的真实表现。
- 确保 CI 使用的 PHP 版本、扩展（如
mbstring、json）与目标环境一致，否则依赖解析可能不同 - 不要依赖
--dry-run的退出码判断“是否有变更”——它成功时返回 0，但无操作也返回 0；需解析 stdout 或检查 lock 文件 diff - 如果项目启用了
config.platform，CI 必须显式设置相同值，否则平台检测失效，dry-run 失去意义
