答案是锁文件残留旧解析结果或子依赖绕过根约束所致。Composer 优先信任 composer.lock 中已解析版本，不每次重新校验约束；^8.0 装出 9.0 包说明 lock 文件中 version 字段已为 9.0.0，应删 lock 后重装，而非修改 composer.json。
版本约束失效通常不是 Composer 本身坏了，而是平台环境、锁文件残留或约束写法被意外覆盖导致的。直接改 composer.json 或硬删 composer.lock 很可能让问题更难回溯。
为什么 ^8.0 会装出 9.0 的包？
这几乎一定是 composer.lock 里存了旧版解析结果，或者你执行过 composer update 时没加 --with-all-dependencies，导致子依赖绕过了根约束。Composer 不会在每次 install 时重新校验所有约束，它优先信任 lock 文件里的已解析版本。
- 运行
composer show laravel/framework看当前实际安装版本，再对比composer.json里写的约束是否真匹配 - 检查
composer.lock中该包的version字段和source的reference，确认是不是手动 commit 过不一致的 lock - 如果 lock 文件里版本明显越界（比如写了
"version": "9.0.0"），直接删掉它再跑composer install—— 这比改约束更可靠
require 写对了但还是装错：常见拼写与作用域陷阱
Composer 解析约束时区分大小写、空格和引号位置，且某些字段会被插件或脚本动态覆盖。
-
"laravel/framework": "^8.0"有效，但"laravel/framework": "^8.0 "（末尾空格）会导致解析失败，降级为宽松匹配 - 在
require-dev里写的约束，对require里的同名包无影响；反过来也一样 - 如果项目用了
composer-plugin-api类插件（比如phpstan/extension-installer），它可能在 install 前重写require，需查插件文档
临时绕过约束的三种安全等级操作
按风险从低到高排列，只应在调试或 CI 中短时使用，不能进生产配置。
- 最低风险：
composer install --ignore-platform-req=php—— 只跳过 PHP 版本检查，不影响包版本选择逻辑 - 中等风险：
composer update --dry-run --with-all-dependencies先看它想装什么，再决定是否加--prefer-lowest或锁定具体版本 - 最高风险：
composer update vendor/package:1.2.3（不带^或~）—— 强制指定版本，但会忽略所有其他约束，包括conflict和replace声明
真正难处理的不是约束写错，而是 lock 文件和 vendor 目录状态不一致时，composer install 表面成功却加载了错误的 autoloader。这种情况下，vendor/autoload.php 可能引用了未实际安装的类路径。
