composer依赖解析失败时应先用composer update --dry-run定位冲突，避免直接删lock文件；需精确指定版本或用as伪版本、--with-all-dependencies等安全方式解决，而非盲目忽略约束。
composer install 时提示 “Your requirements could not be resolved” 怎么办
这是最常见场景：你改了 composer.json 里的某个包版本（比如写成 "monolog/monolog": "^2.0"），但当前 lock 文件锁的是 ^1.25，或者项目里已有其他依赖间接要求旧版——Composer 默认不会“覆盖已满足的约束”，而是卡在依赖解析失败。
实操建议：
- 先运行
composer update --dry-run看具体哪个包冲突，别直接硬上 - 如果只是想跳过某一个包的版本检查（比如临时绕过不兼容警告），用
composer update vendor/package-name --with-all-dependencies比全局 update 更安全 - 不要删
composer.lock后重装——这会连带升级所有包，可能引入未知 break change - 真正需要忽略某条约束时，不是靠“忽略”，而是显式指定你要的版本：
"vendor/package": "2.9.0 as 1.99.99"（用as伪版本欺骗依赖方）
composer require 强制安装不兼容版本的包
当你明确知道某个新版包能跑通（比如测试过），但 Composer 死活拦着，报 Conclusion: don't install vendor/package v3.2.0，说明它的依赖树里有别的包声明了 "vendor/package": "^2.0" 这类硬约束。
实操建议：
- 优先查这个包是否提供
replace或conflict声明——有些包会在composer.json里写"conflict": {"vendor/old-package": "*"}，删掉它再试 - 用
composer require vendor/package:dev-main --ignore-platform-reqs可跳过 PHP 版本、扩展等检查，但仅限开发环境临时验证 -
--ignore-platform-reqs不解决依赖冲突，只绕过环境限制；真要破依赖锁，得配合--with-all-dependencies或手动改composer.json - 注意：
dev-main这类开发分支默认被minimum-stability拦住，需在根composer.json加"minimum-stability": "dev"并设"prefer-stable": true来平衡
为什么 composer update 不按我写的版本号装
你写了 "symfony/console": "5.4.36"，结果装了 5.4.35，甚至 6.3.0——这不是 bug，是 Composer 的版本选择逻辑在起作用：它优先满足所有依赖的“最大公共交集”，而不是字面匹配。
实操建议：
- 确认你写的是精确版本（
"5.4.36"）还是波浪号（"~5.4.0"）或插入符（"^5.4"），后者都会允许小版本升 - 运行
composer show symfony/console看实际可用版本列表，再用composer depends symfony/console查谁在拉高要求 - 想锁死到某次 commit？用
"symfony/console": "dev-main#abc1234"，但要注意这种写法不会触发自动更新 - CI/CD 中建议固定
composer.lock并用composer install --no-dev，避免本地update误污染
composer install 跳过某些包的安装（比如只装 runtime 不装 dev）
不是所有场景都需要装 phpunit 或 infection 这类开发依赖，尤其在生产部署时。但很多人误以为删掉 require-dev 就行，其实 Composer 默认仍会读取并尝试满足它们。
实操建议：
- 部署时加
--no-dev参数：composer install --no-dev --optimize-autoloader，这才是标准做法 - 如果某个包既在
require又在require-dev（比如doctrine/annotations），删require-dev条目才能彻底排除 -
--ignore-platform-reqs和--no-dev可共存，但前者风险高，后者是常规操作 - 注意：某些包通过
autoload-dev注入测试辅助类，删 dev 后如果单元测试跑不了，不是 Composer 的问题，是代码本身耦合了 dev 逻辑
版本约束不是开关，是契约。强行绕过往往意味着你还没看清依赖之间真实的调用链和语义边界。最省事的“强制安装”，常常是下一次故障的起点。
