composer list支持按命名空间筛选（如composer list config）、--short纯命令名输出、--format=markdown生成文档；--no-progress仅禁用下载安装阶段进度条，不抑制状态提示、错误或脚本输出；全局配置composer config -g no-progress true可长效静默所有项目下载进度。
Composer 的隐藏功能不在于“炫技”，而在于解决真实场景中的信息发现、日志污染和自动化卡点问题。最值得立即用起来的，是 composer list 的筛选能力、--no-progress 的精准静默控制，以及全局配置 no-progress 的长效治理效果。
如何用 composer list 快速定位命令而不是翻文档
看到 composer list 只输出一堆命令，很多人就划走了。但它真正有用的地方是「按命名空间过滤」——比如你刚在项目里看到 composer config 被调用，但不确定它支持哪些子操作，直接运行：
composer list config
就能只列出所有 config: 开头的命令（如 config、config --list、config --global），省去扫屏和猜名。同理：
-
composer list require查看依赖相关操作（require、require-dev、remove） -
composer list --short输出纯命令名，适合 grep 或脚本解析 -
composer list --format=markdown生成可直接粘贴进 Wiki 的结构化列表
注意：composer list --verbose 不会显示参数详情，它只是让输出更长；要看具体命令怎么用，得接 composer help <command></command>，比如 composer help dump-autoload。
--no-progress 真正管用的边界在哪
这个参数常被误认为“让 Composer 安静下来”，但它只干一件事：禁掉下载和安装阶段的实时进度条（如 Downloading: 100% 这种不断刷新的行）。它不会抑制：
-
Writing lock file、Installing dependencies from lock file这类状态提示 - 任何错误或警告（比如
Failed to download vendor/package） - 脚本执行输出（如
php artisan optimize的结果）
所以 CI/CD 中单加 --no-progress 仍可能遇到日志混入 ANSI 转义符、或因未设 --no-interaction 导致构建卡在 auth 提示上。真正稳妥的组合是：
composer install --no-progress --no-interaction --optimize-autoloader
如果还要进一步压制非错误输出（比如成功提示），才加 --quiet，但要注意它也会吞掉 Warning —— 某些低危提示（如包已废弃）可能就此被忽略。
全局关掉进度条，比每次敲参数更可靠
你不需要在每个 composer install 后面手动加 --no-progress。运行一次：
composer config -g no-progress true
就会把 {"config": {"no-progress": true}} 写进全局配置文件（Linux/macOS 是 ~/.composer/config.json，Windows 是 %APPDATA%\Composer\config.json）。之后所有项目默认静默下载，除非你显式加 --progress 覆盖它。
这个配置对 Docker 构建特别友好，尤其在 Alpine 等精简镜像中，TTY 检测不可靠，环境变量 COMPOSER_DISABLE_TTY=1 虽然也能禁进度条，但它还会顺带关掉颜色和交互逻辑，影响面更广；而 no-progress 配置只动进度条，更精准。
别信 COMPOSER_ERROR_REPORTING=0 这种伪配置
有人试过设 COMPOSER_ERROR_REPORTING=0 来隐藏报错堆栈，结果发现完全没用。这不是 Composer 的 bug，而是因为这个环境变量根本不存在 —— 官方文档里没它，源码里也搜不到，属于社区误传后被静默忽略的“幽灵变量”。
真要控制错误输出粒度，只有两条路：
- 用
--no-ansi --no-interaction -q组合减少干扰，但失败时仍保留最后一行摘要 - 重定向 stderr：
composer install 2>/dev/null（Linux/macOS）或composer install 2>nul（Windows），但这样错误就彻底消失了，无法判断是否真的成功
生产或 CI 场景下，更推荐用 shell 判断退出码：if ! composer install -q -n; then echo "fail"; exit 1; fi。Composer 的退出码才是唯一可信信号，输出有没有、有多少，全是表象。
