Debian 上选择 Composer 版本的原则
- 以项目为先：优先使用项目在构建时锁定的 Composer 版本，避免依赖解析差异。
- 稳定性分层：生产环境用 stable；预发布或验收可用 RC/beta；仅开发/测试才用 alpha/dev。
- 环境一致：开发、测试、生产保持同一 Composer 版本，减少“能装但行为不一致”的风险。
判定项目所需 Composer 版本
- 查看锁文件中的插件 API 版本：在项目根目录打开 composer.lock，搜索 “plugin-api-version”。例如值为 “2.2.0”，表示该项目是由 Composer 2.2.0 生成的，建议沿用该主版本系列。若文件缺失，先运行一次安装生成锁文件。
- 检查 composer.json 的插件 API 依赖：若看到 “composer-plugin-api”: “^2.0” 等约束，说明需要 Composer 2.x 运行时；若项目未声明，则仍以 composer.lock 为准。
- 现场核对本机 Composer：执行 composer --version，确保与项目所需版本一致。
稳定性标签与依赖策略的选择
- 标签含义与适用：
- stable：功能与 API 稳定，适合生产。
- RC：发布候选，接近稳定，适合最终回归测试。
- beta：主要功能可用，可能有变更，适合早期试用。
- alpha：早期开发，接口易变，仅开发者使用。
- dev：开发分支，随时变动，需谨慎。
- 如何在 composer.json 中控制：
- 允许非稳定依赖：在版本约束加稳定性后缀，如 “vendor/pkg”: “^2.0@beta”。
- 全局最低稳定性：设置 “minimum-stability”: “beta”，并配合 “prefer-stable”: true，在有稳定版时优先使用稳定包。
在 Debian 上安装与切换版本的可选做法
- 直接用官方安装脚本安装/升级（推荐保持最新稳定版）：
- 安装依赖：sudo apt update && sudo apt install -y curl php-cli php-mbstring git unzip
- 下载并验证安装器，然后全局安装到 /usr/local/bin/composer：
curl -sS https://getcomposer.org/installer -o composer-setup.php
HASH=$(curl -sS https://composer.github.io/installer.sig)
php -r “if (hash_file(‘SHA384’, ‘composer-setup.php’) === ‘$HASH’) { echo ‘Installer verified’; } else { echo ‘Installer corrupt’; unlink(‘composer-setup.php’); } echo PHP_EOL;”
sudo php composer-setup.php --install-dir=/usr/local/bin --filename=composer
- 升级：sudo composer self-update；回退可用 composer self-update --rollback。
- 多版本并存与切换（适合需要同时维护多个项目的场景）：
- 使用 update-alternatives 注册多个 Composer 可执行文件，交互选择默认版本：
sudo update-alternatives --install /usr/bin/composer composer /usr/local/bin/composer 100
sudo update-alternatives --config composer
- 项目内临时切换版本：进入项目目录执行 composer self-update --version=2.5.8（示例版本）。
快速决策清单
- 有 composer.lock 且包含 plugin-api-version：选择与之匹配的主版本系列（如 2.2.x）。
- 无锁文件但声明 composer-plugin-api ^2.0：选择 Composer 2.x。
- 生产环境：优先 stable；预发布/验收：RC/beta；开发/CI：alpha/dev（并配合 prefer-stable）。
- 多项目并行：用 update-alternatives 或脚本在项目目录内切换，避免全局冲突。
