直接修改 composer.json 的 version 字段无效，因 composer 依据 composer.lock 和版本约束计算依赖；需删除 composer.lock、收紧版本约束、运行 composer update monolog/monolog 确保降级生效。
直接改 composer.json 的 version 字段没用
很多人以为把 "monolog/monolog": "2.8.0" 改成 "2.7.0" 然后跑 composer update 就能回滚——但实际常卡在依赖冲突或跳过更新。Composer 默认只更新到满足约束的最新兼容版本，不是“你写啥它装啥”。
真正生效的方式是：先清掉锁文件的“记忆”，再强制重算依赖树。
实操建议：
- 删掉
composer.lock（不是注释掉，是物理删除） - 确保
composer.json里对应包的版本约束已收紧，比如从^2.8改成2.7.0或~2.7.0 - 运行
composer update monolog/monolog（指定包名，别用update全量更新） - 检查输出里是否出现
Downgrading monolog/monolog (2.8.0 => 2.7.0)
composer require 强制降级会破坏依赖一致性
执行 composer require monolog/monolog:2.7.0 看似快捷，但它本质是“添加新约束 + 更新”，可能意外升级其他包来满足新旧混搭的 require 规则。尤其当项目里已有 phpunit/phpunit 这类强耦合包时，容易触发 Your requirements could not be resolved 错误。
更稳的做法：
- 用
composer show monolog/monolog确认当前装的是哪个精确版本 - 用
composer depends monolog/monolog查哪些包依赖它，判断降级影响面 - 如果只是临时调试，加
--no-update再手动改composer.json和composer.lock里的 version 字段（不推荐长期用）
锁文件里藏着关键线索：看 packages 和 packages-dev 分区
composer.lock 不是扁平列表，它把生产依赖和开发依赖分开存。如果你只改了 packages 区的 monolog/monolog 版本，但它的某个 dev-only 依赖（比如 phpspec/prophecy）在 packages-dev 里仍绑着高版本，composer install 时可能静默失败或装错。
排查要点：
- 搜索
composer.lock中所有"name": "monolog/monolog"出现的位置，确认两处都改对 - 对比前后
composer.lock的content-hash值，不一致才说明真正生效 - CI 环境务必用
composer install（不是update），否则锁文件变更不会落地
PHP 版本不匹配会导致“降级成功”但运行报错
比如把 symfony/console 从 6.x 降回 5.4，看起来 composer update 没报错，但运行时抛出 ParseError: syntax error, unexpected token "string"——因为 5.4 要求 PHP 7.2+，而你本地是 PHP 8.2，某些内部类型声明被提前解析了。
必须核对的三件事：
- 目标版本的
composer.json里require.php字段（如"^7.2.5 || ^8.0"） - 运行
php -v，确认小版本号（8.2.12和8.2.0有时行为不同） - 某些包（如
laravel/framework）的旧版会悄悄要求扩展（ext-intl），但错误提示藏在artisan tinker启动阶段，不是composer阶段
composer.json 不碰 composer.lock，等于没改。 
