真正该看的是 stderr 中非[INFO]行（如 PHP 致命错误、权限拒绝），可忽略 stdout 中以[INFO]/[WARNING]开头的 Composer 自身日志及纯统计行；加 --no-ansi --no-interaction 后需保留 stderr，用 2>&1 | grep -v "^[.*]" 过滤才不丢真错误。
composer install 输出里哪些行真该看，哪些可以忽略
composer install 的输出不是日志，而是混合了状态提示、进度反馈和真实错误的三合一流。真正需要你停下手来处理的，只有 stderr 里的非 [INFO] 行——比如 PHP 致命错误、扩展缺失报错、权限拒绝；而 stdout 里所有以 [INFO]、[WARNING] 开头的，基本是 Composer 自己的运行快照，不反映环境问题。
常见干扰项：
-
[INFO] Loading config file /path/to/composer.json—— 正常读配置，不用管 -
[WARNING] The lock file is not up to date with the latest changes in composer.json—— 表示composer.json有修改但没跑update，install 仍会按 lock 执行，这个 warning 不影响安装结果 -
Package operations: 42 installs, 0 updates, 0 removals—— 纯统计，只说明动作量，不保证成功
真正要警觉的是这些：
-
PHP Fatal error: Uncaught Error: Call to undefined function mb_strlen()—— 缺ext-mbstring，不是 Composer 问题，是 PHP 环境没配好 -
Could not open input file: vendor/autoload.php——vendor/没生成或路径错，大概率是 install 半途失败或被中断 -
file_put_contents(/path/to/vendor/composer/installed.json): failed to open stream: Permission denied—— 目录写权限不足，尤其在 Docker 或 CI 中常见
为什么加 --no-ansi --no-interaction 后反而看不出错在哪
这两个参数只是关掉颜色和交互式提示，不改变错误流向。问题出在很多人顺手把整个输出重定向到 /dev/null，比如：composer install --no-ansi --no-interaction > /dev/null 2>&1。这会导致 stderr（真正错误）也被吞掉，失败时只剩静默退出，根本不知道是网络超时、证书验证失败，还是平台版本不匹配。
安全做法是保留 stderr 的原始结构，只过滤 Composer 自带日志：
- Linux/macOS：
composer install --no-ansi --no-interaction 2>&1 | grep -v "^[.*]" - Windows PowerShell：
composer install --no-ansi --no-interaction 2>&1 | findstr /v "^["
关键点：必须用 2>&1 把 stderr 合并进 stdout，grep/findstr 才能捕获到错误。漏掉这句，管道左边的错误就直接飞走了。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
“Loading composer repositories with package information” 卡住几秒正常吗
正常，但卡超过 10 秒就要怀疑了。这一行表示 Composer 正在从配置的源（默认 packagist.org 或镜像）拉取元数据缓存，首次运行或缓存过期时会触发 HTTP 请求。它本身不下载包，只获取包名、版本、依赖关系等索引信息。
卡顿常见原因：
- 本地没配镜像，直连 packagist.org 被墙或延迟高
- composer.json 里写了多个私有仓库（
repositories），其中某个不可达 - DNS 解析慢，尤其在某些企业内网或 Docker 容器里
验证方式：加 -vvv 参数跑一次，看卡住时最后一行是不是 Reading .../packages.json from cache 或 Downloading .../packages.json。前者是缓存读取慢（少见），后者是网络请求挂起（常见）。
install 成功后 vendor/autoload.php 存在，但类还是找不到
这不是 Composer 输出的问题，而是 autoload 配置没生效或映射错位。install 只负责把文件解压进 vendor/ 并生成 vendor/autoload.php，但类能否加载，取决于你项目里是否正确引入了它，以及 composer.json 中 autoload 段是否写对。
高频踩坑点：
- 代码里漏了
require __DIR__.'/vendor/autoload.php';—— 尤其在 CLI 脚本或测试入口里容易忘 -
"psr-4": {"App\": "src/"}写成"App\": "src"（少斜杠），导致AppFoo去找srcFoo.php而不是src/Foo.php - 改过
autoload后没运行composer dump-autoload，新映射不会自动生效 -
vendor/在 Git 中被意外提交，又有人手动删了部分目录，autoload 生成逻辑依赖完整 vendor 结构
最省事的验证方式：执行 php -r "require 'vendor/autoload.php'; var_dump(class_exists('MonologLogger'));"。返回 bool(true) 说明 autoload 通了，问题出在你自己代码的命名空间或路径上。
