composer depends 是查反向依赖的精准命令，专为“谁依赖了我”设计；composer show --tree 需手动上溯父节点且仅显示已安装路径，installed.json 手动解析最可靠但需注意 alias/replace 等边界情况。

composer show --tree 怎么看反向依赖关系

它不直接显示“谁依赖了我”，而是展示当前项目里所有包的依赖树，你需要手动往上翻找——composer show --tree vendor/package-name 输出中，目标包出现在哪一层的子节点，它的父节点就是直接依赖者。但注意：这只能看到**当前已安装且启用的依赖路径**，如果某个包被 require-dev 引入、或被其他未激活的配置排除，它不会出现在树里。

• 运行前确保 composer install 已完成，否则树结构不完整
• 输出可能很长，建议配合 grep 过滤：例如 composer show --tree monolog/monolog | grep -B 1 "your-target-package"
• 该命令不区分 require 和 require-dev，混在一起显示，需结合 composer show -s 确认来源

composer depends 能不能查反向依赖

可以，而且更精准：composer depends 是 Composer 2.2+ 内置的反向依赖查询命令，专为这事设计。它会扫描 vendor/composer/installed.json 和所有已加载的 composer.json，找出哪些包在自己的 require 或 require-dev 中声明了你指定的包。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• 基本用法：composer depends vendor/package-name
• 只查生产依赖（忽略 dev）：composer depends --no-dev vendor/package-name
• 如果返回空，不代表没人依赖——可能是该包没被当前 lock 文件锁定（比如只在某分支里存在），或者你拼错了 vendor 名
• 它不检查代码里硬编码的 require_once，也不管运行时动态加载的包

为什么 composer depends 有时查不到已知的依赖者

常见原因不是命令失效，而是环境状态和解析逻辑限制导致的“看不见”：

• 目标包版本未被 composer.lock 锁定（例如你刚改过 composer.json 但没 run update）
• 依赖者本身是 root 包（即你的项目），而 composer depends 默认不显示 root —— 加上 --all 参数才能看到
• 依赖者使用了版本别名（如 "dev-main as 1.0.0"），而你查的是原始包名，得用别名再试一次
• 某些插件（如 hirak/prestissimo 旧版）或自定义 installer 可能干扰 installed.json 的生成，导致依赖关系漏报

替代方案：手动解析 installed.json 查反向引用

当 composer depends 失效又急需确认时，直接读取 vendor/composer/installed.json 最可靠。这个文件是 Composer 运行时的真实依赖快照，字段清晰，结构扁平。

• 打开该文件，搜索目标包的 name 字段（如 "monolog/monolog"）
• 记下它的 uid 值（一串数字），然后全局搜索 "requires" 或 "requires_dev" 对象里是否包含这个 uid
• 匹配到的包对象里的 name 就是依赖者；注意有些包会把依赖写在 replace 或 provide 里，那属于“逻辑替代”，不算真实依赖
• 脚本化处理推荐用 jq：jq 'keys[] as $k | select(.[$k].requires | keys[]? == "vendor/package-name") | $k' vendor/composer/installed.json

Composer 的反向依赖本质是静态元数据匹配，不是运行时分析。所以只要 lock 文件过期、installed.json 损坏、或包被 alias/replace 掩盖，结果就可能断连。别指望一次命令覆盖所有边界场景。