composer list 按纯字母序排列所有命令，不分类、不按功能分组；install 与 outdated 可能相隔甚远，dump-autoload 与 diagnose 也不相邻，这是刻意设计，将命令视为函数名而非操作路径。
composer list 输出的命令到底按什么逻辑组织
它不分类，纯字母序。composer list 输出里你看不到“安装类”“开发类”“调试类”这种分组，install 和 outdated 可能隔十几行，dump-autoload 和 diagnose 也不挨着。这不是设计缺陷，是刻意为之：Composer 把命令当“函数名”处理，不预设使用路径。
常见错误现象：composer list | grep "dev" 找不到 require-dev——因为根本没这个命令，--dev 是 require 的选项；composer list | grep "script" 也搜不到项目 scripts 里的自定义命令，它们压根不注册进命令系统。
- 插件命令（如
phpstan:analyse）只在装了对应插件的项目中出现，全局安装但未启用时不会列出来 -
composer list -a显示隐藏命令（如self-update），但不会显示已废弃别名（如旧版的install别名i） - 终端支持分页时自动启用，按
q退出，别误以为卡死
怎么快速定位你真正需要的命令
别从头扫到尾。用 grep 过滤比肉眼快十倍：
-
composer list | grep "^u"—— 查所有以 u 开头的命令（update、outdated、validate都不在其中） -
composer list | grep -i autoload—— 不区分大小写搜关键词，能抓到dump-autoload -
composer list dump—— 输入前缀自动匹配，dump会列出dump-autoload和dump-env（如果装了 vlucas/phpdotenv）
注意：命令名必须用短横线，dump_autoload 或 dump autoload 都会报 Command "xxx" is not defined。空格和下划线是硬性错误，不是拼写问题。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
插件命令为什么有时“消失”了
不是 Composer 抽风，是加载时机和作用域问题。插件命令只在满足条件时才注入命令列表：
- 项目级插件（写在
composer.json的require-dev里）：必须先进入该项目目录，再运行composer list，否则不出现 - 全局插件（
composer global require phpstan/phpstan）：需确保COMPOSER_HOME/bin在$PATH中，且没在当前项目用--no-plugins - 某些插件依赖 PHP 扩展（如
roave/security-advisories需json扩展），缺失时静默跳过注册，加--verbose可看到警告
验证是否生效最稳的方式：cd /path/to/project && composer list | grep phpstan，而不是在任意目录瞎试。
查完命令名之后，下一步必须做这件事
看到 outdated 就直接跑？先看它到底支持什么选项。每个命令的帮助文本才是唯一权威来源：
-
composer outdated --help告诉你-D, --direct只检查 root 依赖，--minor-only过滤补丁更新 -
composer install --help明确写出--no-scripts会跳过post-install-cmd，而--ignore-platform-reqs可能导致运行时报错 - 同一个选项名在不同命令中含义可能不同：
--dev在require中是“加到 require-dev”，在update中却是“只更新 require-dev”
最常被跳过的一步，就是漏掉 --help。它不标版本号，但反映的是你本地实际行为——官网文档可能滞后，--help 永远是最新的。
