会。手动修改 require 字段而不运行 composer update 会导致 vendor 代码不变、lock 文件不同步，且无约束符的版本可能被意外升级；安全做法是清空 vendor 和 lock 后重新安装，降级需用 --with-all-dependencies，锁定用 = 前缀或 prohibit，排查报错优先用 composer show 和 why。
直接修改 composer.json 的 require 字段会出问题吗？
会。手动改完不运行 composer update，vendor/ 里的实际代码不会变，Composer 仍认为旧版本已安装；更危险的是，如果只改了某个包的版本但没加约束符（比如写成 "monolog/monolog": "2.8.0" 而不是 "^2.8.0"），下次执行 composer update monolog/monolog 可能意外升级回高版本——因为 "2.8.0" 是精确匹配，但 Composer 默认行为是取满足条件的最新版，除非你用 = 显式锁定。
安全做法是：先删掉 vendor/ 和 composer.lock（或至少清空 vendor/），再让 Composer 重新解析依赖树。
- 临时降级测试：用
composer require vendor/package:1.2.3 --no-update先写入composer.json，再composer update vendor/package - 生产环境降级：必须加
--with-all-dependencies，否则可能因子依赖冲突导致失败 - 永远不要只改
composer.json就上线，composer.lock必须同步更新并提交
composer update 时如何避免连带升级其他包？
默认 composer update vendor/package 会递归更新其所有兼容的子依赖，这常引发意外行为。比如你想把 guzzlehttp/guzzle 降到 7.5.0，但它的子依赖 psr/http-client 可能从 1.0.1 升到 1.0.3，而你的代码恰好依赖旧版的内部方法签名。
用 --with-dependencies（注意不是 --with-all-dependencies）可控制范围：
立即学习“PHP免费学习笔记（深入）”；
-
composer update guzzlehttp/guzzle --with-dependencies：只更新guzzlehttp/guzzle及它直接声明的require（不含传递依赖） -
composer update guzzlehttp/guzzle --with-all-dependencies：更新整条依赖链，适合彻底验证兼容性 - 加
--dry-run先看将要变更哪些包：composer update vendor/package --dry-run
如何永久锁定一个包不被任何 update 影响？
靠 require 字段加 = 前缀最可靠，例如："phpunit/phpunit": "=9.5.26"。这个写法会让 Composer 把该包视为“精确版本”，哪怕运行 composer update 也不动它——前提是 composer.lock 已生效且没被手动删掉。
但要注意两点：
- 如果该包是其他包的子依赖（比如你没直接 require
sebastian/exporter，但它被phpunit/phpunit引入），仅锁父包不能锁住它；此时需单独加一行"sebastian/exporter": "=4.0.5" - 使用
composer prohibit（Composer 2.2+）可主动阻止某版本范围：composer prohibit vendor/package:"^2.0"，比手动锁更灵活 - CI 环境中务必用
composer install --no-dev（或--ignore-platform-reqs需谨慎），否则平台要求可能绕过锁定
降级后运行报错：Class not found 或 Method not found 怎么快速定位？
常见原因是类名变更、方法废弃或命名空间调整，不是 Composer 没装对。先确认实际加载的是哪个版本：
composer show vendor/package
输出里会显示当前安装路径和确切版本号。再检查该版本的源码是否真有你要调用的类/方法：
- 进
vendor/vendor/package/src/目录，用grep -r "YourClassName" .扫描 - 查官方 CHANGELOG，比如
laravel/framework的 v9 → v8 降级，Illuminate\Support\Str::of()在 v8 不存在 - 用
composer why vendor/package查谁依赖了它，判断是否该包本就不该降级（比如它是底层 SDK，上层框架强制要求最低版本）
真正难处理的是隐式依赖：某个包在 v1.x 用 symfony/event-dispatcher: ^5.0，v2.x 改用 ^6.0，你强行降级主包却没同步处理 event-dispatcher，运行时才爆 ClassNotFound——这种必须靠 composer depends --tree 逐层看依赖树。
