只有写成"guzzlehttp/guzzle": "7.5.0"（纯数字字符串，无符号）才算真正锁死版本；其他如"^7.5.0"等均为范围约束，会允许升级；改composer.json后须运行composer update guzzlehttp/guzzle或composer update --lock更新lock文件，再install才生效。
composer.json里怎么写才算真正锁死Guzzle版本
只有"guzzlehttp/guzzle": "7.5.0"这种不带任何符号的纯数字字符串，才是精确锁定。写成"^7.5.0"、"~7.5"、"7.5.*"甚至"7.5"都不行——这些全是范围约束，Composer 会按语义化规则自动升级到7.9.9甚至7.10.0（只要符合^7.5.0）。
常见错误：composer require guzzlehttp/guzzle:^7.5.0看似指定了 7.5.0，实际允许装到 7.9.9；要锁死，必须用composer require guzzlehttp/guzzle:7.5.0（冒号后不能有空格、不能加v前缀、不能用@或=）。
- 已存在包时，先加
--no-update再手动composer update guzzlehttp/guzzle，避免全量重算 -
require-dev里的包（如phpunit/phpunit）同样要写死，否则composer update仍会升级它 - 分支写法如
"dev-main"不是锁定，每次update都可能拉新提交；真要固定，得用"dev-main#abc1234"
改了composer.json为什么还是装错Guzzle版本
根本原因：你运行的是composer install，而它只认composer.lock里的记录，不看composer.json的新约束。改完composer.json后没更新lock文件，install就永远装旧版。
正确流程是：改完composer.json → 运行composer update guzzlehttp/guzzle（或composer update --lock）→ 再composer install生效。
-
composer update --lock不装新包，只根据当前composer.json和已安装vendor/重建composer.lock，确保二者逻辑自洽 - 如果
composer update --lock也失败，说明冲突在更底层，错误通常指向某个具体包（如guzzlehttp/psr7v2.6.0），此时才需回到composer why-not guzzlehttp/guzzle:7.5.0定位封杀链 -
composer validate不报错 ≠composer.lock正确；Git 合并冲突后手动修lock文件但未验证结构合法性，就可能导致install卡在解析阶段
如何安全升级Guzzle而不牵连其他依赖
直接composer update guzzlehttp/guzzle只解析这个包及其子依赖，其余包版本完全不动。但要注意：如果目标包的新版本要求更高版本的psr/http-client，该依赖会被连带升级——这是正常行为；若想锁死，加--no-update-with-dependencies（Composer 2.5+）。
升级前务必先跑composer update guzzlehttp/guzzle --dry-run，看清楚哪些子依赖会被牵连（比如guzzlehttp/promises、guzzlehttp/psr7是否也在变动范围内）。
- 想升级到
7.5.0又不想波及symfony/polyfill，不能跑composer update，也不能写composer update "guzzlehttp/guzzle:^7"（引号 + ^会让 Composer 自己找最新兼容版，可能越界） - 正确命令是：
composer update guzzlehttp/guzzle --with-dependencies，表示只允许升级guzzlehttp/guzzle所需的最小依赖集（如psr/http-client），不会波及无关项 - 升级后立刻
git diff composer.lock，确认只有guzzlehttp/guzzle和它的直系依赖被改；多改一个symfony/polyfill-*都可能埋隐患
Laravel项目中Guzzle依赖冲突的典型破局点
报错如guzzlehttp/guzzle[7.4.0] requires guzzlehttp/promises ^1.5 but your lock file fixes it at 1.4.1，本质不是 Guzzle 本身问题，而是guzzlehttp/promises被其他包（比如测试工具或私有 SDK）锁死在旧版。
优先用composer why-not guzzlehttp/promises:^1.5查谁在封杀，而不是盲目删vendor或composer.lock——删了只会让下次install重新触发 SAT 求解器暴力遍历，大型项目可能卡在Resolving dependencies超过 5 分钟。
-
composer prohibits guzzlehttp/promises比depends更有效，它直接列出所有阻止该包安装的依赖及其约束条件 - 对 Laravel 项目，避免对
illuminate/*批量更新——它们内部强耦合，illuminate/support升级后illuminate/database若未同步，极易触发死锁 - 若冲突来自
require-dev里的phpunit/phpunit，考虑把它单独拆到composer.json的config.platform.php下隔离，或改用composer require --dev phpunit/phpunit:10.0 --with-all-dependencies强制协调
真正容易被忽略的点在于：锁文件不是“快照”，而是约束求解器输出的唯一可行解；一旦composer.json和composer.lock出现逻辑断层，哪怕只差一个小版本号，也会导致整个依赖图无法还原。所以每次改版本，都要同时确认json、lock、vendor/三者一致，缺一不可。
