Composer 颜色输出由 COMPOSER_COLOR 环境变量或 --color/--no-color 参数控制，与配置文件无关；设为 1 强制启用，0 强制禁用，CI 中推荐显式设置 COMPOSER_COLOR=1。
Composer 命令行默认会根据终端支持自动启用颜色，但有时它会禁用（比如在 CI 环境、重定向输出或某些 SSH 终端中），导致错误提示、依赖树、进度条等信息可读性下降。是否显示颜色由 COMPOSER_COLOR 环境变量和 --no-color 参数共同控制，不是靠配置文件设置。
如何强制开启或关闭颜色输出
Composer 不读取 composer.json 或 config.json 中的颜色开关，只响应运行时参数或环境变量：
-
COMPOSER_COLOR=1：强制启用颜色（即使 stdout 不是 TTY） -
COMPOSER_COLOR=0：强制禁用颜色（覆盖任何自动检测） -
composer install --color：显式启用（等价于COMPOSER_COLOR=1） -
composer install --no-color：显式禁用（等价于COMPOSER_COLOR=0）
为什么有时候颜色突然没了
常见原因不是配置丢失，而是执行上下文变化：
- 管道或重定向：
composer update | grep "php"会让 Composer 自动禁用颜色（因检测到非 TTY 输出） - CI/CD 环境（如 GitHub Actions、GitLab CI）默认无 TTY，
COMPOSER_COLOR未设时自动关色 - 某些远程终端（如 Windows 的旧版 CMD）不支持 ANSI 转义序列，即使设置了也会被忽略
- 使用
composer -n（即--no-interaction）不会影响颜色，但部分脚本误加--no-color
验证当前是否启用颜色的简单方法
不需要看文档或翻源码，直接运行这条命令即可观察效果：
composer show --help | grep -A2 "Available commands"
如果看到带颜色的命令名（如
php -r "echo getenv('COMPOSER_COLOR') ?: 'not set';"
CI 环境中稳定启用颜色的推荐写法
很多 CI 平台（如 GitHub Actions）支持伪 TTY，但更可靠的是显式声明：
- GitHub Actions：
env: { COMPOSER_COLOR: '1' }写在 job 步骤中 - GitLab CI：
variables: { COMPOSER_COLOR: "1" } - Shell 脚本中临时启用：
COMPOSER_COLOR=1 composer install - 避免全局 alias 覆盖：
alias composer='COMPOSER_COLOR=1 composer'可能干扰其他工具链，慎用
注意：COMPOSER_COLOR 是运行时开关，Composer 没有「永久保存颜色偏好」的机制——每次调用都重新判断，所以别试图往 ~/.composer/config.json 里加 color 字段，它会被忽略。
