Composer install报错主因是前后端依赖对同一底层包（如symfony/console、php版本）提出互斥约束，须用composer why-not倒序定位根因、composer show --tree + grep验证实际版本、--with-dependencies精准更新，并协同platform配置与Node/PHP引擎要求。
前端构建工具（如 Laravel Mix、Vite）和后端框架（如 Laravel、Symfony）共存时，composer install 报错不是因为“前后端不该一起装”，而是它们对同一底层依赖（比如 symfony/console、psr/log、php 版本）提出了互斥约束——必须按依赖图本身来拆解，不能靠删锁文件硬刷。
composer why-not 要倒着读，从最后一行开始看谁在封杀
报错里写 Conclusion: don't install laravel/framework:v10.45.0？别猜。立刻跑：
composer why-not laravel/framework:v10.45.0
输出类似：
myapp/myproject dev-main requires phpunit/phpunit ^9.6 phpunit/phpunit ^9.6 requires sebastian/exporter ^4.0 sebastian/exporter ^4.0 conflicts with symfony/console ^6.0 laravel/framework v10.45.0 requires symfony/console ^6.2
注意：必须从最后一行（laravel/framework v10.45.0 requires symfony/console ^6.2）往回推，才能定位到真正卡住的点是 sebastian/exporter ^4.0 和 symfony/console ^6.2 无交集。中间那几行只是传递路径，不是根因。
立即学习“前端免费学习笔记（深入）”；
-
composer why-not查的是“你想装但装不了”的包；如果它输出空或nothing，说明该版本压根没发布，不是冲突 - 前端工具链常藏在
require-dev里（比如vite-php-plugin），但它参与全量解析，不能忽略 - 某些包在自己的
composer.json里写了"conflict": {"symfony/console": ">=6.0"}，哪怕你没直接 require 它，只要被拉进来就会触发全局拦截
composer show --tree + grep 快速定位实际装了什么版本
别只盯着 composer.json 里写的 ^5.4，最终生效的是 composer.lock 里锁定的版本。用这两条命令交叉验证：
前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。前端设计与 UI/UX 全方位优化专家。覆盖视觉层次、排版系统、色彩理论、响应式布局、交互体验、动画动效、无障碍访问、性能优化八大维度，帮助开发者将普通页面升级为高品质产品级界面。
composer show symfony/console
看输出里的 versions 和 requires 列表；再跑：
composer show --tree | grep -A5 -B5 "symfony/console"
就能一眼看到是哪个包（比如 phpunit/phpunit 或 laravel/pint）把 symfony/console 拉成了 v5.4.37，而你要升的后端框架要求 v6.2.14。
-
composer show --tree输出极长，加grep是刚需，否则人工扫容易漏掉嵌套三层以上的依赖 - 前端构建脚本里如果用了
laravel-mix，它内部依赖webpack-cli→find-up→locate-path→psl，这条链可能意外锁死某个 PSR 包版本 - 运行时类找不到（如
Class 'Symfony\Component\Console\Command\Command' not found）往往是因为symfony/console实际装的是 v5，但代码调用了 v6 的新 API
定点更新要带 --with-dependencies，不带就等于没写
想让 laravel/framework 升到 v10.45.0，但又不想连带把 phpunit 从 v9 升到 v10（它会要求 PHP 8.2+）？执行：
composer update laravel/framework --with-dependencies
这个命令会让 Composer 只重算 laravel/framework 及其直系依赖（比如 symfony/http-kernel、illuminate/support），而跳过 phpunit/phpunit 这类无关项。如果不加 --with-dependencies，Composer 常直接拒绝，报 Could not resolve dependencies。
- 包名必须写全且不带引号、不带
^或~，例如composer update laravel/framework --with-dependencies合法，composer update "laravel/framework:^10"会失败 - 升级后立刻
git diff composer.lock，确认只有laravel/framework和它明确依赖的几个包被改——多动一个symfony/polyfill-ctype都可能引发线上环境 autoload 失败 - 如果
--with-dependencies仍失败，说明它的子依赖里还有硬冲突，此时要对新暴露出来的包再跑一次composer why-not
前端工具链升级要同步检查 platform 配置
很多冲突其实不是语义化版本问题，而是 composer.json 里 "config": {"platform": {"php": "8.1.0"}} 写死了 PHP 版本，但前端构建工具（比如最新版 vite-php-plugin）要求 php >=8.2。这时 composer update 会卡在 Resolving dependencies，不是算不出来，是根本不敢选满足条件的版本。
- 先运行
php -v确认本地 PHP 实际版本，再比对composer.json中config.platform.php是否一致 - 前端工具若用到了 Node.js 生态（如
laravel-mix），它的package.json里engines.node和 Composer 的platform.php必须协同——比如 Node 18 要求 PHP 8.1+，否则mix build可能成功但composer install失败 - 团队协作中，有人提交了新
composer.json但漏提composer.lock，会导致Root requires laravel/framework:v10.45.0 but v10.38.0 is installed—— 此时应git checkout -- composer.lock恢复，而不是删锁重装
最易被忽略的是：前端构建插件（如 vite-php-plugin）和后端框架（如 laravel/framework）都依赖 psr/container，但一个要求 ^1.1，另一个要求 ^2.0，这种 PSR 主版本冲突不会报明显错误，却会导致容器绑定失败，调试时得翻到运行时日志才看得见。
