间接依赖会突然破坏代码，因未显式声明而难以察觉其版本变更，如psr/http-message从v1.1升至v2.0导致方法删除，运行时才报错；需通过composer depends、show、--dry-run及锁死版本等手段主动管控。
为什么间接依赖会突然破坏你的代码？
因为你没直接写它，所以根本没注意它被更新了。比如你只写了 "guzzlehttp/guzzle": "^7.2"，但 guzzlehttp/guzzle 自己依赖的 psr/http-message 从 v1.1 升到 v2.0，而你的中间件硬调了 MessageInterface::getProtocolVersion()——这个方法在 v2 里被删了。Composer 不报错，PHP 运行时才炸。
常见错误现象：Fatal error: Interface 'Psr\Http\Message\MessageInterface' not found 或方法不存在、返回类型突变、构造函数参数顺序改了。这类问题往往在 CI 通过、本地测试也过，上线后第一个请求就挂。
- 间接依赖不显式声明，
composer outdated --direct完全看不到它 -
composer show psr/http-message显示的是当前装的版本，不是“有没有新版本” - 即使你锁死了主依赖版本，它的子依赖仍可能因其他包升级而被连带更新（比如另一个包要求
psr/http-message:^2）
怎么提前发现间接依赖的潜在破坏？
靠 composer show 和 composer depends 组合查链路，而不是等报错。先确认谁在用那个可疑包：
- 查谁引入了
psr/http-message：composer depends psr/http-message - 再查那个包本身是否允许升级：
composer show psr/http-message看versions列表和type字段（是library还是metapackage） - 模拟升级影响：
composer update psr/http-message:^2.0 --dry-run，看会不会连带升级guzzlehttp/guzzle或触发冲突
更关键的是检查 composer.lock：打开它，搜 "psr/http-message"，看它当前锁定的 commit hash 或 version 字符串。如果 lock 文件里是 "1.1.0"，但别人 composer update 后变成了 "2.0.0"，说明有人绕过了约束。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
如何阻止间接依赖被意外升级？
不能靠“不运行 composer update”，而要靠锁死+验证。最有效的三招：
- 在
composer.json中显式声明关键间接依赖："psr/http-message": "1.1.0"（不带符号），把它从“传递依赖”变成“直接依赖”，这样composer update就不敢动它 - 用
config.platform模拟目标环境，防止低版本 PHP 下误装高版本间接依赖："config": { "platform": { "php": "8.2" } } - CI 中加校验步骤：
composer show psr/http-message | grep -q '1\.1\.'，失败则中断构建——这比等 runtime error 实时抓 bug 强十倍
注意：replace 和 provide 在这里基本没用，它们解决的是“包名冲突”，不是“版本越界”。真遇到 psr/http-message v2 被强塞进来，唯一靠谱动作是回退、锁定、补 polyfill，而不是试图“覆盖接口定义”。
修复已发生的间接依赖破坏
别删 composer.lock，别跑全量 composer update。定位、定点、验证三步走：
- 先还原：用
git checkout HEAD -- composer.lock恢复上一个可用的 lock 文件，再composer install - 再定位：执行
composer why-not psr/http-message:^2.0，它会告诉你哪条依赖链挡住了 v2（比如laravel/framework要求^1.0），从而反推谁偷偷升了上游 - 最后定点修复：如果必须用 v2，就
composer update psr/http-message:^2.0 --with-dependencies，并同步检查所有用到该接口的代码，补类型断言或适配层
最容易被忽略的一点：很多团队把 composer.lock 提交到 Git，却没配置 pre-commit hook 或 CI 检查去确保没人提交“只改了 lock 但没改 json”的变更。这种单边更新，就是间接依赖失控的温床。
