composer需通过官方安装脚本配合composer_version环境变量安装指定版本，如curl -ss https://getcomposer.org/installer | php -- --version=2.7.7；依赖版本锁定应在composer.json的require字段中用精确版本号（如"3.5.0"）或语义化约束（如"^3.5"）实现。
安装特定版本的 Composer 本身
Composer 本身不是靠 composer install 装的，它是个独立的 PHAR 工具，版本管理得绕开项目依赖走。
最稳的方式是用官方安装脚本配合 COMPOSER_VERSION 环境变量：
curl -sS https://getcomposer.org/installer | php -- --version=2.7.7
注意：--version 参数只在官方 installer 中有效，且仅支持已发布的稳定 tag（比如 2.7.7、2.5.8），不接受 ^2.7 这类语义化写法。
- 装完后用
php composer.phar --version确认，别信composer --version——后者可能调的是全局 PATH 里的旧版 - Linux/macOS 下如果想全局用，记得把
composer.phar改名 + 加入 PATH，例如sudo mv composer.phar /usr/local/bin/composer - Windows 用户直接下
Composer-Setup.exe不支持指定版本，必须用 CLI 方式安装 PHAR
在 composer.json 里锁定依赖包版本
“指定版本号”本质是控制 require 字段的约束写法，不是命令行开关。
常见写法差异直接影响更新行为和兼容性：
-
"monolog/monolog": "3.5.0"→ 精确锁定，composer update不会动它 -
"monolog/monolog": "^3.5"→ 允许 3.5.0 到 composer update monolog/monolog 可能升到 3.6.0 -
"monolog/monolog": "dev-main"→ 指向分支，不稳定，CI 构建容易飘，慎用 -
"monolog/monolog": "3.5.*"→ 等价于"~3.5.0"，只允许 patch 升级（3.5.1, 3.5.2…）
执行 composer require monolog/monolog:3.5.0 会自动写进 composer.json 并安装，但要注意：如果已有更宽泛的约束（如 ^3.4），命令不会覆盖，得手动改 JSON 或加 --no-update 再删重装。
composer update 时只更新某几个包
默认 composer update 会按整个锁文件重算所有依赖，想局部更新必须显式列出包名。
比如只升级 guzzlehttp/guzzle 到最新兼容版：
composer update guzzlehttp/guzzle
多个包就空格分隔：
composer update guzzlehttp/guzzle symfony/console
- 它仍受
composer.json里对应包的版本约束限制，不会突破^7.0去装 8.x - 如果想强制忽略约束装某个版本（比如临时调试），得加
--with-all-dependencies，但大概率引发冲突，不推荐日常用 - 运行后检查
composer.lock是否真变了——有时看似执行了，其实没更新，因为当前已满足约束
为什么 composer install 不按 composer.json 装新版本？
这是设计使然：composer install 只读 composer.lock，完全无视 composer.json 里的新约束。这是为了确保多人环境一致。
常见误操作和后果：
- 改了
composer.json但只跑composer install→ 毫无变化，连 warning 都没有 - 删了
composer.lock再install→ 所有包按composer.json重新解析，可能引入不兼容更新，CI 构建失败 - 团队里有人 commit 了新
composer.lock，你 pull 后只install→ 安装的是他锁住的版本，不是你本地json里写的
真正生效的链路永远是：修改 composer.json → composer update xxx → 提交 composer.lock。漏掉中间一步，版本就对不上。
lock 文件里记录的是精确版本+hash，这才是 Composer 认的“事实”，composer.json 只是人类可读的“意向书”。
