Composer install 没进度条是因为 stream_isatty(STDOUT) 检测失败，自动降级为静默模式；唯一可靠启用方式是显式添加--progress参数，它优先级最高，可覆盖所有环境变量和配置，且专为下载/解压阶段设计。
composer install 为什么没进度条
不是配置错了，是 Composer 检测到 stdout 不是交互式终端（stream_isatty(STDOUT) 返回 false），就自动关掉进度条——CI、Docker、SSH 未开 PTY、重定向到文件（如 composer install > log.txt）全都会触发这个逻辑。Windows PowerShell 中中文乱码也可能让 ANSI 进度字符渲染失败，看起来像“没动”。
怎么强制显示下载进度条
--progress 是唯一可靠方式，优先级最高，能覆盖所有环境变量和配置。它专为下载/解压阶段设计，只显示包名 + 文本进度条，干净不干扰。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer install --progress：最直接，非 TTY 环境下也生效 -
composer install -v：会显示类似Downloading monolog/monolog (3.5.0): 100% [============================>]的静态进度行，但混入大量调试信息 - 别用
--no-progress测试——这是关开关，不是开；也别信COMPOSER_PROGRESS=1，它根本不存在 - Docker 或 GitLab CI 中，加
-t参数分配 TTY（RUN composer install -t --progress），或用script -qec "composer install --progress" /dev/null绕过检测
怎么查看真正有用的详细日志
-vvv 是唯一能透出底层行为的开关：HTTP 请求 URL、原始响应体、SAT 依赖求解步骤、子进程 stderr 全部可见。其他参数（-v、-vv）只暴露表层动作，卡在 Resolving dependencies through SAT 时基本没用。
- 所有
-vvv输出走stderr，想grep必须写2>&1 | grep "https\|failed\|Downloading" - CI 或 Docker 中加
--no-ansi，避免颜色控制符污染日志解析 - 敏感信息（如带 token 的私仓 URL）会明文出现，截图前务必清洗：
sed 's/token:[^@]*@/token:***@/g' - 别翻
~/.composer/logs/composer.log——它只记初始化错误，不含任何安装过程日志
中文终端下进度和日志显示异常怎么办
PowerShell 或某些 SSH 客户端里中文乱码，会导致进度条字符错位、-vvv 日志中 JSON 响应体显示为方块或空格，本质是编码或字体问题，不是 Composer 本身故障。
- 加
--ansi强制启用 ANSI 控制符，可能修复进度条渲染（composer install --progress --ansi） - 用
composer install -vvv 2>&1 | iconv -f utf-8 -t gbk 2>/dev/null尝试转码（仅限 Windows CMD 场景） - 更稳妥的做法是重定向到文件再用支持 UTF-8 的编辑器打开：
composer install -vvv --no-ansi 2>&1 > debug.log - 如果
-vvv日志里出现json_decode() expects parameter 1 to be string, bool given，先别急着查 PHP 版本——大概率是网络拦截导致响应为空，不是编码问题
--progress 和 -vvv 解决的是两类事：前者让你知道“有没有在动”，后者告诉你“卡在哪、为什么动不了”。两者经常要一起用，但注意 -v 和 --progress 同时存在时，-v 会压制动画进度，只留静态百分比——这不是 bug，是输出层级设计。 
