直接修改 composer.json 中的版本约束是最常用且可控的方式，需手动编辑该文件中 require 或 require-dev 下对应包的版本字符串（如 "^2.8" 改为 "^3.0"），再执行 composer update 包名 或全量 update 才生效；仅改 lock 文件风险极高，必须由 composer 重算依赖生成新 lock。
直接修改 composer.json 中的版本约束行
最常用也最可控的方式，就是手动编辑项目根目录下的 composer.json 文件，在 "require" 或 "require-dev" 对象里找到对应包名，改掉它的版本字符串。比如把：
"monolog/monolog": "^2.8"改成
"monolog/monolog": "^3.0"。改完后必须运行
composer update monolog/monolog（指定包名）或 composer update（全量更新），否则变更不会生效——composer install 只读 composer.lock，不会重新解析约束。
用 composer require 覆盖已有依赖
这个命令不只是加新包，它也能“重写”已有依赖的约束并触发更新。比如项目已装 guzzlehttp/guzzle 为 ^7.5，你想升到 ^8.0，直接运行：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
composer require guzzlehttp/guzzle:^8.0。Composer 会自动更新
composer.json 的约束，并同步更新 composer.lock 和 vendor/ 下的代码。注意：如果该包有不兼容的依赖树（比如你锁了 php 版本太低），命令会报错并中止，不会留下半截状态。
为什么不能只改 composer.lock？
composer.lock 是生成文件，手改它风险极高：
- 校验和（
content-hash）会失效，下次composer install可能报错 - 嵌套依赖的版本关系可能断裂，导致
autoload失败或运行时Class not found - CI/CD 流水线很可能因 lock 文件校验失败而中断
composer.json 约束出发，让 Composer 自己重算依赖图并生成新 lock 文件。
升级后出现 Class not found 或 Method not found
这是大版本升级（如 v2 → v3）最常见的问题，本质是 BC（Breaking Change）未处理。重点检查：
- 是否漏掉了官方升级指南里要求的命名空间变更（比如
Psr\Log\LoggerInterface没变，但实现类路径变了） - 是否还在调用已被移除的方法（如
Monolog\Logger::addInfo()在 v3 中废弃） -
vendor/autoload.php是否被重新加载（有些脚本缓存了旧 autoloader）
composer show monolog/monolog 看当前安装版本，再查对应 GitHub 的 UPGRADE.md 或 CHANGELOG.md。
实际操作中最容易卡住的点，不是改哪一行，而是没意识到 composer update 会连带升级其他间接依赖——尤其当多个包都依赖同一个库的不同子集时，Composer 可能挑出一个“满足所有人”的中间版本，而不是你期望的那个。真要锁定，得配合 composer prohibits 查冲突，或者临时加 "prefer-stable": true。
