composer install --dry-run 仅校验 composer.lock 是否可安全还原，不预览安装内容；它解析依赖、检查平台约束，但不下载、不写入、不执行脚本，成功表示锁文件合法且环境基本匹配。
composer install --dry-run 不是用来预览“要装什么”的，它只校验当前 composer.lock 是否能被安全还原——成功就说明 lock 文件合法、依赖可解、环境基本匹配；失败则暴露冲突或缺失条件。
composer install --dry-run 实际做了什么
它不下载包、不写 vendor/、不生成 autoload.php、不执行任何脚本（包括 post-install-cmd），但会完整走通依赖解析流程：读取 composer.json 和 composer.lock，检查 PHP 版本、扩展要求（ext-zip 等）、平台配置（config.platform.php），并模拟安装路径映射。若 composer.lock 存在且格式合法，它会尝试按锁文件精确还原依赖树。
常见现象是终端无输出或只打印 Nothing to install, update or remove——这不是卡住，而是它确认“按 lock 还原没问题”。只有当 vendor 缺失、lock 与 json 不一致、或平台约束不满足时，才会报错或列出差异。
- 它不访问 Packagist，除非
composer.lock丢失，此时会尝试临时解析，但结果不可靠 - 它不校验磁盘权限、网络连通性、vendor 目录是否可写——这些留到真实 install 才暴露
- 它不验证 autoload 规则是否冲突，比如两个包都声明
"psr-4": {"App\": "src/"}，这类问题要等composer dump-autoload才浮现
为什么不能用它看“升级后效果”
composer install --dry-run 完全不碰 composer.json 中的版本范围（如 "monolog/monolog": "^2.0"），它只忠于 composer.lock 记录的精确版本。想预览放宽约束或更新依赖带来的连锁反应，必须用 composer update --dry-run。
典型误用场景：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 改了
composer.json里某个包的版本号，跑install --dry-run却没反应 → 因为 lock 文件没变，它根本不重算 - 以为
install --dry-run能看出主版本跃迁风险 → 实际只显示“将安装 monolog/monolog:2.9.1”，不会提示“3.0.0 已发布且 BC break” - CI 中用它判断“是否有变更需构建” → 错，它返回 0 只代表 lock 可执行，不代表代码或依赖有更新
哪些错误它能提前暴露，哪些不能
它能快速捕获的硬性失败：
-
Your requirements could not be resolved：lock 文件中某包要求的 PHP 版本/扩展在当前环境不满足 -
Package foo is not available in a stable-enough version：minimum-stability 或 stability flags 导致锁中版本不可达 -
Root composer.json requires bar, it is not present：lock 文件引用了本地不存在的包（如私有仓库未配置）
但它完全不检查的几类问题：
- PHP 运行时扩展是否真能加载（例如
ext-igbinary已声明但未启用） - 自定义 repositories 的认证 token 是否有效（
--dry-run不发起实际 HTTP 请求） - 脚本钩子（如
post-install-cmd）调用的命令是否存在或权限是否足够 -
autoload配置是否导致类名冲突或路径不可达
上线前最该搭配的命令组合
单独用 composer install --dry-run 只是守门第一步。真正要覆盖风险，得配合：
- 先跑
composer update --dry-run -v --no-install：看依赖树重算后有哪些升降级，尤其注意→箭头右侧的版本 - 再跑
composer install --dry-run --no-progress：确认当前 lock 在目标环境能否干净还原 - 如果失败，立刻接
composer why-not <package>或composer prohibits <package>定位冲突源头 - 最后手动验证 autoloader：
composer dump-autoload -v（虽然没有--dry-run参数，但-v能暴露 PSR-4 映射问题）
最关键的细节是：它不读取运行时 PHP 版本，只认 config.platform.php 配置。开发机上 --dry-run 成功，不代表 PHP 8.1 的生产环境也能过——这个 gap 往往被忽略到部署那一刻才炸出来。
