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 中声明了你指定的包。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 基本用法：
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
