不能用一键脚本“安全”安装 Composer，因官方不提供、CentOS Stream 源无包、第三方脚本常跳过校验或硬编码过期 URL；curl | php 在 CentOS Stream 上易因 OpenSSL 与 PHP 版本不匹配导致 Signature mismatch 或静默失败，应改用明确版本 URL 下载、手动校验 SHA384、再安装。
不能用一键脚本“安全”安装 Composer —— 官方不提供、CentOS Stream 源里没有、第三方脚本往往跳过校验或硬编码过期 URL，容易导致 Signature mismatch 或静默失败。
为什么 curl | php 安装在 CentOS Stream 上大概率失败
官方安装命令 curl -sS https://getcomposer.org/installer | php 在 CentOS Stream 8/9 上常因 OpenSSL 版本与签名算法不匹配而报 Signature mismatch。这不是网络问题，是 SHA384 校验逻辑在较新 PHP + OpenSSL 组合下对重定向响应处理异常。直接执行该命令，php 进程可能中途退出，留下损坏的 composer-setup.php，后续 php composer-setup.php 会报错但不提示原因。
- 别依赖重定向：用明确版本 URL 下载，例如
https://getcomposer.org/download/2.9.6/composer.phar，避免latest跳转引入不确定性 - 必须手动校验：用
php -r "hash_file('sha384', ...)"对比官网提供的.sha384文件，缺这步就等于裸奔 - 别用 root 直接跑 curl | php：临时文件写入权限、SSL 上下文、PHP 扩展启用状态都不可控；先下载再校验再安装更稳
手动安装 Composer 的最小可靠流程（含权限与路径）
以下命令可直接复制粘贴执行，适配 CentOS Stream 8/9，无需改 /etc/profile 或全局 export PATH：
- 下载指定版本：
curl -sS https://getcomposer.org/download/2.9.6/composer.phar -o /tmp/composer.phar - 校验签名：
php -r "if (hash_file('sha384', '/tmp/composer.phar') === file_get_contents('https://getcomposer.org/download/2.9.6/composer.phar.sha384')) { echo 'OK'; } else { exit(1); }"（返回 OK 才继续） - 安装并赋权：
sudo mv /tmp/composer.phar /usr/local/bin/composer && sudo chmod 755 /usr/local/bin/composer - 验证：
composer --version应输出Composer version 2.9.6 - 若提示
command not found，运行echo $PATH确认含/usr/local/bin；若提示Permission denied，检查ls -l /usr/local/bin/composer是否有x权限
改源必须写的三个字段，漏一个都不生效
执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 才真正生效。注意这三处硬性要求：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
repo.packagist是固定键名，不是repos.packagist或repository.packagist—— 写错就静默忽略 -
composer是 type 值，必须显式写出，不能省略，也不能写成composer-type或注释 - URL 必须以
/结尾，否则请求路径拼成https://mirrors.aliyun.com/composer/packages.json（少一级目录），直接 404
验证是否成功：composer config -g repo.packagist 应输出完整 JSON，如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。如果为空或报错，说明没写对。
项目级配置比全局更可控，尤其在 CI 或多项目环境
全局镜像看似省事，但在实际交付中容易被覆盖或失效：
- 项目
composer.json中若定义了"repositories": []或"packagist.org": false，全局设置完全无效 - Docker 构建时，容器无用户家目录，
composer config -g写入的配置不会持久化 - 推荐进项目根目录执行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g）——它会自动合并进composer.json的repositories字段，Git 可追踪，CI 一致 - 如果已有私有仓库配置，确保
repositories是对象而非数组，否则该命令会覆盖整个字段
真正麻烦的从来不是装不上，而是装上了却不知道它到底连的是哪个源、用的是哪份缓存、谁在覆盖谁的配置。每一步校验和显式声明，都是为后续排查省下两小时。
