composer install 不报错但装不上是因为它只按 composer.lock 安装，不解析新依赖；真实冲突在无 lock 或 lock 过期时才暴露；用 composer require xxx –dry-run 可精准验证单个包兼容性。
composer install 为什么没报错但实际装不上
因为 composer install 默认只校验 composer.lock 里的依赖快照，不重新解析依赖树。哪怕你本地改过 composer.json，只要没删 lock 文件，它就照着旧的装——冲突可能被掩盖了。
- 真实冲突常出现在 CI 环境或新机器首次
composer install时，lock 文件不存在或过期 -
composer update才会触发完整依赖解析，但代价是可能升级一堆包，干扰验证目标 - 想纯检查冲突又不动现有环境？得绕过 lock 文件 + 禁用写入操作
composer update –dry-run 真正能干啥
composer update --dry-run 是目前最接近“检测冲突但不安装”的标准做法，但它不是魔法：它仍会读取 composer.json，生成新依赖图，尝试解决版本约束，最后在真正写文件前停下。
- ✅ 能暴露
Your requirements could not be resolved这类核心冲突错误 - ✅ 显示将要安装/升级哪些包（含版本号），方便人工核对是否符合预期
- ❌ 不模拟
install场景：它默认作用于全部包，无法指定只检查某一个新增包 - ❌ 不验证脚本（
post-install-cmd）或插件兼容性，那些问题得等真装完才浮现
怎么精准测试加了一个包会不会炸
如果你只是往 composer.json 里加了一行 "monolog/monolog": "^3.0"，想确认它和现有包不打架，别直接 update --dry-run 全局——太慢，噪音大。
- 用
composer require monolog/monolog:^3.0 --dry-run，它只解析新增依赖 + 当前 lock 的约束 - 加
--no-update参数可跳过自动更新 lock，避免意外修改（适合 PR 前快速验证） - 如果提示
Root package requires ... which is not present，说明该包本身缺失（比如私有源未配置），不是版本冲突 - 注意 PHP 版本约束：
--dry-run会检查config.platform.php，但不会读取你当前 CLI 的 PHP 版本，CI 上容易误判
常见假阳性与漏报场景
--dry-run 不是编译器，它依赖 Composer 自身的求解器逻辑，有些冲突它看不见，有些它又过度敏感。
- 平台包冲突（如
ext-gd）只在install阶段校验，--dry-run完全忽略——得靠composer check-platform-reqs - 私有仓库返回 401 或超时，
--dry-run可能卡住或报Could not parse version constraint，实际是网络问题 - 使用
path类型仓库时，--dry-run仍会尝试读取目标目录结构，若路径不存在，会报错而非跳过 - 某些插件（如
hirak/prestissimo）禁用后，--dry-run输出的包列表顺序可能和真实install不一致，但不影响冲突判断
真正难搞的是那种“看起来能装上、lock 也生成了、但运行时报 ClassNotFound”的情况——那通常不是依赖冲突，而是 autoloader 配置、PSR-4 映射或符号链接权限的问题。--dry-run 对这种无能为力。