composer install --dry-run 可预览安装步骤而不执行，跳过下载解压等写入操作，不依赖现有 vendor，但无 lock 文件时仍会报错；composer update --dry-run 模拟更新并列出包变更，加 --with-all-dependencies 可深度更新；二者均不触发钩子、不校验扩展，预览锁文件差异建议用 composer update --no-install 配合 diff。
composer install 时如何预览实际操作而不真正执行
直接用 --dry-run 参数即可。它会跳过所有写入操作（如下载、解压、生成 autoload、修改 vendor/ 和 composer.lock），只打印将要做的步骤和依赖变化。
- 适用于检查
composer install在当前环境是否会导致意外升级或冲突 - 不依赖本地已有
vendor/，即使目录为空也能运行 - 不会读取已安装包的版本缓存，因此结果比
composer update --dry-run更贴近“从零安装”的真实行为 - 若项目没有
composer.lock，--dry-run仍会尝试解析composer.json并报错（如缺少平台配置），但不会生成 lock 文件
composer install --dry-run
composer update 怎么安全预览依赖变更
composer update --dry-run 是更常见的使用场景，尤其在 CI 或上线前确认更新影响。它会模拟整个依赖解析过程，并列出将被安装、更新、降级或移除的包。
- 默认只更新
composer.json中声明的顶层包及其子依赖，不强制刷新整个锁文件 - 加
--with-all-dependencies后，会递归更新所有间接依赖（即“深度更新”），此时--dry-run输出会显著变长 - 如果锁文件存在且未被修改，
--dry-run通常很快；若锁文件缺失或与composer.json不一致，Composer 会先做完整解析，耗时可能明显增加 - 注意：某些插件（如
hirak/prestissimo）在 dry-run 模式下可能不生效，但不影响输出逻辑
composer update --dry-run
composer update --dry-run --with-all-dependencies
为什么 --dry-run 有时不显示具体文件变动
--dry-run 不模拟文件系统操作，所以不会告诉你“将删除 vendor/foo/bar/src/Helper.php”，只告诉你“将卸载 foo/bar:1.2.3”。它不触发 installers（如 PHP library installer、WordPress plugin installer），也不生成 autoloader 映射。
- 无法预览
post-install-cmd或post-update-cmd脚本的实际执行效果 - 不会检查扩展依赖（如
ext-mbstring）是否满足——这些校验发生在真正安装时，dry-run 阶段只做约束解析 - 若
composer.json中定义了platform配置（如"php": "8.1.0"），dry-run 会按该版本解析兼容性，但不会验证本地 PHP 是否真为该版本
替代方案：用 --no-install 看锁文件差异
当需要对比 composer.lock 变更细节时，--dry-run 不够直观。更有效的方式是先生成新 lock 文件，再用 diff 工具查看：
- 运行
composer update --no-install：解析依赖并重写composer.lock，但跳过 vendor 写入 - 用
git diff composer.lock或diff -u composer.lock.old composer.lock查看精确的版本、哈希、require-dev 变化 - 这个组合比
--dry-run多出锁文件结构级信息，适合代码审查或自动化校验
composer update --no-install实际执行前，最易被忽略的是
--dry-run 对脚本钩子和平台扩展的“静默跳过”——它看起来很安全，但掩盖了真实环境中可能失败的关键环节。 
