最可靠降级方式是 composer require vendor/package:1.2.3（精确版本），它会自动卸载当前版本、安装指定旧版并更新 lock 文件和 vendor；需注意依赖冲突、环境兼容性及三处版本一致性验证。

直接用 composer require 指定旧版本

最常用也最可靠的方式是覆盖式重装：Composer 会自动卸载当前版本，安装你指定的旧版，并更新 composer.lock 和 vendor/。关键在于版本约束写法要准确。

• 运行 composer require vendor/package:1.2.3（精确版本）——会强制锁定到该版本，不带 ^ 或 ~
• 若当前已安装高版本（如 2.5.0），该命令会触发降级，不是报错或忽略
• 避免写成 composer require vendor/package:^1.2，这仍可能装到 1.2.9 而非你想要的 1.2.3
• 执行前建议先 git status 确认无未提交变更，降级可能影响功能兼容性

降级时遇到 your requirements could not be resolved

这不是网络或权限问题，而是依赖图冲突：你想降级的包，其旧版本所依赖的其他包版本，与项目中已有其他依赖的要求不兼容。

Github Github Issues

通过 `gh` CLI 工具或 REST API 创建、分类、打标签、指派 GitHub Issues。

下载

• 先运行 composer why vendor/package 查看谁在引用它，再查这些“上游”是否硬性要求高版本
• 尝试加 --with-all-dependencies：例如 composer require vendor/package:1.2.3 --with-all-dependencies，让 Composer 同步调整传递依赖
• 如果失败，需手动检查 composer.json 中其他包的版本约束，临时放宽（如把 "monolog/monolog": "^2.8" 改为 "^2.0"）再重试

composer update 加版本约束也能降级

虽然 composer update 默认升级，但它支持局部更新+版本锁定，适合批量或条件性降级。

• 直接运行 composer update vendor/package --with-dependencies 不会降级，它只升不降
• 正确做法是先改 composer.json：
  

  "require": {
      "vendor/package": "1.2.3"
  }
  

  
  再运行 composer update vendor/package —— 这会尊重 JSON 中的显式声明，执行降级
• 注意：不要运行 composer update（无参数），否则所有包都可能被意外升级

验证降级是否生效且无残留

仅看 composer show vendor/package 输出还不够，有些旧版本 bug 会在运行时暴露，必须确认三处一致。

• 运行 composer show vendor/package，确认显示的 versions 是你指定的旧版（如 1.2.3）
• 检查 vendor/vendor/package/composer.json 中的 version 字段，应为 1.2.3（不是 dev-main 或 1.2.x-dev）
• 查看 composer.lock 中对应包的 version 和 source/reference，reference 应为该版本的 commit hash（不是主干分支）
• 如果项目用了 autoload classmap，降级后记得跑一次 composer dump-autoload 避免类加载缓存问题

Composer 的降级本质是“重新解析依赖图并接受更老的解”，它不会保留旧文件或跳过冲突检查。最容易被忽略的是：你以为只是改一个包，但它的旧版本可能依赖 PHP 7.4，而你本地已是 PHP 8.2 —— 这类环境兼容性问题不会在 require 阶段报错，直到 autoload 或运行时报 ParseError。