composer install --no-ansi 在 CI/CD 中必须使用，因日志系统不支持 ANSI 序列，否则输出乱码干扰排查和日志解析；且非所有环境自动禁用颜色，该参数是最直接可靠的强制关闭方式。
为什么 composer install --no-ansi 在 CI/CD 里不是可选，而是必须
CI/CD 日志系统（比如 Jenkins、GitLab CI、GitHub Actions）默认不支持 ANSI 转义序列，composer 输出的彩色日志会变成一堆乱码，比如 [32mLoading composer repositories with package information[39m。这不仅干扰人工排查，还会让日志解析工具（如 ELK、Sentry）误判为异常内容。
关键点在于：不是所有 CI 环境都自动禁用颜色 —— 即使 TERM 未设或设为 dumb，某些 Composer 版本仍会输出 ANSI，尤其在 Docker 容器内运行时。
-
--no-ansi是最直接、最可靠的开关，它强制关闭所有颜色和光标控制字符 - 不要依赖
COMPOSER_NO_ANSI=1环境变量：它在旧版 Composer（ - 如果用了
composer update，同样要加--no-ansi；仅对install加不够
--no-ansi 和 --quiet 的区别不能混用
--quiet 不只是“关颜色”，它会抑制大部分输出（包括成功提示、包下载进度、警告），只留错误和致命异常。CI 日志需要的是「干净但完整」的日志，不是「静音」。
典型误用场景：把 --quiet 当作日志净化手段，结果 CI 流水线失败时完全看不到哪一步卡住、哪个包解析失败。
-
--no-ansi→ 保留全部文本信息，仅去除颜色控制符（适合日志归档与人工回溯） -
--quiet→ 只输出错误 + exit code，连Installing dependencies from lock file都不显示（调试时基本不可用） - 两者可共存：
composer install --no-ansi --quiet等价于只输出错误，一般不推荐
Docker 构建中漏掉 --no-ansi 的常见表现
在 Dockerfile 中写 RUN composer install，构建日志里出现大量 ^[[33m、^[[0m 类似字符，或者日志行被截断、缩进错乱，基本就是 ANSI 没关。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
更隐蔽的问题是：某些 CI 平台（如 Bitbucket Pipelines）会把含 ANSI 的日志行识别为“超长行”而自动折叠，导致关键错误被隐藏。
- 务必在所有
composer命令后显式加--no-ansi，哪怕命令已封装在 shell 脚本里 - 若使用
docker build --progress=plain，也不能替代--no-ansi—— 这是两个不同层级的控制 - 检查基础镜像：有些 PHP 官方镜像（如
php:8.2-cli）预装的 Composer 版本较老，默认行为更激进，必须加参数
CI 配置里容易忽略的兼容性细节
GitHub Actions 默认用 actions/checkout + composer/installer，看起来省事，但它底层调用的仍是 composer install，没加 --no-ansi 就照样输出 ANSI。
GitLab CI 的 image: php:8.2 同理 —— 镜像里装的是标准 Composer，不会因为跑在 CI 就自动降级输出格式。
- 在
.github/workflows/ci.yml中，确保每条run下的composer命令都带--no-ansi - 避免用
composer global require类命令：它可能触发交互式提示（即使加了--no-ansi也拦不住），CI 应该用项目级require或预装二进制 - Composer 2.5+ 支持
--no-ansi全局生效，但 CI 脚本不该依赖版本特性，显式声明更稳
真正麻烦的不是加参数，而是有人改了本地 composer.json 的脚本字段，加了 "post-install-cmd": "php artisan optimize"，却忘了这些钩子执行时也会继承父进程的 ANSI 设置 —— 所以整个链路都要统一处理。
