升级卡在“your requirements could not be resolved”时，应先运行composer why-not laravel/framework:^11.0定位冲突源，倒序分析拒绝链，区分conflict声明、硬绑定依赖或版本未发布；require-dev中过时包常引发隐性锁死，需临时注释并验证；升级后必须检查composer.lock改动范围，避免非必要依赖被动更新；遇强conflict应查packagist替代方案，慎用replace绕过。
框架升级卡在 Your requirements could not be resolved，不是版本写错了，是旧生态包用 conflict 或硬绑低版本把路堵死了——得先揪出谁在封杀，再决定是升、换还是绕。
composer why-not 是你升级时第一个该敲的命令
报错里只写 Conclusion: don't install laravel/framework:^11.0，但没说谁不让装。这时候别改 composer.json，先问 Composer：composer why-not laravel/framework:^11.0。它输出的是拒绝链，不是因果图，必须从最后一行（通常是你的根项目）倒着读。
- 如果某行末尾带
(conflict with foo/bar >=2.0)，说明foo/bar自己声明了conflict字段，Composer 是照章执行 - 如果输出里出现
orchestra/testbench:^7.0或phpunit/phpunit:^9.0，大概率是它们内部硬绑了 Laravel 9/10，和你要升的 L11 冲突 - 输出为空？说明你要升的版本压根没发布过，不是冲突，是版本不存在
require-dev 是框架升级最常翻车的地方
主项目已切到 laravel/framework:^11.0，但 require-dev 里还留着 orchestra/testbench:^7.0 或 laravel/pint:^1.0 —— 这些包往往没跟上主框架节奏，会悄悄把 symfony/console、illuminate/support 等关键包锁死在旧版。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
composer why symfony/console，确认是否被require-dev中的某个工具拉进来 - 临时注释掉
require-dev下非必需的包，再跑composer update --dry-run验证是否能过 - 别信 “只是开发用，不影响生产”——Composer 解析时不管 dev 还是 prod，所有约束一视同仁
升级后立刻检查 composer.lock 的改动范围
用 composer update laravel/framework --with-dependencies 升级框架，不是为了“强制装上”，而是让 Composer 在最小影响范围内重算它的直系依赖。升级完不看 composer.lock 就提交，等于埋雷。
- 执行
git diff composer.lock，确认只有laravel/framework及其明确依赖（如illuminate/xxx、symfony/xxx）被改动 - 如果发现
monolog/monolog、guzzlehttp/guzzle或phpunit/phpunit也被动更新了，说明--with-dependencies拉得太宽，得回退并手动指定子依赖范围 - 若
composer.lock里出现大量replace或provide声明，要警惕是否有人为干预过依赖图，这类修改极难追踪
遇到 conflict 字段强互斥，别硬顶，先查 Packagist 替代方案
有些包在 composer.json 里写了 "conflict": {"laravel/framework": ">=11.0"}，这不是 bug，是作者明确放弃支持。这时候加 --with-all-dependencies 强升，只会把 symfony/http-foundation 之类的基础包也拖进不兼容状态。
- 去 Packagist 搜原包名，看有没有官方标注的替代品（比如
foo/bar→newvendor/baz） - 用
composer show foo/bar查它最后更新时间，如果超过 12 个月没维护，优先考虑替换而非适配 - 真要临时绕过，可用
replace字段声明：“我自行保证兼容”，但仅限调试环境，且必须同步在代码里做运行时校验
框架升级最难的不是命令怎么敲，是判断哪个包该升、哪个该换、哪个该删——composer why-not 输出的每一行，都是决策依据，漏掉任何一行，都可能让升级停在第二天早上。
