最可靠方式是在require命令中明确指定版本号；如^2.9.0支持小版本升级，2.9.4精确安装，dev-main仅用于调试，版本格式错误将导致降级或报错。
直接指定版本号安装最可靠
Composer 安装特定版本不是靠“切换源”或“改配置”，而是靠在 require 命令里写死版本约束。不加任何修饰符时，composer require vendor/name 默认拉最新稳定版，但你要的往往不是“最新”，而是“那个能跑通的旧版”。
常见错误是复制别人命令却漏掉版本号，比如只敲 composer require monolog/monolog，结果装了 v3.x，而你的 PHP 7.4 环境根本不兼容。
- 用
composer require vendor/name:^2.9.0锁定最小兼容版本（推荐，支持向后小版本升级） - 用
composer require vendor/name:2.9.4精确安装某次发布（适合修复已知 bug 或复现环境） - 用
composer require vendor/name:dev-main装开发分支（仅调试用，别上生产）
版本号写错会静默降级或报错
Composer 对版本字符串非常敏感。写 2.9 和 ^2.9 行为完全不同：2.9 是“>=2.9.0 ^2.9 实际等价于 >=2.9.0 —— 看似一样，但如果你写成 <code>^2.9.0，它就只接受 2.9.0 到 2.9.999，跳过 2.10.0（因 2.10 被视为不兼容变更）。
更隐蔽的坑是用了带连字符的预发布版，比如 3.0.0-beta1：默认情况下 Composer 不装预发布包，除非你显式加上 @beta 后缀，或在 composer.json 里设 "minimum-stability": "beta"。
立即学习“PHP免费学习笔记（深入）”；
- 查清目标包真实发布的版本号，别信文档或 GitHub 页面顶部显示的“Latest release”——去 Packagist 页面点开
versions标签页确认 - 遇到
Could not find package，先检查拼写，再确认该版本是否已废弃（Packagist 上显示abandoned） - PHP 版本不匹配时，错误信息通常是
Your requirements could not be resolved，背后往往是php: ^8.1这类依赖冲突
全局安装 vs 项目本地安装要分清
composer global require 装的是全局工具（比如 larastan/larastan），对当前项目无影响；而项目内执行 composer require 才会写入 composer.json 并更新 vendor/。很多人想给 Laravel 项目装旧版 guzzlehttp/guzzle，却误用 global，结果 app() 里还是找不到类。
- 项目依赖一律用项目根目录下执行
composer require，别加global - 装完立刻检查
composer.json里的require字段是否已写入对应条目和版本号 - 如果已有同名包，
require会尝试升级/降级；如需强制重装，先composer remove vendor/name再重新require
装完还得验证是否真生效
Composer 写完 composer.json 不等于代码里就能用。尤其当包提供函数、类或配置时，容易卡在自动加载或运行时依赖上。
- 运行
composer show vendor/name确认实际安装的版本号，不是你“以为”的那个 - 检查
vendor/autoload.php是否被正确引入（常见于自写脚本漏掉这行） - 若类找不到，运行
composer dump-autoload强制刷新自动加载映射（尤其在手动增删类文件后） - 某些包（如
symfony/console）需要额外注册服务提供者，版本降级后接口可能变化，得同步改调用方式
版本管理从来不是“输对命令就完事”，关键在确认上下文：PHP 小版本、其他已装包的约束、自动加载路径、运行时行为是否一致。少一个环节，就可能让“明明装了”变成“就是不工作”。
